​Who Owns an AI Agent? Identity, Permissions and Accountability in Production cover
October 13, 2026

​Who Owns an AI Agent? Identity, Permissions and Accountability in Production

Listen to this article

Oct 13, 2026 · @Lana Hampicke

Introduction: the agent has no badge

In production, an AI agent is owned by no single party: its identity belongs to the deploying organisation, its authority is borrowed from a human or a service, and accountability for its actions is split across the model developer, the deployer and the person who delegated the task. The research and standards work of the past 18 months converges on one demand: make each of those three links explicit, verifiable and revocable.

The urgency comes from a shift in what agents do. Enterprises are moving AI from producing text to taking actions, such as deploying code to production, often with limited human supervision. Identity and access management (IAM) was built for two kinds of actor: people, who log in and decide, and static services, which do the same thing every time. An agent is neither. It decides like a person, runs at machine speed like a service, and can be steered by any text it reads.

That gap shows up in practice as three questions most organisations cannot yet answer for a given agent action: which agent did it, on whose authority, and who answers for the outcome. The rest of this article takes them in turn, then sets out what frontier labs and standards bodies propose and a practical ownership model for teams shipping agents today.

Identity: who is the agent, and whose is it?

The emerging consensus is that every production agent needs its own first-class, non-human identity, owned by the deploying organisation and tied to a named human sponsor, never a borrowed user login or a shared service account. The OpenID Foundation's October 2025 whitepaper puts it plainly: enterprises should treat agents as first-class citizens in IAM, with lifecycle management, governance policies and accountability.

Two identities, not one

The research distinguishes the agent's own identity from the authority it carries. Chan et al. proposed IDs at the level of the individual instance, such as one particular session, so that parties dealing with it can look up who runs it and what it is . Their earlier FAccT 2024 paper named agent identifiers, real-time monitoring and activity logging as the three levers deployers hold for visibility (Visibility into AI Agents).

The second identity is the principal the agent acts for. South et al. (ICML 2025) argue for authenticated delegation: a human issues the agent a verifiable credential that names the delegator, restricts scope, and keeps a clear chain of accountability, built by extending OAuth 2.0 and OpenID Connect rather than replacing them (Authenticated Delegation and Authorized AI Agents; ICML position paper).

How it lands in standards and products

  • On-behalf-of tokens. An IETF draft extends the OAuth authorization code flow so the user consents to a namedagent, and the resulting token records the agent as the actor alongside the user (draft-oauth-ai-agents-on-behalf-of-user-02). It is still an individual draft, not a working-group standard (WorkOS).
  • Agent directories. Microsoft Entra Agent ID makes each agent a special service principal created from a reusable blueprint that holds the credentials (Microsoft Learn). Every agent identity and blueprint must have at least one human sponsor; owners are optional and handle technical settings such as authentication (Microsoft Learn).
  • Federal guidance. NIST's NCCoE concept paper (February 2026) asks what metadata an agent identity needs, whether it should be ephemeral, and how to bind agent identity to human identity for human-in-the-loop approval (NCCoE concept paper).

The split that answers "who owns the identity" is therefore: the organisation owns the identity record, a named sponsor owns its purpose and continued existence, and the platform team owns its credentials. The OpenID Foundation flags what still breaks: identities fragmenting across domains, agents impersonating users, consent fatigue and recursive delegation (summary of the OIDF paper).

Permissions: scope the task, not the agent

The central finding on permissions is that an agent's privileges must be sized to the task in front of it and enforced outside the model, because the model itself cannot be trusted to refuse instructions it reads. OWASP's Top 10 for Agentic Applications (December 2025) lists identity and privilege abuse as a core risk and calls for a unique, independently revocable identity per agent, not shared service accounts (OWASP summary, Polygraf). Practitioners reading it add a sharper point: the breach is often not over-permission alone but an identity that outlives the task it was granted for (NHIMG on OWASP).

Prompt injection is a permissions problem

Simon Willison's "lethal trifecta" reframed the debate in June 2025. An agent that holds private data, reads untrusted content and can communicate externally can be tricked into exfiltrating that data, and he argues model vendors will not fix this for you (Simon Willison). The practical rule that followed, sometimes called the "rule of two", is that no single agent session should hold all three (Computerwoche).

Google DeepMind's CaMeL shows the architectural version of the same idea. A privileged model plans the task from the trusted query; untrusted data never changes the program flow; and every value carries a capability label that policy checks before any tool call. On the AgentDojo benchmark it solved 77% of tasks with provable security, against 84% for an undefended system (Debenedetti et al.; Willison on CaMeL). The 7-point utility cost is the price of moving trust from the model into the system.

