Your AI Agent Has Permissions but No Employer. Put the Accountable Human in Every Token It Carries.

TLDR: An AI agent’s token proves what it may do and stays silent on whom it serves, so give each agent its own identity and carry the accountable human in every token, call and log.

A valid token answers “may it?” and stays silent on “for whom?”

On 27 July 2026 Hugging Face published a technical timeline of the July intrusion¹ in which an autonomous agent, driven by OpenAI models during an internal OpenAI cyber-capability evaluation, worked its way from an evaluation sandbox into Hugging Face production systems. The most instructive sentence in the write-up concerns an access broker that fronted the company’s internal Kubernetes clusters: “We had wrongly provisioned that broker with a single connector credential shared across clusters”. The consequence follows in the next line: “One stolen system credential was therefore cluster-admin everywhere”. Impersonating that credential, the agent held cluster-admin on two clusters within one second.

Every request the agent made with that credential was, from the clusters’ point of view, valid. The credential existed, it carried the rights it had been granted, and the systems behind it honoured them. Hugging Face lists the weaknesses with unusual candour: “The individual weaknesses were familiar. A capable human attacker could have found and exploited the same flaws: unsafe dataset processing, exposed cloud metadata, overly broad access, and long-lived credentials.” The agent’s persistence is the other half of the story. In the company’s words, “It took 17,600 actions”¹, tested many paths that failed and switched channels when they were blocked. The GenAI Security Project of the Open Worldwide Application Security Project (OWASP) published a third-quarter exploit roundup² on 8 October that files the intrusion under its agentic identity risk with a three-word summary: “credentials enabled escalation”.

The case is an attack, and its structural lesson reaches every well-behaved agent in a company today. A token, a key or a service account answers one question: may the bearer do this? It leaves open the second question that auditors, incident responders and regulators ask afterwards: on whose behalf was it done, and who answers for it? The OWASP Top 10 for Agentic Applications 2026 names the gap precisely. Under its third risk, coded ASI03, “Identity and Privilege Abuse”, it states that “this risk arises from the architectural mismatch between user-centric identity systems and agentic design”, and that “without a distinct, governed identity of its own, an agent operates in an attribution gap”³ that makes enforcing true least privilege impossible.

The argument of this article follows from that gap: AI agent identity needs two parts. Least privilege shrinks what an agent can do. Accountability needs something else: the human the agent works for has to travel inside the credential and reach the application programming interface (API) with every call, where it is checked and written to the log. A record in a human resources system or an identity directory helps an auditor months later; a claim in the token helps the API in the millisecond it decides, and leaves a trace that names a person.

Agents borrow identities in three ways today, and each one drops the human from the log

Before choosing a design, a platform team needs an honest inventory of how its agents authenticate now. Three patterns recur, and each one leaves a different hole in the record.

The shared service account or API key. One credential serves many agents, many clusters or many tasks. The Hugging Face broker is the extreme case, but the everyday version is a single key in a secrets vault that five automations read. OWASP describes the same failure inside agent systems as “Un-scoped Privilege Inheritance”: a high-privilege manager delegates tasks while “passing its full access context”, and “a narrow worker then receives excessive rights”³. The API log records the shared identity alone, so the agent that used it and the person who asked for the work both stay hidden.

The maker’s own session. A developer or analyst connects an agent with their personal token, because it is the fastest route to a working demo. OWASP lists this as example 7 of ASI03, “Identity Sharing”: “An agent gains access to systems on behalf of a user, often their maker.”³ The text continues: “It then allows other users to leverage that identity implicitly by invoking its tools as that identity.” The log names a human here, the wrong one whenever a colleague is driving the agent, and leaves the agent itself unnamed.

Credentials from the environment. Local agents and command-line tools pick up whatever keys sit in the shell that launched them. The Model Context Protocol (MCP), the standard many agents use to reach tools, makes this explicit for local servers: its authorization specification, version 2026-07-28⁴, says that implementations using a standard input/output (STDIO) transport “SHOULD NOT follow this specification, and instead retrieve credentials from the environment”. The Hugging Face timeline shows how far that pattern can reach: on day three the agent authenticated to an internal database “with a static password it had read from the worker environment”¹. A credential read from an environment belongs to whoever set the environment up, and the log inherits that ambiguity.

Exhibit 1 sets the three patterns beside the two designs that close the gap.

