Blog · arXiv Analysis · Last reviewed June 25, 2026

The Authorization Overlay Becomes the Delegation Contract

Amjad Ibrahim and Yong Li's June 2026 arXiv paper Overlaying Governance: A Compositional Authorization Framework for Delegation and Scope in Agentic AI argues that agent authorization needs a compositional overlay. Delegation and scope are not just static consent tokens; they are runtime terms that must attach to existing authorization graphs.

A delegation contract, in this essay, is not a legal spell or a prompt promise. It is the machine-checkable record of delegator, delegate, purpose, scope envelope, context, expiry, onward-delegation rule, revocation path, and evidence trail.

Tokens Are Not Contracts

Ibrahim and Li's paper, arXiv:2606.03518 [cs.AI], was submitted on June 2, 2026. Its subject is the authorization problem created when AI agents do not merely read data or answer prompts, but act for users, hand work to other agents, and carry authority through chains of delegation.

Ordinary web authorization often works with a familiar shape: a principal receives a credential, the credential has scopes, and a service checks whether the request fits. That shape is useful, but it becomes thin once an agent is expected to act under time limits, purpose limits, hardware limits, resource envelopes, and possible onward delegation. The paper's useful move is to treat delegation as a governance term in the runtime authorization decision, not as a background story hidden behind a broad token.

This is a different concern from the site's earlier pages on tool-scope intent gates, runtime governance planes, and portable action certificates. Those pieces ask how an action is gated, observed, or receipted. This paper asks how the permission graph itself should absorb agentic delegation without pretending every agent is just another static user.

Current Context

As of June 25, 2026, agent authorization is no longer a speculative edge case. NIST's AI Agent Standards Initiative frames agents as systems capable of autonomous actions and names industry-led standards, open protocols, agent authentication, identity infrastructure, and security evaluations as active work. NIST's NCCoE is separately exploring standards-based ways to identify, manage, and authorize actions taken by software agents, including AI agents; its concept paper was published February 5, 2026, and its public comment period closed April 2, 2026.

OAuth Token Exchange, standardized in RFC 8693, gives existing identity systems a way to request new security tokens with impersonation or delegation semantics. That is useful infrastructure, but it is not the same as a recursive authorization graph. A token can carry subject, actor, audience, resource, scope, and lifetime; the overlay paper asks a deeper question: how should those grants compose when agents delegate to other agents inside existing domain policies?

The ReBAC lineage matters here. Google's Zanzibar paper described a relationship-based authorization system used across Google services, while OpenFGA exposes a Zanzibar-inspired model where authorization checks evaluate relationship tuples against an authorization model. Ibrahim and Li's contribution is to treat agent delegation, scope envelopes, sessions, and attenuation as additional relations that can be overlaid onto such models rather than pasted into prompts.

Overlaying the Graph

The core proposal is compositional. The authors build on relation-based access control, the Zanzibar style of relationship graphs, and OpenFGA as a reference implementation. Instead of requiring each existing authorization domain to be rewritten from scratch, the paper defines an overlay that adds agent-specific relations for delegation, scope, and authority attenuation on top of domain policies.

The word "overlay" matters. A finance system, document system, or collaboration system already has its own objects and permissions. The agentic layer should not erase that domain model. It should add a disciplined vocabulary for who delegated to which agent, which scope envelope applies, whether that envelope narrows as authority moves through a chain, and which relation ultimately permits or denies the action.

That makes delegation inspectable. If a user authorizes an agent to summarize one folder, and the agent delegates part of the task to another component, the authorization question should not collapse into "the original token was valid." The live question is narrower: does this actor, under this delegation chain, within this resource scope, have permission for this action now?

The paper's taxonomy is useful for product design because it separates several cases that interfaces often blur: full delegation, scoped delegation with attenuation, conditional delegation, depth-bounded delegation, temporal delegation, and group delegation. Those are different contracts. A one-hop, read-only, ten-minute delegation is not the same authority as a reusable agent credential that can create child agents and write across a workspace.

What the Benchmark Shows

The empirical section compares ordinary domain authorization with domain-plus-overlay authorization in OpenFGA models for Google Drive-like and Slack-like use cases. The paper scales users, agents, groups, folders, documents, workspaces, channels, and messages across synthetic scenarios. The Google Drive-like series grows to 1,000 users, 100 groups, 200 folders, 30 documents per folder, 500 agents, and one session per agent; the paper also reports scenarios up to 780,000 relations.

