On October 15, OpenRouter launched Armor in beta — a safety classifier that checks agent tool calls before they are executed, based on rules written in plain English. The system sits between the model and the application, works on top of the Jev decision model from TypesafeAI, connects as a plugin to the Responses API, and remains compatible with Claude Code. The company accompanied the launch with a claim of higher accuracy and significantly lower cost compared to competitors, but there is no independent verification of these claims yet.
What happened
On October 15, 2026, OpenRouter announced the launch of Armor and opened beta access. The classifier processes every tool call and issues one of three verdicts: hard-deny, soft-deny, or allow. An action outside the policy is blocked before it is executed, while the model receives an explanation of the reason for the refusal, and a safeguard_results field appears in the response — the rejection remains observable rather than being silently discarded. In custom agents, Armor is enabled via a plugin with the identifier id armor in the Responses API, and in a Claude Code-compatible scenario, it is enough to run the model through OpenRouter with the command ori claude --model -- --permission-mode auto. The company accompanied the launch with published documentation and curl request examples to the Responses API, so this is a beta, not a closed preview.
Context
Before Armor, agent protection was built mainly from allowlists, manual permissions, and regex filters that each team assembled on its own. The severity of the problem is illustrated by a typical scenario: an agent with shell access can push changes to main or send a .env file outside, and there is nothing to stop it at the last moment. Armor changes the structure of the solution: the classifier is moved to a separate layer between the model and the tools, and the safety assessment is separated from the vendor of the capability model, so auto mode with safeguards works with any model served by OpenRouter, not just Anthropic models. The economics of the issue are formulated in the original post: safety is very hard to sell if no one understands its meaning, and SOC2 is the reverse example here — a standard that the market has accepted as a mandatory requirement. Armor repeats this move at the API level: protection from a separate product becomes a router option.
Why this matters for the industry
For the industry, this is an architectural shift: tool call checking is moved from custom filters to a model-agnostic classification layer, and OpenRouter packages protection as a plugin of its own API. For guardrail and monitoring startups, this is pressure: basic protection becomes much cheaper and becomes part of the gateway, so solutions at the level of a regex filter lose their meaning, but space opens up above the classifier — policy packs, approval interfaces, and observability on top of safeguard_results. Further, methodology will decide everything: if OpenRouter or TypesafeAI publish test sets, metrics, and error distributions, Armor can become the de facto point of comparison for guardrails on the router side and force competitors to disclose their numbers, and other gateways will likely copy the security plugin format. If tool call classification survives the beta and receives independent audits, within a two-year horizon the policy layer may become a standard block of the inference stack — much like SOC2 became a mandatory pass in the B2B market.
Why this matters for users
If you are running agents that execute shell commands or make API calls, Armor allows you to describe a policy in natural language — for example, “never push to main” or “do not send .env outside” — and receive a safeguard_results field in the response with a verdict for each call. You can try it right now: documentation and curl request examples to the Responses API have been published, in custom agents the classifier is enabled via the id armor plugin, and for Claude Code it is enough to run ori claude --model -- --permission-mode auto through OpenRouter. The cost of the experiment is minimal, but a reasonable first step is to enable Armor not as a blocking circuit, but in observation mode: log the verdicts and see where the classifier makes mistakes before giving it the right to block production.
What is still unknown / limitations
Key claims are currently confirmed only by the company itself: the comparison of Jev with Claude Code's auto-classifier has no disclosed test set, metrics, and distribution of false positives and false negatives — a classic “claim first, eval later” pattern. The classifier's robustness to paraphrasing of the same rule is also not characterized: a natural language policy moves protection into a non-deterministic space, and a false positive on soft-deny breaks the agent's working cycle more than a rare miss of a dangerous action, and any product on top of Armor inherits this uncontrolled non-determinism. Armor is in beta: there are no public prices or latency data, and terms and SLA are promised only after the beta. Expectations about independent benchmarks, the response of other gateways, and the standardization of policy layers are forecasts, not facts, and they need to be confirmed or refuted in the coming months.
Sources
- OpenRouter: “Today, we are launching OpenRouter Armor in beta” (official launch announcement)
- Armor — A Safety Classifier for Tool Calls (official OpenRouter documentation)
Author
Look at AI, editorial team