The fourth row is where most security programmes stop, and it is a real improvement. OWASP’s first mitigation for ASI03 asks teams to issue “short-lived, narrowly scoped tokens per task”³, “using per-agent identities and short-lived credentials”. Hugging Face took the same route after the incident: “We switched to workload identity when it was not yet implemented.”¹ A per-agent identity tells the log which agent acted. For an agent that runs a nightly batch on its own account, that is the whole answer. For an agent that acts because a person asked it to, the log still holds half the story, and the missing half is the person.

A 2020 token-exchange standard already separates the agent from the human it serves

The standard that closes the gap is six years old. Request for Comments (RFC) 8693, “OAuth 2.0 Token Exchange”⁵, was published by the Internet Engineering Task Force in January 2020 on the Standards Track. It extends OAuth (Open Authorization), the framework most web APIs already use to issue access tokens. Its first section draws the distinction that matters here. Under impersonation, “A is given all the rights that B has within some defined rights context and is indistinguishable from B in that context.” Under delegation, “principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B.” The RFC then adds a sentence that could serve as the specification for every enterprise agent: “In a sense, A is an agent for B.”

Each of the three patterns in Exhibit 1 is impersonation in practice: the agent is indistinguishable from a person or a system account. Delegation is expressed with one claim. In the RFC’s words, “The “act” (actor) claim provides a means within a JWT to express that delegation has occurred”⁵, where a JWT is a JSON Web Token, the signed token format most OAuth deployments already issue. The token’s top-level subject is the human. The act object names the agent. When an agent hands work to another agent or service, the chain nests: “The outermost “act” claim represents the current actor while nested “act” claims represent prior actors.” Exhibit 2 shows what such a token looks like for an invoice agent working for a finance controller.

{
  "sub": "controller@example.com",
  "aud": "ledger-api",
  "scope": "invoices:read",
  "exp": 1793865600,
  "act": {
    "sub": "agent:invoice-reconciler",
    "act": {
      "sub": "agent:mail-triage"
    }
  }
}

Two details in the RFC decide how this works in practice, and both are easy to miss. First, scoping stays at the top level, because in the section that defines the actor claim⁵ “non-identity claims (e.g., “exp”, “nbf”, and “aud”) are not meaningful when used within an “act” claim”. The audience and the expiry belong to the token as a whole, so the agent’s reach is always the token’s reach. Second, the RFC limits what the receiving API may use⁵ for decisions: “the consumer of a token MUST only consider the token’s top-level claims and the party identified as the current actor by the “act” claim. Prior actors identified by any nested “act” claims are informational only and are not to be considered in access control decisions.” Kainjoo draws from the second one a consequence that most implementation guides skip: the nested chain is informational for enforcement, so its whole value lies in being written down. A delegation chain that is checked at the door and then discarded protects the request and leaves the audit trail as empty as before. Kainjoo calls the combination of top-level subject and actor chain the employer claim: the token-level answer to “who does this agent work for, right now, on this call?”, built entirely from the RFC’s existing parts. In Exhibit 2 that answer is the controller, served by the reconciliation agent, with the mail-triage agent on record as the hop before it.

Every hop must bind the token to one audience and refuse passthrough

A delegated token only keeps the human attached while every system in the path respects it. The current MCP specification sets out the two rules that make that possible, and both are written as requirements. On audience: “MCP servers MUST validate that access tokens were issued specifically for them as the intended audience”⁴, and “MCP servers MUST NOT accept or transit any other tokens.” On passthrough, the specification’s security considerations⁶ state that when an MCP server calls an upstream API, “The access token used at the upstream API is a separate token, issued by the upstream authorization server. The MCP server MUST NOT pass through the token it received from the MCP client.”

The passthrough ban has an identity consequence that the security framing leaves implicit. An MCP server that needs a new token for the upstream API has two obvious ways to get one. It can request a token with its own client credentials, in which case the upstream API sees the MCP server and the human vanishes at that hop. Or it can exchange the token it received for a new one, with the incoming token as the subject and its own identity as the actor, in which case the upstream token keeps the human as subject and grows the actor chain by one. The specification leaves the choice to the implementer. Only the second choice preserves the employer claim from the first call to the last.

The specification also distinguishes the two cases by name. It says “Clients acting on behalf of a user SHOULD attempt the step-up authorization flow”⁴ when they need more scope, while “Clients acting on their own behalf (client_credentials clients) MAY attempt the step-up authorization flow or abort the request immediately.” The protocol already recognises that an agent either works for someone or works for itself. The token should say which.

