Artificer Digital The Artificer's Grimoire

Scout: The Enforcement Point Moves Out of the Agent's Reach — the July 2026 Agent-Authorization Research Wave

Summary

A cluster of preprints posted in the first two weeks of July 2026 converges on a single architectural claim: the decision to authorize an agent’s tool call must be made somewhere the agent’s own context cannot reach. The reasoning is uniform across the group. An LLM agent acts on text — retrieved documents, tool outputs, issue bodies — that it cannot authenticate, so anyone who can write into that context can forge the appearance of authority. Three of the papers build enforcement points that sit outside the agent’s reach and refuse to take the agent’s word for anything — each in a different place. aiAuthZ moves the decision off the agent’s host, binding each tool call to a cryptographic identity the agent can neither read nor mint; Context-to-Execution Integrity (CXI) sets a deterministic gate at the execution boundary that admits a call only when its provenance, effect, and invocation all agree on one signed action manifest; and Governed MCP drops the enforcement point into the OS kernel itself, treating every tool call as a syscall and interposing a mandatory governance layer that userspace code can’t bypass. A fourth paper, an action-graded severity scale, fixes the measurement problem beneath all of them — it stops scoring attacks as a single pass/fail bit and grades how much harm the executed action actually did. Meanwhile the productized edge caught up: the Model Context Protocol’s Enterprise-Managed Authorization (EMA) reached stable in mid-June, giving enterprises identity-provider-governed control over which servers an agent may connect to — while explicitly leaving the harder question, whether a given action may run, to a separate layer that the research above is racing to formalize.

Key Findings

1. One principle, stated four ways: authority the agent cannot fabricate

The unifying idea is old in systems security and freshly urgent for agents: put the authorization decision outside the component you cannot trust. What makes it acute here is that the LLM agent is, for this purpose, definitionally the untrusted component — not because the model is malicious, but because it ingests attacker-writable input and cannot reliably separate instruction from data. CXI opens with the whole problem in one sentence: “Language-model agents read attacker-writable context to solve tasks.” aiAuthZ states the consequence plainly — agents “issue tool calls on the basis of text they cannot verify, so any party who controls part of the context can forge the appearance of authority.”

This is where the practitioner should notice the throughline to work already covered here. The ClaudeBleed postmortem diagnosed exactly this failure at the product layer — trust anchored on where code runs rather than who is running it — and sketched a three-layer corrective whose deepest layer was “gate every privileged action behind an authorization check that runs after the message is parsed.” The agent-identity/IAM analysis then showed the industry solving the issuance half of identity (Entra Agent ID, AWS AgentCore Identity, SPIFFE) while the runtime-authorization half stayed the harder, less-settled problem. The July papers are the runtime-authorization half getting a research program. They take the ClaudeBleed corrective — decide at the action boundary, not in the agent — and turn it into mechanisms with threat models, formal properties, and shared benchmarks.

That the group shares a benchmark matters. Three of the four evaluate on AgentDojo (Debenedetti et al.), the 97-task, 629-security-test-case environment that plants injection payloads where untrusted data naturally lands — an email body, a file, a web page — and checks the environment state deterministically afterward to see whether the agent sent the mail or moved the money. It is the closest thing agent security has to a common yardstick, and it is why these results can be read side by side rather than as four disconnected demos.

The design-level approach itself is not new. Google DeepMind’s CaMeL (“Defeating Prompt Injections by Design,” March 2025) and the fourteen-author design-patterns paper (June 2025) established the approach of constraining the system around the model a year earlier — CaMeL by routing a privileged planner and a quarantined data-reader through a custom interpreter that enforces capability policies outside the model, the design-patterns paper by cataloguing six architectures (Action-Selector, Plan-Then-Execute, LLM Map-Reduce, Dual LLM, Code-Then-Execute, Context-Minimization) that each deny untrusted input a path to a consequential action. Simon Willison’s reading of that paper named the operating assumption the whole family shares: an attacker who lands tokens in the context should be treated as controlling what happens next, so the defense has to live in the architecture, not the prompt. The July wave’s contribution is not the insight; it is moving from constrain the model’s options to make the enforcement point a separate, cryptographically- or deterministically-governed process — and measuring it.

2. aiAuthZ: cryptographic identity, off the host, at sub-millisecond cost