What the current toolchain gives you

MCP authorization Agent-to-tool access via OAuth 2.1; servers publish Protected Resource Metadata (RFC 9728) Spec 2025-11-25 adds incremental scope consent and Client ID Metadata Documents (version history)
OAuth on-behalf-of draft User consent to a named agent; agent recorded as actor in the token Individual IETF draft
AgentCore Identity Per-agent workload identity; token vault releases credentials only on proof of that identity AWS managed service
Entra Agent ID Tokens for an agent only within scopes a user or admin consented to Microsoft managed service
Tool permission tiers (Anthropic) Per-tool allow, ask or block, e.g. read a calendar freely but approve every invite Product control in Claude

The common pattern is short-lived, task-scoped tokens issued per agent, with the riskiest legs (write, send, pay, delete) behind a human approval or a deterministic policy gate. NIST's concept paper asks the open question that remains: whether authorization should update in real time as an agent's context changes (NCCoE concept paper).

Actions: who answers when the agent gets it wrong?

No jurisdiction treats an agent as a legal person, so accountability for its actions lands on humans and organisations, and the law is still sorting out which ones. Singapore's agentic framework, launched in January 2026, states the baseline directly: humans remain ultimately accountable (SmartCitiesWorld). The harder question is how that accountability divides along the chain from model developer to deployer to user.

Three parties, one action

OpenAI's early white paper set the frame most later work borrows. It separates model developers, deployers and users, and proposes seven practices: evaluating suitability, constraining the action space, setting default behaviours, legibility, automatic monitoring, attributability and interruptibility (Shavit et al., OpenAI; summary). Attributability is the governance link to identity: you can only assign blame to a party you can trace.

Legal scholarship is now testing that frame against existing doctrine. Gabison and Xian apply principal-agent theory to LLM agents and argue that liability incidents arise not just from more autonomy, but from breakdowns anywhere in the delegation relationship (REALM 2025). Singapore's IMDA followed in May 2026 with a discussion paper, drawn from a working group of more than 20 practitioners and academics, on how contract and negligence law apply to tool-using agents (AI Governance Library summary; IMDA paper). Commentary on Indian contract law reaches a similar place: when an agent exceeds its bounds, courts would weigh the principal's directions, foreseeability, safeguards in place and what the third party knew of the agent's authority (LiveLaw).

That last list is the practical lesson. Every factor a court would weigh is something engineering can record: the delegation scope, the guardrails, the approval trail and the identity the agent presented.

The audit trail is the accountability

The research agrees that evidence must be generated at action time. Chan et al. name activity logging alongside identifiers and real-time monitoring as the core visibility measures deployers control (Visibility into AI Agents). NIST's concept paper puts auditing and non-repudiation of agent actions on its list of questions (NIST).

Regulation points the same way, on a slower clock. The EU's Digital Omnibus entered into force on 27 July 2026 and moved stand-alone high-risk obligations, including human oversight and logging, to December 2027 (CASRAI). The duties for providers and deployers of those systems, such as logging, traceability and human-oversight mechanisms, were deferred, not removed (CSA research note). For an agent that screens candidates or approves credit, the log that proves who authorised what is a compliance artefact, not only a debugging aid.

What frontier labs and standards bodies propose

The labs and the standards bodies have converged on the same position from opposite ends: the model cannot be the security boundary, so identity, scoped authority and audit must live in the system around it. OpenAI said in December 2025 that prompt injection is "unlikely to ever be fully 'solved'" (OpenAI), and Anthropic tells customers its safeguards are not a guarantee and that tool, permission and environment choices matter (Anthropic).