The reported result is not that overlays are free. They add relations, graph size, and memory pressure. The benchmark runs 1,000 operations per case, with overlay workloads using an 80/20 check/write split to reflect changing delegation state. The useful claim is more modest: median check latency remains under 7 ms in the reported suite, while write-operation medians fall in the 4.49 ms to 9.42 ms range.

The companion GitHub repository matters because it lowers the trust burden. It lists OpenFGA models, tuple generators, benchmark scripts, setup commands, generated datasets, and analysis artifacts for the paper's Google Drive and Slack experiments. For an authorization proposal, that kind of artifact trail is part of the argument: the governance layer should be inspectable, and so should the research that proposes it.

What It Does Not Prove

The benchmark is feasibility evidence for the tested synthetic OpenFGA models, not a production certification. The authors explicitly say the datasets simplify real deployments: folder and channel topologies come from controlled templates, and delegation chains use bounded rules rather than full production histories. A real deployment still has connector bugs, stale grants, cross-tenant boundaries, rate limits, caching choices, audit retention, human approval queues, and incident workflows.

The paper also does not solve intent inference. It gives a way to represent delegated authority after authority has been granted. It does not prove that a model correctly understood the user's purpose, that a prompt was not injected, that a human approval was meaningful, or that a child agent will choose the right action. Those questions belong with intent gates, agent observability, agent sandboxing, and incident review.

Finally, OAuth, OpenFGA, Cedar, Zanzibar-style ReBAC, and protocol authorization are not interchangeable. Token exchange can reshape credentials. A ReBAC engine can answer graph membership questions. A policy language can express application rules. An overlay can inject agentic delegation relations. A governed agent may need all of those layers, plus monitoring and revocation, before an action deserves institutional trust.

The Governance Memory

The Spiralist reading is that the permission record becomes governance memory. A prompt can say "only use approved data." A policy document can say "do not exceed delegated authority." Neither statement is enough if the runtime cannot reconstruct who granted authority, what was granted, where it narrowed, and why the final action was permitted.

Agent systems intensify an old access-control problem. Organizations already struggle with stale service accounts, overbroad roles, inherited permissions, and unclear accountability. Agents add a conversational surface and a planning loop, which can make authority feel informal even when the consequences are concrete. The overlay idea resists that informality. It says that agency must be represented in the authorization model itself.

This also gives a sharper standard for audits. A reviewer should be able to ask three questions and get structured answers: which human or service delegated authority, what scope envelope survived each step, and which relation in the authorization graph allowed the final action. If any of those answers is missing, the system is relying on trust theater rather than authorization evidence.

Governance Standard

Any production agent that acts under delegated authority should have a first-class authorization record for identity, delegator, delegate, purpose, scope envelope, attenuation rule, context predicates, expiry, onward-delegation depth, revocation path, and final relation check. The record should be independent of the chat transcript. It should survive handoffs between tools and agents. It should fail closed when the delegation chain or scope envelope cannot be evaluated.

The authorization decision should preserve enough evidence for later review: principal, agent identity, session, token issuer, audience, resource, scope, relation tuple or policy rule, context values, approval event, denial or allowance, trace ID, and any downstream side effect. Logs should not retain raw credentials, but they should retain enough metadata to prove whether the authority was current and bounded.

This does not make an agent safe by itself. It creates the minimum condition for accountable action: authority becomes explicit enough to deny, narrow, trace, revoke, and review. The practical question for agentic governance is no longer whether a model promised to behave. It is whether the system can prove that the action was inside a current, bounded, inspectable delegation contract.

Source Discipline

Use Ibrahim and Li's paper for the overlay model, delegation taxonomy, proof claims, OpenFGA benchmark setup, and stated limitations. Use NIST materials for current U.S. standards and project context around agent identity and authorization. Use RFC 8693 for token-exchange claims. Use OpenFGA documentation and the Zanzibar paper for relationship-graph authorization background.

Keep source types separate. An arXiv framework is not a deployed control. A GitHub artifact repository is reproducibility evidence, not a peer-reviewed audit. A NIST concept paper is project planning, not a binding standard. An OAuth token is not a complete authorization model. A ReBAC check is not evidence that user intent was valid. Governance claims should name the implementation, model version, policy schema, tuple source, token semantics, benchmark date, and exclusions.

Sources

Return to Blog