aiAuthZ (Sai Varun Kodathala) is the most direct statement of the thesis. It first quantifies why prompt-level refusal is not a foundation: across 15 contemporary models run against eight attack scenarios drawn from real agent incidents, refusal ranged from 100% down to 38%, and — the detail that should end the “just use a better model” argument — the most expensive model in the set refused only half the attacks despite a twentyfold price spread over the cheapest. Refusal is not something you can buy your way into.

The mechanism moves the safety decision, in the paper’s words, “off the agent’s host.” Before a tool call executes, an authorization gateway verifies caller identity with a per-message HMAC-SHA256 signature bound to a single-use nonce and a timestamp window, then evaluates a role-based, argument-level policy the agent — this is the property that matters — “can neither read nor modify.” Every decision joins a hash-chained audit log, and each accepted call emits an authenticated receipt. With the gateway in front, reported residual attack success falls to 0% across all 15 models at no more than 0.03 ms of added decision latency. (Read that 0.03 ms as the policy-evaluation cost, not an end-to-end off-host round trip: the paper doesn’t state whether the gateway was benchmarked co-located or across a network, so it isn’t a claim about network latency to a separate host.) Two narrower evaluations round out the picture, and they should be read separately. On AgentDojo’s banking suite the gateway blocked all seven attacker-directed calls where a spotlighting baseline let two injections through — though not for free: it also blocked one legitimate first-time payment, dropping clean-task completion from 100% to 80%. In a distinct evaluation over nine in-scope incident-corpus cases, it blocked all nine, against four of nine for an argument-only policy that constrains tool arguments but doesn’t authenticate the caller on each message.

Two cautions keep this honest. First, the guarantee is only as good as the policy: a role-and-argument allow-list still has to be written correctly, and the paper’s clean numbers come from scenarios with well-specified policies — the same “who writes the policy” burden that has slowed every capability-based scheme. Second, the cryptographic receipt machinery (a reported 94% verification rate across eight transmission channels, zero forgeries in 25 wrong-key trials) is the least battle-tested part and the least necessary to the core claim; the durable idea is identity-bound, off-host authorization, and a team could adopt that without the QR-receipt apparatus.

3. Governed MCP: tool calls are syscalls, and userspace is bypassable

Governed MCP (Daeyeon Son; first posted April, revised in July) puts the operating-systems analogy at the center of its design: “These tool calls are the agent’s syscalls—privileged operations with side effects on shared state—yet today’s safety enforcement lives entirely in userspace, where a 10-line script can bypass it.” The argument is that guardrail libraries living in the same process as the agent are trivially defeated, so governance has to be interposed the way a kernel mediates syscalls — mandatory, ahead of the operation, unbypassable by the code it governs.

“Kernel-level” here is literal, not a metaphor: the authors implement the gateway as an actual operating-system kernel — Anima OS, a bare-metal x86-64 kernel of roughly 286,000 lines of Rust — with the tool-call reference monitor built in as a mandatory six-layer pipeline (schema validation, trust tier, rate limit, adversarial pre-filter, a logit-based semantic gate the authors call ProbeLogits, and constitutional policy matching) over a Blake3 hash-chained audit trail. The non-inference layers are cheap — a reported 11.3 microseconds per call — while ProbeLogits classification runs 332–556 ms, which the paper positions as several times faster than a Llama Guard 3 baseline. Ablating ProbeLogits collapsed F1 from 0.789 to 0.357, the authors’ evidence that hand-written rules alone don’t hold. The completeness claim is scoped, and the paper is candid about it: every WASM host function and registered MCP tool routes through the kernel gateway — which is what makes the classic “10-line userspace bypass” structurally impossible on that surface — but the paper discloses that a set of ring-3 syscall paths remains ungated, pending future work.

The tension worth flagging for practitioners: the semantic gate is itself a model. Governed MCP moves enforcement out of agent userspace and into the OS kernel, and makes it mandatory, which is the valuable part, but ProbeLogits reintroduces a learned classifier into the decision — so the strongest guarantees in this design are the deterministic layers (schema, trust tier, rate limit), and the semantic layer inherits the usual classifier caveats about distribution shift and adversarial evasion. Read it as “mandatory interposition is the win; the semantic tier is a probabilistic add-on, not a proof.”

4. CXI: provenance, effect, and invocation have to agree

