OpenRouter launches Armor, a beta classifier that blocks risky AI agent tool calls

What OpenRouter launched

OpenRouter, the service that gives developers one API for many AI models, launched Armor in beta on 15 October 2026. Armor is a safety classifier that sits between a model and the application running it, and checks every tool call the model proposes before the call is executed. The announcement on X said regex-based filtering often is not enough to catch unwanted tool calls, and that Armor uses TypeSafe's Jev model to guard against out-of-policy calls.

The problem is familiar to anyone running coding agents. As OpenRouter's Armor documentation puts it, an agent that can run shell commands can also push to main, delete a directory or send a .env file to an external server. Most harnesses handle this by asking a person to approve each command, which is safe but slow. Armor lets developers write rules in plain English instead, and blocks calls that break them.

OpenRouter's headline claim is that Armor does this with better performance than Claude Code's own automatic classifier at a fraction of the cost. That comparison comes from a test set OpenRouter built itself, covered below. During the beta, Armor evaluations are not billed.

How Armor decides whether a tool call runs

For each tool call, OpenRouter holds the call instead of forwarding it to the application. It sends the call, the developer's rules and the conversation so far to a decision model, which returns a probability that the call matches each rule. Armor combines those into a single verdict, flagged or not flagged.

A call that is not flagged is released unchanged, with a safeguard_results field recording the verdict. A flagged call is marked to skip execution, along with metadata naming the rule and an instruction not to retry with the same arguments. The model then treats it like any failed tool call: it tries a narrower call or explains the situation to the user. OpenRouter's launch thread stresses that user intent counts. If the user asked to push their work, a git push can go through; a dangerous command the user never asked for is flagged.

Developers also supply environment facts, which the documentation describes as the system prompt of the Armor call: which repositories, domains and buckets are trusted, the deploy target, the current branch and who the user is. A rule about sending data outside the trusted repository can only be judged if Armor knows which repository is trusted, so stale facts make every rule less precise.

Hard-deny, soft-deny and allow rules

Rules come in three tiers, and the precedence between them is the core of the design.

• Hard deny: an action that must never happen, such as credential exfiltration. A match blocks the call, and neither an allow rule nor the user asking for it clears the block.
• Soft deny: an action that is usually wrong but sometimes legitimate, such as deleting a directory. A match blocks the call unless an allow rule also matches, or the user asked for that exact operation on that exact target. Asking to clean up old drafts does not clear rm -rf on the root directory.
• Allow: an exception that never blocks anything and exists only to clear a soft-deny match, for example a test suite that deletes its own temporary directory.

Claude Code auto mode on any model

Each rule can carry an id, a name, instructions of up to 8,000 characters and a match threshold. The defaults are 0.6 for deny rules and 0.7 for allow rules. OpenRouter says it set them on Claude Code's auto-mode test sets, and that below 0.7, allow rules that only partly applied were clearing force pushes and repository deletes. Armor also includes one built-in soft deny for boundaries the user has set in the conversation, such as don't push until I review.

The most practical feature may be compatibility with Claude Code. Anthropic's coding agent has an auto permissions mode that relies on a classifier to decide which actions can run without asking. Armor implements a Claude Code compatible API, reading Claude Code's safeguards entry and answering in the format it expects, so auto mode can work with any model OpenRouter serves. OpenRouter's launch example runs Claude Code with Kimi K3 through Ori, its command-line tool for running agent harnesses on OpenRouter. When a request reaches an Anthropic endpoint that supports the safeguard beta, Anthropic's own classifier verdict is passed through; elsewhere, Armor evaluates.

What happens to a blocked call

How a blocked call is represented depends on the API and an output_mode setting. That matters because, in one mode, Armor only reports and the client is responsible for not running the call.

The benchmark, latency and cost

OpenRouter's benchmark used a synthetic test set of 492 tool calls seeded from real harness logs. Jev 1.13, Armor's default model, agreed with the labels on 446 calls, or 90.7%, at $0.0021 per call. Cloudflare's Clef decision model scored 88.4%, Sonnet 5 as used by Claude Code 88.2% at an estimated $0.022 per call, and OpenAI's GPT-6 Luna decisions 82.7%. Jev is built by TypeSafe, which raised an $870 million Series A in early October.

The documentation adds two operational numbers. With the Claude Code compatible rule set loaded, Armor added 279 milliseconds of latency per tool call at the median and 334 milliseconds at the 90th percentile. Pricing, OpenRouter says, will be announced before general availability.

Why it matters for agent builders

Agent failures are moving from hypothetical to documented. OpenAI recently disclosed that an internal model spent someone else's test cryptocurrency without permission, and security researchers have shown a backdoored model stealing credentials through Codex CLI. A guard that inspects each call against written rules, rather than trusting the model, addresses both kinds of failure, whatever model is generating the calls.

Armor also lowers the switching cost between models. Teams that liked Claude Code's auto mode but wanted to run other models had to give up the classifier or approve commands by hand. An audit mode, which reports verdicts without blocking anything, lets teams measure false positives and misses on their own traffic before enforcing.

Limits and open questions

The benchmark is OpenRouter's own, on a test set it generated for the task, and has not been independently reproduced. The Sonnet 5 cost is an estimate, and accuracy on 492 synthetic calls says little about rare but catastrophic cases. OpenRouter itself warns that the decision model will occasionally block a call a developer would have allowed and release one they would not.

Other limits are written into the documentation. The configuration fields, the safeguard_results object and the blocked-item type may change during the beta. Armor is not yet supported for requests under HIPAA, zero data retention or data-region restrictions; plugin requests there are rejected, while Claude Code requests fall back to Claude Code's local evaluation. If the decision model times out, the default is to block the call. Provider-native tools such as web search are skipped unless a developer opts in, and every evaluated call is sent, with the conversation so far, to the decision model, which by default is TypeSafe's Jev.