Identity, authorization, accounting

Section 7 opens Part II, the report's tour of what each layer of the stack can contribute. This page covers the system-level half that deals with principals and permissions: §7.1 (identity), §7.2 (authorization) and §7.3 (accounting). The report frames a fourth pillar, privacy, in §7.4, which has its own page, and closes the section with §7.5, the "intent-specification gap" argument, covered on AI as the last-mile developer. Everything below is a version of one question: what does an access-control system key on when the thing asking for access was not written by anyone?

Why the AAA pillars assume the wrong actor

The report organizes §7 around the textbook security mechanisms, citing Sandhu & Samarati (1996) and the Generic AAA Architecture (RFC 2903): authentication establishes who is acting, authorization decides what they may do, accounting records what they did, and privacy governs where information flows (§7, p. 30).

Each pillar quietly leans on an assumption about the actor. If the actor is a human, you can hold them responsible because they meant to do it. If the actor is a program, you can reason about it ahead of time because its behavior is in its source. The report's point is that an agent gives you neither handle.

"an agent is a stochastic actor whose behavior emerges from LLM inference over an unpredictable model context."— the report, §7, p. 30

The section summary blames unstructured intent and context plus a shrinking role for human oversight (§7, p. 30). Our reading: that is the report's three dimensions applied to one layer.

The report treats identity as the foundation: every downstream mechanism starts by establishing who is acting (§7.1), which is why OP 7.5 explicitly depends on OP 7.1–7.2.

OP 7.1 · Distinguishing agents from humans

The question. When an action arrives at a service, can the service tell whether the user did it or the user's agent did it, given that current identity protocols have no notion of an agent as its own kind of principal (§7.1, p. 31)?

What already exists. There is no shortage of identity machinery: the report lists OpenID Connect, X.509 certificates, SPIFFE, Decentralized Identifiers and Verifiable Credentials, and notes recent work applying these to agents (Garzon et al., 2025). The trouble is not missing plumbing. Every one of these identifies either a human or a deterministic workload, and the agent is neither.

Why it is hard for agents specifically

Computer-use agents are the sharpest case. They click buttons, fill forms and navigate pages exactly the way a person does, so at the HTTP layer there is nothing to distinguish them. The report adds that this indistinguishability also cuts the other way: it makes it easy for adversarial environments to mislead the agent (§7.1, citing Zhan et al., 2026b).

Then there is the incentive problem. Bot accounts exist on some services but take far more effort than handing the agent your own login, so agents get a human identity or the user's credentials. The report's examples:

• OpenClaw agents that are routinely given email credentials and use them to register on sites, create crypto wallets and hire human workers, with little supervision.
• Moltbook, a "social network for agents," where there is no clear way to tell a human posting through the API from an agent following a prompt from an agent posting on its own.
• Open-source maintainers receiving large volumes of agent-written code with no way to tell it apart from human contributions, and agents that have already published defamatory "hit pieces" about developers who rejected their pull requests.

What the report points to

One direction: a protocol with a first-class "agent" entity whose identity binds four things together (§7.1, p. 31).

agent identity = {
  user:        who the agent acts for
  software:    model, version, guardrails
  task:        the specific task or session
  delegation:  the chain through which authority was granted
}

Related work the report names (§7.1, p. 32): the NIST concept paper on AI agent identity and authorization (Booth et al., 2026), the OpenID Foundation's Identity Management for Agentic AI (South et al., 2025), Microsoft Entra Agent ID, the IETF SCIM Agentic Identity Schema draft, and the Linux Foundation's AGNTCY.

What a good answer would have to do. Our reading: be cheaper to adopt than reusing a human account, or the incentive problem wins regardless of how good the protocol is. And it must carry the software and task fields, not just a "this is a bot" flag, because the later problems (tracing, purpose-bound permissions, intent binding) all need them.

OP 7.2 · Tracing agents back to users

The question. Three linked sub-questions (§7.1, p. 32): how does an agent say "I am acting for User A right now" in a form that is cryptographically verifiable and auditable; how do you design identity for an agent serving several principals or living in several identity contexts; and how does identity flow through a delegation chain while staying traceable to the person who started it?

Where accountability for an agent's action should land (the prompting user, the developer, the deploying organization) is itself left open. What it claims is narrower: whatever the answer, you cannot assign responsibility without first being able to walk the chain. A service hit by a fraudulent purchase or a defamatory post may need to find the responsible party, or refuse further requests from agents run by the same organization.

Shared agents

A team's group-chat bot or an agent in a shared repository takes instructions from several people at once. Today it authenticates as one service account or one set of client credentials, and there is no standard way to say which user it is acting for at this moment. So an action in a shared context cannot be traced to the person who asked for it.

Multi-hop chains

Agents call remote tools over MCP and hand sub-tasks to other agents over protocols like A2A. In a chain such as user → root agent → sub-agent → remote MCP tool, every hop is an independent decision-maker. The report's core question is what identity the downstream service actually sees. If a deeply nested sub-agent does damage, there is currently no mechanism to walk back up to the originating user and find the hop where things went wrong.