Context-to-Execution Integrity (Igor Santos-Grueiro) is the most information-flow-flavored of the three and the most precise about what it checks. Policies mark protected sink fields (the recipient of a transfer, the address of an email); typed releases carry narrow, validated values out of writable context to specific destinations; opaque data slots hold untrusted evidence as data that can never be interpreted as an instruction; and, in the paper’s formulation, “a deterministic gate admits a call only after field authority, exact-effect authorization, and invocation authority all bind to the same action manifest.” In plainer terms: the value going into a dangerous field has to have provenance the policy trusts, the operation has to be one the policy authorized with those exact effects, and the invocation event itself has to be accounted for — and all three must describe the same action, or the call is refused.

On the “does it break normal work” axis, CXI reports security and utility separately rather than blending them into a single score: on a 400-episode code-agent benchmark the authors report “231 safe task completions and zero observed field, effect, or invocation escapes”; on AgentDojo (720 live episodes, 1,739 model calls) they report 199 safe task completions, with the same zero escapes, and caution that the two benchmarks use different units and should not be averaged. A deterministic gate that admits real work while reporting no escapes is the profile a practitioner wants — no learned component in the enforcement path, which is exactly what CaMeL argued for and what Governed MCP’s semantic tier steps away from. The open question CXI shares with every taint-tracking scheme is authoring cost: someone has to declare the protected fields and legal effects for each tool, and the paper’s clean run rests on having done so.

5. The measurement fix: grade the action’s harm, not a success bit

The fourth paper is not an enforcement mechanism; it is the ruler the other three should be measured with. Beyond Attack-Success Rate (Harry Owiredu-Ashley) observes that red-team benchmarks report compromise “as a single bit: the attack succeeded, or it did not,” which “discards the information a defender most needs, namely how harmful the resulting action was.” Its replacement is a seven-level ordinal scale (L0–L6) that grades an agent’s tool-call trajectory on whether the executed action was reversible, whether it crossed scope to reach another party, and whether it expanded privilege.

The finding that justifies the whole exercise: the study surfaced cases scoring a zero attack-success rate that nonetheless permitted “an externally visible cross-scope leak through an unfiltered tool.” A binary metric called that defense a win; a graded one calls it an L-something data exfiltration. For anyone evaluating the enforcement points above, this is the difference between “our gateway blocks the attack” and “our gateway blocks the catastrophic actions but still leaks read-only data across a tenant boundary” — which is the distinction that actually governs a deployment decision. The paper grades with a panel of three frontier-model judges (reported inter-rater agreement of 0.91 against an oracle, Krippendorff’s alpha), and is candid that the judges are weak at spotting multi-step “escalation chains” — a caveat that matters, because escalation chains are where graded scoring earns its keep.

One disambiguation, because July 2026 produced two “severity scales” for agent security that grade different objects. Anthropic’s Cyber Jailbreak Severity scale, examined in the cyber-jailbreak severity analysis, grades how much a jailbreak technique uplifts an attacker over their existing tools. This action-graded scale grades how much harm the executed action caused, regardless of technique. One scores the intruder’s key; the other scores the damage in the room. They are complementary, and a mature program will want both — a triage grammar for bypass techniques and a harm grammar for outcomes.

6. The productized edge: EMA governs the door, not the room

The research is not floating free of shipping product. Two enforcement points already run outside the agent in production, and they bracket exactly what the papers are formalizing.

MCP’s Enterprise-Managed Authorization (EMA) reached stable status on June 18, 2026, with adopters including Anthropic, Microsoft, and Okta per InfoQ’s coverage. It lets an organization govern, through its own identity provider, which MCP servers a user’s agent may connect to and at what scope — mechanically, the client obtains a short-lived Identity Assertion JWT Authorization Grant (ID-JAG) from the IdP during single sign-on and exchanges it for a server access token, so approved servers light up on first login with no per-server consent prompts, and IdP revocation propagates immediately across all MCP clients. This is a real onboarding and governance win, and standing up MCP internally without wiring server access to your directory is now the harder-to-defend choice.

But EMA is authorization for the connection, not the action, and the distinction is the entire point of the research wave. A practitioner analysis of the extension puts the line precisely: “EMA answers can this user connect this client to this server, and with which scopes? It never answers should this specific action run, right now, on this resource?” (Hosseini). Once the agent is connected, EMA’s visibility ends; what the agent then does with that access is a separate enforcement problem that organizations own. EMA closes the “who connects” slot the earlier MCP gateway survey flagged; it leaves the “what may it do once inside” slot open, which is the slot aiAuthZ, CXI, and Governed MCP are competing to fill.