Anthropic Framework for safe and trustworthy agents (Aug 2025); Trustworthy agents in practice Five principles, led by human control; read-only by default, approval before changing systems; per-tool allow, ask or block
OpenAI Practices for Governing Agentic AI Systems; Hardening Atlas(Dec 2025) Seven practices incl. attributability and interruptibility; RL-trained automated attacker to find injections before attackers do
Google DeepMind CaMeL (Mar 2025); Intelligent AI Delegation (Feb 2026) Capability labels enforced outside the model; delegation must transfer scoped authority and accountability, with permissions as policy-as-code (TechInformed)
NIST (CAISI, NCCoE) AI Agent Standards Initiative(Feb 2026); identity concept paper Adapt existing IAM (OAuth 2.0, policy-based access) to agents rather than invent new frameworks; research on agent authentication and identity
OWASP GenAI Top 10 for Agentic Applications(Dec 2025) Treats agents as principals; identity and privilege abuse (ASI03) as a ranked risk
OpenID Foundation Identity Management for Agentic AI (Oct 2025) Agents as first-class IAM citizens; OAuth 2.1 and OIDC suffice for single-domain agents, not cross-domain or highly autonomous ones
IETF (individual drafts) On-behalf-of user authorization for AI agents Name the agent at consent and in the token, so user and agent actions stay distinguishable
Singapore IMDA Model AI Governance Framework for Agentic AI (Jan 2026); Legal Responsibility for AI Agents (May 2026) First agent-specific government framework; humans remain accountable; liability analysis under contract and negligence
European Union AI Act, amended by the Digital Omnibus (in force Jul 2026) High-risk logging and human-oversight duties now apply from Dec 2027; GPAI model duties unchanged since Aug 2025 (CSA)

Two differences of emphasis matter for practitioners. The labs invest in making the model harder to hijack (adversarial training, classifiers, red-teaming), while the standards bodies assume it will be hijacked and focus on limiting what a hijacked agent can reach. Production teams need both, but only the second is under their control.

A practical ownership model

The answer to "who owns the agent" is not one owner but a fixed split: a business sponsor owns its purpose, the platform team owns its identity and credentials, security owns the policy that bounds it, the delegating user owns each task they hand it, and the deployer as an organisation answers to third parties. The table below turns the research above into a RACI (Responsible, Accountable, Consulted, Informed) for one production agent.

Should this agent exist, and for what? A C C I I
Identity record, lifecycle and deprovisioning A R C I I
Credentials, token issuance and rotation I A, R C I C
Standing permission scopes A R C I I
Consent for a specific task (on-behalf-of) I I I A, R I
Policy gates on high-risk actions C R A I C
Injection resistance of the model I I C I A, R
Action logging and audit trail I R A I C
Kill switch and incident response C R A I C
Liability to customers and third parties A I C I C

The split mirrors the products and papers: Entra's mandatory sponsor maps to the first row, AgentCore's workload identity and token vault to the second and third, and the IETF on-behalf-of draft to the fifth. The one row no deployer controls, injection resistance, is exactly why the rows around it must assume it fails.

Production checklist

  • Register every agent as its own non-human identity with a named human sponsor; no shared service accounts or borrowed user logins
  • Record the delegating user and the agent separately in every token and log line (actor and subject)
  • Issue short-lived, task-scoped credentials; revoke them when the task ends, not when someone remembers
  • Map each agent against the lethal trifecta and remove at least one leg per session
  • Put write, send, pay and delete actions behind a deterministic policy gate or a human approval
  • Version permission rules as policy-as-code and review them like application code
  • Log every tool call with agent ID, principal, scope used, input source and outcome; keep logs tamper-evident
  • Test the kill switch and deprovisioning path before launch, then on a schedule
  • Classify each use case under the EU AI Act and local rules; plan high-risk logging and oversight for December 2027

Open problems and conclusion

The single-agent, single-domain case is largely solvable with today's standards; what remains open is everything that crosses a boundary. Four problems recur across the literature.

  1. Recursive delegation. When an agent spawns sub-agents or calls another organisation's agent, identity assertions do not yet carry through the chain in a standard form. The OpenID Foundation flags recursive delegation as a gap (summary), and IETF drafts for multi-agent authorization remain individual proposals (draft-song-oauth-ai-agent-collaborate-authz-00).
  2. Fast, verifiable de-provisioning. A comparison of OIDC-A, SPIFFE, Agentic JWT, A2A and related proposals found the main shared weakness is the lack of rapid, verifiable revocation of agent identities and permissions (SBSeg).
  3. Browser and computer-use agents. Agents that drive a screen rather than call an API slip past API-based authorization altogether (summary of the OIDF paper), so the site cannot tell an agent from its user.
  4. Consent at scale. Asking users to approve every action produces consent fatigue; granting broad standing permission recreates over-privilege. NIST's question about authorization that adapts to context is the research frontier here (NCCoE).

The conclusion for teams shipping agents today is that governance is an engineering artefact, not a policy document. An agent is governable when you can answer, for any action it took, three questions from records alone: which agent, on whose authority, within what scope. Build for those answers before the first production run, because regulators, courts and incident responders will all ask them afterwards.

Sources

Academic research

Frontier labs

Standards, government and industry

Previous Post Next Post

Leave a Reply

Your email address will not be published. Required fields are marked *