A way to picture this: today's chain usually collapses into "service account of whoever made the last call." What OP 7.2 asks for is closer to a signed stack trace, where each hop appends who it is and on whose behalf it is acting, and the bottom frame is a human.

Related work the report names: Google A2A Agent Cards for advertising capability and identity, and OWASP Agent Naming Service proposals for discovery with identity verification. It also defers intent binding to §7.3, which is OP 7.5 below.

Why OAuth, sandboxes and the trust-management classics fall short

Before its two authorization problems, §7.2 lays out why delegation is different for agents (§7.2, pp. 32–33). A classic app asks once for a well-defined, understandable set of actions ("save photos to cloud storage"). An agent asked to plan a trip may read your calendar, search flights, book hotels and look at your bank balance, and that sequence is chosen at runtime. No upfront consent screen can list it. The report notes this is also called the "intent-execution separation problem" in an IETF draft, and says better authorization would give least privilege via context-aware decisions, plus just-in-time grants that are issued when needed and revoked when the task ends.

Two more pressures: long-running, multi-purpose agents can reuse a grant for another task, and prompt injection often drives agents beyond the intended scope (citing Rehberger, 2025).

The report also mentions trusted execution environments as a possible route to client-side sandboxing (Abdollahi et al., 2026). Our reading of the table: attenuation, the one property agents most obviously need for sub-agent delegation, already exists in the literature (Macaroons, SPKI). The gap the report identifies is that nobody has carried it over, and that none of these systems can express purpose.

OP 7.3 · Enabling context-aware authorization

The question. Can authorization enforce least privilege for agents by granting access not just to a resource, but only under the right conditions and for the right purpose, while staying aware of consent fatigue and of how vague an agent's stated purpose can be? And how is authority delegated between parties, including from a parent agent to its sub-agents (§7.2, p. 33)?

Why it is hard

In classic authorization, permissions come from an app specification. For an agent, they come from a natural-language instruction plus a plan that is still being written. And the same permission can be right or badly wrong depending on why it is used: read access to medical records is fine when finding a doctor and a serious violation when drafting a social media post. That is Contextual Integrity reasoning showing up inside an access-control decision.

"Traditional mechanisms can express conditions like “read-only” or “valid only on weekdays,” but they cannot express “only when helping the user find a doctor.”"— the report, §7.2, p. 33

The same gap applies to natural-language sub-tasks passed between agents.

Permissions also grow during a task. The report's example is an agent resolving a customer complaint that starts with email access, then discovers it needs the billing system and internal monitoring logs (pp. 33–34). So authorization has to be an ongoing process run by the authorization infrastructure, not one decision at the start.

The two obvious answers, and their catches

• Human approves each request. At agent speed this produces consent fatigue: people start approving everything, which defeats the purpose of asking (p. 34).
• The model writes the policy. Possible, but the report warns that untrusted policy inputs open the door to model manipulation attacks. This is the same separation §6's policy-engine design insists on.

What the report points to

A list of research systems, all framed as related work rather than answers (p. 34): CaMeL (a trusted planner isolated from an untrusted data processor), Conseca (policies generated from system context), Sapien (stateful policies generated in context), SAGA (centralized agent access control), Progent (fine-grained tool policies), FORGE (Datalog-based policies), MiniScope (computes minimal OAuth scopes and asks the user to approve them), and Siu et al. (2026a) on formalizing what authorization based on system context requires.

What a good answer would have to do. Our reading: represent purpose in a form a machine can check, keep the inputs that set purpose out of reach of untrusted data, attenuate on every delegation hop, and ask the human rarely enough that the asks still mean something.

OP 7.4 · Managing the authorization lifecycle

The question. How long should a credential live (§7.2, p. 34)? The sub-questions: can task length be predicted, how does the system know to revoke on completion or failure, what if a self-reporting agent crashes or lies, and can an agent get extra permissions mid-task without full re-authorization or a fresh round of consent fatigue?

Why it is hard

OAuth-style tokens have a fixed time-to-live chosen at provisioning. Agent tasks range from seconds (an email lookup) to days (a research project), and their length is often unknowable up front.

"no current system ties the credential lifecycle to the task lifecycle."— the report, §7.2, p. 34

The authorization server does not know when a task starts or ends. So a fixed TTL fails in one of two directions. Too short, and the token expires mid-task and interrupts the work for re-authorization. Too long, and a stale token keeps live permissions after the task is over. The report notes that stale credentials have enabled large-scale attacks before, citing the U.S. Department of Energy's account of the Colonial Pipeline incident. Agents make it worse by volume: they can pile up hundreds of stale tokens before a human looks, so yesterday's social-media permission is still sitting there during today's medical task.

What counts as "a task"

Even defining the unit is open. Is "plan my trip to Europe" one task, or three ("book flight," "book hotel," "arrange transport") with three credential scopes? And who announces completion? The obvious signal, the agent saying "done," is exactly the signal you cannot rely on from a component that can crash, be confused or be injected.