The nearest productized fill for that slot is AWS’s Policy in Amazon Bedrock AgentCore, whose gateway speaks MCP and evaluates every tool call against Cedar policies at a default-deny boundary — associate a policy with a gateway and it blocks everything until a rule opens a specific invocation. AWS’s own rationale for putting the check there reads like the abstract of any of the July papers: you need “an auditable, deterministic enforcement layer that sits outside the agent and tools,” because “the LLM’s plan is the thing you can’t trust—it can’t be responsible for enforcing its own constraints.” That a hyperscaler and four independent research efforts arrived at the same sentence in the same window is the signal worth acting on: deterministic, default-deny authorization at a boundary the agent can’t rewrite is no longer only a research position — it is an emerging design pattern, and Cedar-at-the-gateway is the reference practitioners can deploy today while the research sharpens the guarantees.

Practical Implications

Decide where each consequential action gets authorized — and make sure it isn’t the agent. The single most useful move from this whole body of work is an inventory: list the tool calls whose effects you would not want an attacker to trigger (money movement, external sends, privilege changes, destructive writes, cross-tenant reads) and confirm that something other than the model’s own reasoning stands between the request and the effect. If the answer for any high-consequence action is “the model was instructed not to,” that is now a known-weak foundation with named alternatives.

If you run on AWS, AgentCore Policy is the adopt-now answer for tool-call authorization. A Cedar policy engine evaluating every MCP tool call at a default-deny gateway is the same boundary-authorization pattern aiAuthZ and CXI describe, in production form today — even if it doesn’t ship their sharper guarantees (aiAuthZ’s per-message identity binding, CXI’s action-manifest provenance). Off AWS, the equivalent is a gateway or proxy that terminates the tool-call path and enforces a policy the agent cannot edit — the middle-tier pattern the gateway-vendor landscape already mapped. Default-deny is the setting that matters; an allow-by-default gateway is theater.

Wire MCP server access to your IdP now, but do not let EMA-stable lull you. EMA going stable is the signal to route MCP connection authorization through your directory — the onboarding and revocation wins are real and the standard is settled. Just hold the line internally that EMA is the lock on the door, not a guard in the room. Budget a separate runtime-authorization layer for what agents do once connected; the two are different controls and conflating them is how “we adopted EMA” becomes a false sense of coverage.

Stop reporting agent-security results as a pass/fail rate. Adopt the reversible / scope-crossing / privilege-expanding grading from the action-graded scale even before a standard settles. The reason is concrete: a defense can post a zero attack-success rate and still leak data across a boundary through an unfiltered read. If your evaluation can’t tell “blocked the transfer but leaked the statement” from “blocked everything,” it is hiding the failures most likely to reach production.

Treat the design-pattern layer as the cheap floor, and the July mechanisms as the sharper ceiling to watch. If you cannot deploy an off-host gateway tomorrow, the 2025 design patterns are the low-cost starting point — Plan-Then-Execute and Action-Selector deny untrusted content a path to arbitrary actions with no new infrastructure, just architecture. The research mechanisms (per-message cryptographic identity binding, kernel-style mandatory interposition, CXI action manifests) are more powerful and not yet packaged; watch them, prototype against AgentDojo, but expect authoring cost and integration work. And keep CaMeL’s cautionary tale in view: a year on, principled off-model defenses remain thin on the ground — and not, on the reported numbers, for lack of efficacy. CaMeL delivered provable protection at roughly 77% task completion against about 84% for an undefended baseline, a trade-off its proponents call deliberate and acceptable. The likelier brake on adoption is more mundane: the utility cost, the policy-authoring burden, and the engineering lift are what keep teams on reactive filters. The July papers report better numbers; they inherit the same adoption tax.