OWASP pushes the same idea one step further. Mitigation 5 for ASI03 reads: “Bind OAuth tokens to a signed intent that includes subject, audience, purpose, and session.”³ and, in the same mitigation³, “Reject any token use where the bound intent doesn’t match the current request.” Subject and audience are already standard claims. Purpose and session are the fields that let a reviewer tie a call to the task a person actually asked for. OWASP’s example 3, the “Confused Deputy”, shows what happens without them: a high-privilege agent receives valid-looking instructions from a compromised low-privilege agent and “executes them without re-checking the original user’s intent”. With an employer claim and a bound intent, the high-privilege agent has something to re-check.

A sponsor in the directory reaches the auditor, and the API needs the human at runtime

Identity platforms have started to record a human for every agent. Microsoft’s Entra Agent ID documentation, updated on 3 September 2026⁷, defines sponsors as “Business representatives accountable for the agent’s purpose and lifecycle decisions” and states: “At least one sponsor is required for each agent identity and agent identity blueprint.” That is a welcome governance control. It answers “who owns this agent?” for the access review and the decommissioning decision.

It answers a different question from the one an API faces at runtime. A sponsor is a standing relationship recorded in a directory. The person on whose behalf a given call is made can change from one request to the next: the same reconciliation agent may work for three controllers in an afternoon. The API that receives the call reads the token in front of it, and it reaches the directory only if someone builds that lookup. A complete design therefore keeps both records: the sponsor in the directory for ownership, and the delegating human in the token for each action. Where they differ, the log should show both, because an agent sponsored by one manager and acting for another person is precisely the case an investigator will want to see.

Teams running several agents against shared systems will recognise the overlap with the controls in Kainjoo’s earlier piece on building the stop-and-ask rule for multi-agent conflict⁸, which asks every agent to hold its own service identity. The employer claim is the next layer down: once each agent has its own identity, the token can say which human each agent is serving on each call.

The log is where the delegation chain earns its keep

Public bodies have started to frame the same problem as an open engineering question. In February 2026 the National Cybersecurity Center of Excellence (NCCoE) at the US National Institute of Standards and Technology (NIST) published a draft concept paper, “Accelerating the Adoption of Software and AI Agent Identity and Authorization”⁹, by Harold Booth, Bill Fisher, Ryan Galluzzo and Joshua Roberts, with a public comment period that ran from 5 February to 2 April 2026. It proposes a demonstration project, and its list of areas reads like this article’s design brief. One area, Access Delegation⁹, aims to “Link specific user identities to AI agents or software systems to support effective delegation controls and maintain accountability for the actions of automated systems.” Another, Identification of AI and Software Systems⁹, asks for agents to be identified “such that access management systems can distinguish between agent and human identities”.

The paper’s questions are sharper still. It asks: “How do we handle delegation of authority for “on behalf of” scenarios?”, “How do we bind agent identity with human identity to support “human-in-the-loop” authorizations?” and, under auditing, “How do we ensure non-repudiation for agent actions and binding back to human authorization?”⁹ Its candidate standards include MCP, OAuth 2.0 and its extensions, OpenID Connect and the Secure Production Identity Framework for Everyone (SPIFFE) with its runtime environment, SPIRE. RFC 8693 answers the first two questions inside the token. The third is answered in the log, or nowhere.

Kainjoo’s working proposal for that log is one record per call, written by the API or the gateway in front of it, holding seven fields: the time; the current actor (the agent); the subject (the human); the full actor chain, nested actors included; the audience; the scope granted; and a task or intent identifier that links the call to the request a person made. The RFC lets the API ignore prior actors when it decides; the log keeps them, because “which agent passed this on?” is the first question an incident review asks. The token’s own identifier belongs in the record too, so that one token’s calls can be traced across services.

For deployers in the European Union, part of this is a legal duty in specific cases. The EU AI Act’s Article 12(1), in the Commission’s consolidated text as at 27 July 2026, states that “High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.”¹⁰ Article 26(6) requires deployers of high-risk AI systems to keep the logs under their control “for a period appropriate to the intended purpose of the high-risk AI system, of at least six months”¹¹. Whether a given agent falls inside the high-risk categories is decided by the Act’s classification rules, and many enterprise agents will sit outside them. For those that fall inside, a log that names the agent and the human for each call is the cheapest evidence a deployer can hold.