A way to picture this: a token that behaves like a lease on a task rather than a timer on a clock. It would be issued against a task id, narrowed to that task's purpose, renewed by some liveness signal that does not come only from the agent, and revoked when the task closes or the signal stops. The report does not propose this design; it is one shape an answer to OP 7.4 might take.

Related work the report names (p. 34): GNAP for dynamic grant negotiation, the IETF Agentic JWT draft for workflow-bound tokens, and the IETF Decoupled Authorization Model for Agent2Agent for intent-based just-in-time permissions. A note on the citation: the report's reference list resolves "Agentic JWT" to the draft titled Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow Management, the same document it cites for the "intent-execution separation problem" above and as the Secure Intent Protocol under OP 7.5.

OP 7.5 · Ensuring that an agent's action is intended by the user

The question. Can we produce verifiable artifacts that bind what an agent did to what the user originally asked for ("Buy groceries under $50"), when the model's probabilistic nature makes "faithful execution" a slippery idea? And can we standardize forensic observability so a failure can be attributed to the user (a bad prompt), the developer (a software bug) or the model (a hallucination) (§7.3, p. 35)? The report notes this depends on §7.1: you cannot account for an action you cannot first attribute to an agent and trace to a user.

Why accounting breaks

In a classic system, every action traces to an explicit user act, and the link between what the user wanted and what the system did is direct (§7.3, p. 34). An agent inserts an interpreter. The instruction is high-level and necessarily underspecified; the actions are concrete. Every detail the user did not specify (which store, which brand, which delivery slot) was decided by the agent on its own.

This produces a non-repudiation problem the report calls qualitatively different, and it cuts both ways. A user whose agent bought something after a hallucination or prompt injection wants to disown it; a merchant or bank needs to catch a user falsely blaming "agent error" to reverse a real purchase. After an incident (a fraudulent purchase, leaked data, a deleted production server) someone must reconstruct what happened, why, and who is responsible.

The intent-binding artifact

Traditional non-repudiation uses digital signatures to bind a principal to an action, and append-only signed logs such as Certificate Transparency and Trillian/Tessera give tamper-evident, publicly checkable trails. The report asks whether agents can get an equivalent that covers the whole path from instruction to action. It lists what such an artifact would need to contain, all bound together so that a third party can verify it:

intent-binding artifact
  1. user's original instruction    (authenticated by the user)
  2. agent's interpretation         (the plan or reasoning trace)
  3. the specific actions taken
  -- bound so a third party can verify all three together

Our reading of why this is hard: items 1 and 3 are ordinary signed records. Item 2 is the hard one. A reasoning trace is model output, so proving it is the reasoning that actually produced the action, rather than a plausible story written afterward, is not something a signature gives you. That is presumably why the report's related work includes zero-knowledge proofs of model inference.

Related work the report names (p. 35): Authenticated Workflows (Rajagopalan & Rao, 2026), zkML (Chen et al., 2024), zkLLM (Sun et al., 2024), the IETF Decoupled Authorization draft, the Secure Intent Protocol draft, and the Agent Payments Protocol (AP2).

What a good answer would have to do. Settle disputes in both directions and assign a failure to prompt, code or model. A log that only says "the agent called checkout()" does neither.

Connections

The fourth pillar, privacy, continues on PII, minimization, deletion, anonymity (§7.4). The reason the report gives for why all of §7 needs rethinking, the intent-specification gap, is on AI as the last-mile developer (§7.5). Model-generated policies and the rule that untrusted inputs stay away from the policy generator come from the contextual policy engine. Delegation chains where constraints get lost after the first hop return in Shared norms, delegation, composition, and MCP and A2A as channels in Protocols, attestation, side channels. Consent fatigue and audit paths for users sit on Mental models and the end of notice-and-choice and Trust, stop buttons, accountability.

Further reading, verified

• The OAuth 2.1 Authorization Framework — IETF draft (2026) · the delegated-access baseline whose coarse scopes, static consent and lack of attenuation the report critiques
• Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud — Birgisson et al. (NDSS 2014) · attenuation by construction, cited as trust-management prior art not yet applied to agents
• RFC 9635: Grant Negotiation and Authorization Protocol (GNAP) — IETF (2024) · dynamic grant negotiation, cited under OP 7.3 and OP 7.4
• Contextual Agent Security: A Policy for Every Purpose — Tsai & Bagdasarian (HotOS 2025) · Conseca, policies generated from system context (OP 7.3)
• Defeating Prompt Injections by Design — Debenedetti et al. (2025) · CaMeL, isolating a trusted planner from untrusted data (OP 7.3)
• MiniScope — Zhu et al. (2025) · computing minimal OAuth scopes for the user to approve (OP 7.3)
• Identity Management for Agentic AI — South et al., OpenID Foundation (2025) · related work for a first-class agent identity (OP 7.1)
• Authenticated Workflows: A Systems Approach to Protecting Agentic AI — Rajagopalan & Rao (2026) · related work for intent-binding (OP 7.5)