Open Questions

  1. Who writes the policy, and does the authoring cost sink these the way it slowed CaMeL? Every out-of-agent scheme here — role-and-argument allow-lists (aiAuthZ), protected-field and legal-effect declarations (CXI), Cedar rules (AgentCore) — moves the hard problem from “detect the attack” to “specify the policy.” The clean benchmark numbers assume well-specified policies. Whether real teams can author and maintain per-tool policies at scale, or whether policy sprawl becomes the new bottleneck, is the question that decides adoption.

  2. Does a deterministic gate or a model-based gate win the semantic cases? CXI and the deterministic layers of the others make no learned decision and report no escapes; Governed MCP’s ProbeLogits reintroduces a classifier to catch semantically-unsafe calls that pass structural checks. The unresolved trade is whether the residual cases a deterministic gate can’t express (context-dependent “this specific transfer is anomalous”) are worth a probabilistic component in the enforcement path, or whether that reopens the door these designs are trying to shut.

  3. Where does per-action authorization standardize — MCP, the IdP, or the gateway? EMA standardized connection authorization at the IdP via ID-JAG. There is no equivalent standard for per-action authorization, and three research groups plus AWS have each built their own. Whether this converges on an MCP extension, an identity-layer primitive, or a gateway-category de facto standard (Cedar is a plausible nucleus) will determine whether teams get portability or another vendor-lock decision.

  4. Do the reported guarantees survive adaptive attackers? The papers report strong residual-attack numbers against fixed corpora and AgentDojo’s injection suite. AgentDojo is a moving target that its own authors keep hardening, and none of these results yet reflect an attacker adapting specifically to the enforcement mechanism (forging the manifest, gaming the argument policy, targeting the classifier). The security claims are promising and early; the second-round adaptive-attack papers are the ones to wait for before treating any of these as settled.

  5. Does out-of-agent enforcement compose with agent autonomy, or throttle it? A gate that refuses any action whose authority it can’t establish will refuse legitimate novel actions too. The design-patterns literature was explicit that these architectures work by deliberately limiting what an agent is allowed to do. How much useful autonomy survives a strict authorization boundary — and whether that cost is acceptable for the autonomy levels teams actually want to run — is the practitioner-experience question none of the July papers can answer from a benchmark.

Sources

  1. aiAuthZ: Off-Host, Identity-Bound Authorization for AI Agents — Sai Varun Kodathala, arXiv, 2026-07-06
  2. Governed MCP: Kernel-Level Tool Governance for AI Agents via Logit-Based Safety Primitives — Daeyeon Son, arXiv (v1 April, v2 2026-07-06)
  3. Context-to-Execution Integrity for LLM Agents — Igor Santos-Grueiro, arXiv, 2026-07-07
  4. Beyond Attack-Success Rate: Action-Graded Severity Scale for Tool-Using AI Agents — Harry Owiredu-Ashley, arXiv, 2026-07-08
  5. Enterprise-Managed Authorization: Zero-touch OAuth for MCP — Model Context Protocol Blog, 2026-06-18 (stable)
  6. MCP Promotes Enterprise-Managed Authorization to Stable — InfoQ, 2026-07-06
  7. Enterprise-Managed Authorization for MCP: what it actually does, and what it leaves to you — Ehsan Hosseini
  8. Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows — AWS Security Blog
  9. Defeating Prompt Injections by Design (CaMeL) — Debenedetti et al., Google DeepMind, arXiv, March 2025
  10. CaMeL offers a promising new direction for mitigating prompt injection attacks — Simon Willison, 2025-04-11
  11. Ten Months After CaMeL, Where Are the Secure AI Agents? — NeuralTrust
  12. Design Patterns for Securing LLM Agents against Prompt Injections — Beurer-Kellner et al., arXiv, June 2025
  13. Design Patterns for Securing LLM Agents against Prompt Injections (commentary) — Simon Willison, 2025-06-13
  14. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents — Debenedetti, Zhang, Balunović, Beurer-Kellner, Fischer, Tramèr, arXiv (NeurIPS 2024)
  15. Scout: First-Class Agent Identity — the Directory/IAM Layer Emerges — Artificer’s Grimoire scout (builds on, does not duplicate)
  16. Scout: ClaudeBleed — Trust-Boundary Postmortem and the Execution-Context Authorisation Pattern — Artificer’s Grimoire scout (builds on, does not duplicate)
  17. Scout: Grading Jailbreaks — Anthropic’s CJS Scale as a Governance Template — Artificer’s Grimoire scout (disambiguation: jailbreak-technique severity vs. action-harm severity)
  18. Scout: MCP Enterprise Gateway Patterns — The Middle Tier Emerges — Artificer’s Grimoire scout (the middle-tier “slot” framing this builds on)
  19. Enterprise-Managed Authorization (extension specification) — Model Context Protocol Docs