Off-Agent Authorization for Tool Calls

What it constrains

Off-agent authorization constrains which tool calls an AI agent may execute by moving the two fundamental safety questions — who is asking, and is this caller permitted — out of the model and into a separate trust domain. The enforcement point sits between users, agent runtimes, and tools. It evaluates identity, session binding, role, tool, arguments, and policy before an action runs.

The problem it addresses is structural: agent runtimes treat every speaker as the operator. A teammate, a stranger, a poisoned document, or a spoofed display name all look the same to the model. Model-layer safety is uneven and does not track price — in a benchmark of 15 frontier models (July 2026), refusal rates against eight attack scenarios derived from the Agents of Chaos corpus ranged from 100% down to 38% among fully evaluated models, and the most expensive model refused only half of the attacks. aiAuthZ equalises this: with the gateway in place, residual attack success falls to 0% for every model at no more than 0.03 ms of added decision latency.

aiAuthZ is one implementation and research reference for this pattern. Secure AI Atlas treats the canonical control as the broader off-agent authorization boundary, not as the specific aiAuthZ project or paper.

Control pattern

The control uses a gateway running in a trust domain separate from the agent host, with the policy store, per-user keys, and brokered secrets on the gateway side of the boundary. The agent holds no credentials with which to read or rewrite any of them. Two request paths cross the boundary:

Ingress path. The user submits a signed message. The gateway verifies a per-message HMAC-SHA256 signature computed over the user identifier, the session identifier, a hash of the message content, a single-use nonce, and a timestamp. The session’s active user is bound to the most recent verified message rather than to a long-lived session token.

Tool-call path. The agent emits a tool call with its service token and an X-Active-Message-Id. The gateway authorises: service token valid → session bound to a user → role permits the tool → argument constraints pass → under the rate limit. The agent never sees the user’s HMAC key, never reads policy, and cannot rewrite the audit log.

The policy is a role-based and argument-level policy that the agent can neither read nor modify. It combines:

• Role-based tool allowlists
• Per-tool rate limits
• Argument-level constraints on paths, URLs, recipients, and write sizes

A credential broker keeps API secrets off the agent host by injecting them only after a call is authorised. The gateway speaks the Model Context Protocol (MCP) and plain HTTP, so existing runtimes connect to it as an ordinary tool source.

Identity binding and receipts

Every accepted message yields an HMAC-authenticated QR receipt. Because a QR code is self-locating and error-correcting, it re-verifies even after being forwarded, screenshotted, and re-compressed — where a plain byte-signature or an invisible watermark would break. In a provenance evaluation across eight transmission channels, the receipt achieved 94% mean verification with zero forgeries accepted in 25 wrong-key trials.

Audit log

Every decision is appended to a SHA-256 hash chain: every record’s hash includes the previous record’s hash, so editing or deleting any past row changes its hash and breaks every link after it. A verify-chain endpoint detects tampering. Retention clears payloads by crypto-erasure but never removes chain rows, so data-erasure obligations and an unbroken chain coexist.

Implementation evidence: aiAuthZ

The aiAuthZ paper and implementation demonstrate one concrete design for this control: per-message HMAC verification, session identity binding, policy-mediated tool authorization, hash-chained decision logs, and brokered credentials. That evidence supports the pattern, but does not make aiAuthZ itself the only valid control design.

What it is not

Off-agent authorization is not a prompt injection detector. Injected text passes through ingress by design; the defence is that injected text cannot change whose identity is bound to the session. It is not a content guardrail and is complementary to probabilistic classifiers such as Llama Guard and Constitutional Classifiers. It is not a sandbox by itself: a runtime that keeps its own overlapping built-in tools can bypass it, and closing that bypass is an explicit deployment obligation.

Owner

The gateway owner should sit where identity management, security engineering, and AI platform operations meet. The owner is responsible for provisioning per-user HMAC keys out of band, maintaining the role-based and argument-level policy, auditing the hash chain for tampering, and ensuring that agent runtimes have their overlapping built-in tools disabled.

Evidence

• HMAC-SHA256 signature verification per message
• Policy evaluation decision log (hash-chained audit)
• QR receipt verification records
• Credential broker configuration (no secrets on agent host)
• Conformance check showing agent runtime built-in tools are disabled

Common errors

• Running the authorization gateway on the same VM as the agent it protects. The control depends on policy and keys living in a trust domain the agent has no credentials for. If they share a host, a compromised agent can read the database, exfiltrate keys, and forge approvals.
• Keeping the agent runtime’s own built-in shell, file, and web tools enabled alongside the gateway. In end-to-end testing, when the runtime’s own tools remained enabled, the model performed the sensitive action through the built-in tools and never consulted the gateway.
• Relying on model-layer safety as a substitute. Price does not buy safety: in a 15-model benchmark the most expensive model attempted 4 of 8 attacks, while a cheaper model attempted only 2, and only one safety-specialised model refused them all.
• Treating off-agent authorization as a prompt injection detector rather than an authorization layer. The gateway does not prevent the model from being deceived; it prevents a deceived model from acting beyond the verified user’s authority.

Related risks

• LLM01: Prompt Injection (OWASP Top 10 for LLM Applications)
• Excessive Agency
• Data Exfiltration
• Privilege Escalation
• Repudiation of Actions

References

Kim, A. “aiAuthZ: Off-Host, Identity-Bound Authorization for AI Agents.” arXiv:2607.05518 (2026).

Shapira, N., Wendler, C., Yen, A., et al. “Agents of Chaos.” arXiv:2602.20021 (2026).

Uchibeke, U. “Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents.” arXiv:2603.20953 (2026).

Prakash, P. “Agent Identity Protocol.” arXiv:2603.24775 (2026).

Source implementation: https://github.com/Sports-Vision-Inc/aiAuthZ