Short answer: A model can screen tool calls, but it gives probabilities, so the decision that lets an AI tool touch a real system should come from deterministic rules that return the same answer for the same call, evaluated next to the credential.
What is OpenRouter Armor?
On October 15, 2026, OpenRouter announced Armor in beta, using TypeSafe’s Jev model “to guard against out of policy tool calls.” The Armor docs call it “a classifier that runs between the model and your application and evaluates every tool call the model makes.”
You write rules in plain English as hard deny, soft deny, or allow. For each call, a decision model reads the call, your rules, and the conversation so far, and returns a probability that the call matches each rule. A deny rule counts as matched at 0.6 by default.
The docs are candid about the tradeoffs. Armor added 279 ms at the median and 334 ms at the 90th percentile in OpenRouter’s own test. And in their words: “It will occasionally block a call you would have allowed, and occasionally release one you would not.”
Why does this matter if you don’t use OpenRouter?
Willow’s October 15 post on runtime governance sums up the model gateway’s job with the question “Which model should receive this request?” That’s routing. Armor is a model gateway reaching past routing to check what the model is about to do.
LLM gateways can also screen proposed tool calls; Gatekeeper governs access to the services AI tools act on. Armor shows buyers want action controls alongside routing. The open question is how the decision gets made.
Should a model decide whether a tool call runs?
For some calls, a model is a reasonable screen. Coding tools run shell commands that are hard to list in advance, and a plain-English rule like “don’t send credentials outside the trusted repository” catches spellings a pattern match would miss. Armor’s audit mode lets you measure misses on your own traffic before you enforce.
For calls that move money, change production, or read customer data, you need a decision you can predict and explain later. A classifier’s score does not guarantee that the action is correctly authorized. Its decision can change as the conversation changes, and that conversation is input you don’t fully control. That is a change in inputs, rather than proof that identical inputs produce inconsistent decisions.
How does Gatekeeper make the decision?
Gatekeeper sits in front of the services your AI tools act on, like GitHub, Salesforce, or an internal API, and decides on each tool call whether it runs. Policy is deterministic: static rules plus rules written as code, deny by default, with no model in the decision path. The same call with the same context gets the same answer.
That policy runs inside an enclave (TEE). Policy evaluation and credential release both happen inside that attested boundary, and no server outside the enclave holds a key. When a call passes, the credential is used for the approved request. For bearer tokens, the credential goes out with that request to the service; the AI client does not receive the reusable secret.
Sensitive actions can wait for a person to approve the exact parameters, and the approval is bound to that payload, so an edited call needs a new approval. Every request, decision, and approval is written to an append-only log.
How do the two approaches compare?
| Comparison | Classifier on the model path | Deterministic policy in an enclave |
|---|---|---|
| How rules are written | Plain English, scored by a decision model | Static rules and rules written as code |
| Same call, same answer | Repeatability must be assessed with identical complete inputs; false positives and misses are a separate issue. | Yes, with the same rules and trusted context; this does not guarantee that the rules are correct. |
| Where it sits | Between the model and your application; it withholds flagged calls or relies on client enforcement, depending on output mode. | In front of the services, inside the enclave |
| After a call is allowed | The call goes to your application; service credentials are managed separately in your application and tool stack. | The credential is used inside the enclave for the approved outbound request; the AI client does not receive the reusable secret. |
| What the log records | A verdict per tool call in the response | Who asked, what for, which rule decided, the reason, and any approval, in an append-only log |
What should you ask about any tool-call control?
Three questions cover most of it. If I send the same call twice with the same rules and context, do I get the same decision, and can I see which rule made it? Who actually stops a flagged call, the gateway or my client? (Armor can withhold flagged calls itself in other output modes. Its docs are clear that in Claude Code compatible mode, “A Messages client that ignores safeguard_results will run a flagged tool_use.”) And when a call is allowed, where does the credential sit, and who else can read it?
Common questions about tool-call policy
Should we use a classifier like Armor at all?
It can help where good rules are hard to write in advance. Keep the decision that releases a credential to a system you care about in deterministic rules. Teams can run both.
Can Gatekeeper policy use outside signals, like a risk score?
Yes, with a limit. Policy runs with no network access at evaluation time, so outside signals have to be pushed into the policy context before the call.
Does Gatekeeper use a model anywhere in the decision?
No. Policy is deterministic rules, deny by default, with no model in the decision path.
Next step: run one workflow in monitor mode with us and see what your AI tools are already doing.
Related reading: what an MCP gateway is and what an LLM gateway does.