The Authorization That Cannot Widen

On June 22, 2026, Genliang Zhu and Chu Wang posted Intent-Governed Tool Authorization for AI Agents to arXiv. The paper names a specific and narrow problem: existing authorization systems ask whether a credential can call a tool. They do not ask whether the user's current request justifies calling that tool. Those are different questions, and the gap between them is the gap the paper proposes to close.

The paper calls its proposal IGAC - Intent-Governed Access Control. The mechanism is a server-side authorization layer that introduces intent certificates, session-scoped policy narrowing, intent-aware manifest filtering, and intent-tool-payload consistency checks. The central invariant the paper names is precise: user intent may only reduce the authority granted by static integration policy. It never expands scopes, data policy, tenant boundaries, or review requirements. The authorization cannot widen.

What the structural claim names

The authorization problem the paper identifies is not a configuration error. It is a design condition. A credential that grants both read and export authority over a data store does not become inappropriate because the credential exists. It becomes inappropriate when the user asks for a bounded summary and the agent, holding an export-capable credential, decides to export. The credential was valid. The action was unjustified. No existing authorization layer sits between those two facts.

IGAC inserts a layer there. The mechanism works by attaching an intent certificate to the agent session. The certificate names the user's expressed intent and binds it as a policy attribute. When the agent attempts a tool call, the server checks whether that call is consistent with the certificate. If a user asks for a summary and the agent constructs an export payload, the payload fails the intent-tool-payload consistency check even if the underlying credential would normally permit it.

The invariant holds in one direction only. A credential can be narrowed by an intent certificate. It cannot be widened. A session granted summary-reading authority cannot be expanded by a more permissive subsequent certificate to include export authority. The narrowing is monotone. The architecture allows the agent to do less than its credentials permit; it does not allow the agent to do more than the certificate names.

The paper maps IGAC onto OpenPort, an existing governance substrate. OpenPort already implements authorization-dependent discovery, scope and attribute-based access control checks, draft-first writes, preflight impact binding, state-witness checks, idempotency, stable reason codes, and audit logging. IGAC is not a replacement for that substrate. It is an additional layer that adds the user's current intent as a live policy input to each tool call decision.

The practical example the paper offers is precise. A model-generated delete call should not execute merely because the integration holds a delete scope. The credential permits the action. The intent certificate, if the user asked only for a search, does not. The authorization layer is the site where that inconsistency becomes a denial rather than a logged-after-the-fact audit event.

Where the authorization design does not align

The June 22 paper by Zhu and Wang places the authorization decision on the server. The agent does not decide what it is permitted to do within its session. The server decides, on the basis of the intent certificate, what the agent is permitted to do with any given tool call. The agent receives a narrowed manifest of available tools and cannot discover tools outside that manifest.

This is the structural inverse of the blanket-grant pattern that the Vercel "Allow All" architecture (S4-S6 in the arc) instantiated. In that pattern, the user grants broad authorization at session initialization and the agent inherits the full grant. The agent then acts within that grant, narrowing its own behavior only by whatever alignment training and safety filters happen to constrain it. The authorization surface is wide at the start; narrowing happens inside the model, not at the server.

IGAC inverts the direction. The user's stated intent creates a certificate that is narrow from the start. The server enforces the certificate at each tool call boundary. The agent cannot widen its own authorization by finding a path to a permitted credential that the user's intent would not justify. The narrowing is architectural, not behavioral.

The heartbeat-bound credential protocol described in the May 20, 2026 paper by Deochake and Saurabh (P8) addresses the revocation horizon: when should a credential expire without a central authority round-trip? IGAC addresses the authorization scope: given that a credential is live, what scope is justified by the current user intent? The two mechanisms are complementary and independent. P8 bounds the time dimension of credential authority. IGAC bounds the scope dimension of credential authority. A session that holds a live heartbeat-bound credential still requires an intent certificate to determine which tools within that credential's scope are consistent with the current request.

The TrustedARI routing architecture described in V019 addresses a related problem on the routing side: whether an agent's incoming instruction can be trusted as originating from an authorized source. IGAC addresses the outgoing side: whether the agent's outgoing tool call is justified by the intent the user expressed. The two mechanisms address different boundaries of the same trust problem.

The substrate question IGAC leaves open is the one it names without answering. The intent certificate requires a component to parse the user's expressed intent and convert it into a structured policy attribute. The paper maps this onto the existing OpenPort substrate but does not specify how the intent parser handles ambiguous, compound, or multi-step requests where the intent is not a single bounded phrase. A user who says "help me prepare the quarterly report" has expressed an intent that might justify reading from five different data sources, constructing a draft, and sending it to a distribution list. Whether that compound intent generates a certificate that narrows or widens the agent's effective scope relative to a simpler request is the open architectural question.

The Andreessen autonomy threshold framing (A1-A6) argued that agents need sufficient authority to be useful. IGAC does not dispute that claim. It disputes the design assumption that "sufficient authority" means authority granted at session start and inherited for the session's duration. Under IGAC, sufficient authority is re-evaluated at each tool call boundary against the user's current expressed intent.

What composes with IGAC

The May 18, 2026 paper by Christodorescu and colleagues (P6) argued that agent security is a systems problem and that the model itself must be treated as an untrusted component. That paper's solution space sits at the architecture level: isolation, mediated tool access, capability scoping, instruction-versus-data separation. IGAC is a specific instantiation of mediated tool access. It puts the mediation at the intent layer rather than at the capability layer alone.

The May 15, 2026 paper by Alamdari, Klassen, and McIlraith (P5) introduced linear temporal logic runtime monitors that intervene when an agent attempts to violate a specification. The specification in that framework is independent of the agent's policy. IGAC's intent certificate is also independent of the agent's policy. The two mechanisms differ in how they represent the constraint: LTL monitors represent behavioral constraints over time; intent certificates represent scope constraints over a session. A system that combined both would constrain the agent's behavior over time and constrain which tools the agent is permitted to use at each step.

The five categories of agentic AI risk that CISA has begun to map (C1-C5) include structural privilege as a distinct risk category. IGAC addresses structural privilege directly by removing the condition under which an agent's full credential scope is available for any action the agent generates. The credential scope and the intent-justified scope are no longer the same thing.

What remains on the table

• When a user's expressed intent is compound or ambiguous, what is the procedure for generating an intent certificate that does not collapse to either the widest or narrowest plausible reading of the request? And who bears the governance burden if the certificate is later shown to have been too broad?
• IGAC maps onto OpenPort as an existing governance substrate. For agent deployments that do not run on OpenPort or an equivalent authorization infrastructure, what is the migration path, and does the intent certificate mechanism require changes to the tool API surface itself or only to the server-side authorization layer?
• The monotone narrowing invariant holds for a single session. In a multi-agent swarm where one agent's output becomes another agent's input, does the intent certificate from the originating session propagate, get re-issued, or get discarded? And if re-issued, against whose intent?
• The paper positions intent-tool-payload consistency as a server-side check. Where an agent's tool call constructs a payload incrementally across multiple steps, at what point in the construction sequence does the consistency check fire?
• If the intent certificate narrows the agent's manifest and the agent reaches a task state where it cannot complete the user's stated intent without a tool the manifest has removed, what is the recovery path? Does the agent surface the restriction to the user, halt, or request a new certificate?

The loop closed around an oversight function that was never instrumented.