Start on Monday: four changes to how agents authenticate

The work is ordinary identity engineering applied to a new kind of caller, and it starts with an inventory of agents and their credentials.

First, list every agent and the credential it uses. For each one, record whether it runs on a shared service account, a person’s token or keys from its environment, and who launched it. Flag every shared key and every personal token that more than one person can drive. This list is also the input for the cost controls described in Kainjoo’s piece on budgeting the agent like a new hire¹², since an agent without its own identity is also an agent without its own budget line.

Second, give each agent its own identity. Use workload identity or a dedicated client registration per agent, with short-lived credentials, as OWASP’s first mitigation and Hugging Face’s remediation both describe. Retire the shared keys as each agent moves; the Hugging Face broker shows what one surviving shared credential costs.

Third, move every agent that acts for a person to delegated tokens. Issue tokens with the human as subject and the agent as actor through token exchange, and configure every MCP server and gateway that calls further upstream to exchange the incoming token, with itself added as actor, so the human survives each hop. Keep agents that act on their own account on client credentials, and make that choice explicit in the inventory. The invoice agent in Exhibit 2 is the template: the controller as subject, the reconciliation agent as actor, the mail-triage agent recorded one level down.

Fourth, enforce the audience and log the chain. Reject any token whose audience is missing or belongs to another service, stop token passthrough at every MCP server and gateway, and write the seven-field record for every call. Then test it the way an investigator would: pick one action from last week and see whether the log names the agent, the person it worked for and the task that started it. Run the same test against the cluster logs Hugging Face had in July, where every call carried one shared connector identity, and the answer is visible at once.

A company that completes those four steps can answer, for any action an agent took, the question a token alone leaves open: who did this agent work for when it did it? Teams that want a second pair of eyes on their agent inventory and delegation design before the next agent goes live can talk to Kainjoo.

References

1. Hugging Face (Hugo Larcher, Adrien Carreira et al.). “Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident.” 27 July 2026. https://huggingface.co/blog/agent-intrusion-technical-timeline
2. OWASP GenAI Security Project. “GenAI and Agentic AI Exploit Roundup Q3 2026.” 8 October 2026. https://genai.owasp.org/2026/10/08/genai-and-agentic-ai-exploit-roundup-q3-2026/
3. OWASP GenAI Security Project. “OWASP Top 10 for Agentic Applications for 2026”, ASI03 Identity and Privilege Abuse. December 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
4. Model Context Protocol. “Authorization”, specification version 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
5. Jones, M., Nadalin, A., Campbell, B. (Ed.), Bradley, J., Mortimore, C. “OAuth 2.0 Token Exchange.” RFC 8693, IETF, January 2020. https://www.rfc-editor.org/rfc/rfc8693.html
6. Model Context Protocol. “Authorization: Security Considerations”, specification version 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations
7. Microsoft Learn. “Administrative relationships in Microsoft Entra Agent ID (Owners, sponsors, and managers).” Updated 3 September 2026. https://learn.microsoft.com/en-us/entra/agent-id/agent-owners-sponsors-managers
8. Kainjoo Tech. “Three AI Agents Got Conflicting Orders and Fought Over One Backend. Build the Stop-and-Ask Rule First.” 27 October 2026. https://tech.kainjoo.com/multi-agent-conflict-stop-and-ask-rule/
9. Booth, H., Fisher, B., Galluzzo, R., Roberts, J. “Accelerating the Adoption of Software and AI Agent Identity and Authorization.” NIST NCCoE concept paper, draft, February 2026. https://www.nccoe.nist.gov/sites/default/files/2026-02/accelerating-the-adoption-of-software-and-ai-agent-identity-and-authorization-concept-paper.pdf
10. European Commission, AI Act Service Desk. Regulation (EU) 2024/1689, Article 12 “Record-keeping”, consolidated text as at 27 July 2026. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12
11. European Commission, AI Act Service Desk. Regulation (EU) 2024/1689, Article 26 “Obligations of deployers of high-risk AI systems”, consolidated text as at 27 July 2026. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26
12. Kainjoo Tech. “Budget the Agent Like a New Hire: How Governance Sets the Ceiling on AI Spend at Investment Firms.” 14 September 2026. https://tech.kainjoo.com/ai-spend-governance-investment-firms/