If you enjoy our content, please consider subscribing to support our work and receive quality articles from industry professionals delivered every week.
Explore the latest articles contributing to the discussion around agents, agent ecosystems, and enterprise AI:
Anthropic’s Zero Trust Agents: Authenticated, Sandboxed, and Still Dangerous: https://agenticmesh.substack.com/p/anthropics-zero-trust-agents-authenticated
Skills or Tools, Which Should an Agent Use?: https://agenticmesh.substack.com/p/skills-or-tools-which-should-an-agent
Article: Agent Identity - The Foundation for Secure Agents
Agents are doing real work under user accounts, shared credentials, and names nobody owns. When something goes wrong, the enterprise may see the action (and outcome) but not the agent behind it.
Enterprise agents are starting to do real work before many enterprises can answer a basic question: which agent did it? Some agents were never registered. Some act through user credentials or shared service accounts (for example, coding agents like Claude Code or personal agents like OpenClaw). Others have no clear owner. When an invoice is approved, a case is closed, a workflow is triggered, or an output is released, the enterprise may see the action (and potentially, the negative outcome), the tool call, or the token, but not the actor.
That means agents have an accountability problem. An agent that does real work needs an identity the enterprise can manage. Without that identity, the organization cannot assign ownership, limit eligibility, suspend the agent, or reconstruct what happened later.
When Agents Become Unaccountable Actors
The issue often starts with coding assistants, personal productivity agents, browser agents, and local tools that act through a user’s account. They can read files, call APIs, generate code, update tickets, query systems, or prepare outputs that later enter production workflows. These tools may be visible under a person, but the enterprise still loses the separate agent record: which tool acted, which version ran, what it was allowed to do, and what evidence remains.
The control problem grows when agents move out of the user’s workspace and into business processes. A company may end up with thousands, or eventually millions, of agents reviewing invoices, routing cases, checking policy, reconciling data, and preparing releases. At that point, the agent is a software actor inside the operating model, often running through service accounts, queues, schedulers, and tool services.
An enterprise cannot suspend or investigate an agent it never registered as its own actor. Anonymous processes, hidden user extensions, shared service accounts, and local tools with inherited credentials create work that looks legitimate in logs but has no identifiable or governed agent behind it. If a business-process agent can change records, move work through a queue, make recommendations, call tools, and produce outputs that other systems consume, the enterprise needs to know whether the agent was allowed to do the work, who owns the behavior, and which running instance took the action. In April 2026, the Cloud Security Alliance reported that “nearly all organizations (82%) have unknown AI agents running in the IT infrastructure.”[1] Auth0 gives the same operational guidance: “Instead of letting an agent “borrow” a user’s session or identity, it needs its own managed identity.”[2]
Figure 1, Agents Running Wild
Agent identity has to capture two requirements at once: accountability for the work and governance of the software artifact. Accountability means the enterprise knows the business owner, process owner, approved task classes, and decision trail. Software governance means it knows the version, runtime binding, lifecycle state, capabilities, credentials, and deployment context. A user account hides the agent as a software actor. A shared service account hides the business accountability attached to the work. Huang and coauthors describe traditional IAM as “fundamentally inadequate for the dynamic, interdependent, and often ephemeral nature” of agents in multi-agent systems.[4]
The enterprise has to treat the agent as its own governable participant. The registry should show who owns the agent, which version is approved, where it may run, which credentials it may present, and how to suspend it when trust is withdrawn.
What an Agent Identity Must Contain
An agent identity gives services and auditors a durable profile for the actor. It records what the agent is, who owns it, where it can run, and what kinds of work it may be eligible to do. Other controls depend on that profile: a credential proves the caller is presenting the identity, a role may describe broad eligibility, and a task grant authorizes one execution.
The agent registry is the book of record for agent identity. At minimum, it should store a canonical agent ID, human-readable name, agent class or type, version, owner, process owner, tenant, environment, runtime binding, lifecycle state, eligible task classes, capability declarations, credential references, and audit metadata.
Those fields give the enterprise the facts that authentication cannot provide. A valid credential can prove that a caller presented an identity. It cannot tell the enterprise whether the right version is running, who is accountable for the process, where the agent is allowed to operate, which classes of work it may receive, which runtime may present its credentials, or whether the agent is active, suspended, deprecated, retired, or revoked.
Agent failures rarely fall neatly into one team. The business owner is accountable for the process or class of work. The technical owner is accountable for implementation, deployment, versioning, and operational health. If those responsibilities are blurred, incident response can stall on the most practical question in the room: who has the authority and context to suspend, patch, or retire the agent?
The identity also has to be separate from any single running instance. The registry may describe agent:invoice-reviewer:v2, while production may run many concurrent instances of that agent across tasks, tenants, or worker pools. Audit needs both levels: the durable agent identity and the specific runtime instance that acted. Instance metadata should include runtime ID, host or workload identity, deployment version, session ID, task ID, start time, and termination state.
Without that separation, the enterprise may know which agent class misbehaved but not which running process took the action.
How Agent Identity Is Created and Managed
Agent identity needs a lifecycle because production agents change after approval. A useful lifecycle includes requested, registered, qualified, approved, active, suspended, deprecated, retired, and revoked.
Creation begins before the agent receives production work. The enterprise needs to decide who can request an agent identity, who approves it, who owns it, how its capabilities are declared, how task eligibility is assigned, how credentials are provisioned, and how the first version is qualified.
Those lifecycle states should act as control points, not labels that sit unused in a database. A suspended agent should stop receiving new work. A deprecated version should stop receiving grants after the migration window. A revoked agent should have its credentials rejected, its runtime binding blocked where needed, and any active task authority reviewed under the relevant risk policy.
During operations, suspended, deprecated, and revoked should lead to different controls. Suspended means the agent may return after review, but new work stops now. Deprecated means the enterprise is moving away from a version and should block new grants after the migration window. Revoked means trust has been withdrawn: credentials fail, runtime bindings are blocked where needed, and existing authority is reviewed or terminated.
Initial authority should stay narrow. A capable agent should not enter production because it can call a tool or complete a demo workflow. Before production work begins, the enterprise should record the business owner, technical owner, approved task classes, version, runtime binding, credential plan, policy review, test evidence, and audit setup. Broader authority should come later through task-scoped grants and runtime enforcement.
Agents change after they enter production. New versions add capabilities. Owners move. Eligible tasks expand or shrink. Credentials rotate. Trust can be withdrawn after an incident or policy change. If the identity model cannot represent those shifts, production will accumulate stale, orphaned, or overprivileged agents.
A stale invoice-review agent shows how quickly the issue becomes operational. If the business owner changed, the old version stayed active, and the agent can still call a payment-routing tool, a routine classification error can become a financial control failure. During the incident, the enterprise needs to know which registered agent acted, which version ran, which owner was accountable, and why the runtime was still eligible for the task.
The Employee Lifecycle Pattern
The employee lifecycle gives enterprises a useful pattern because it already connects identity to accountability. Before a person receives production access, the enterprise verifies the identity, assigns a manager, defines the role, provisions access, records approvals, evaluates readiness, and creates a path for later changes. Agents need similar discipline, adjusted for software actors rather than people.
Figure 2, Agent Identity vs Employee Identity
Onboarding registers the agent, assigns business and technical owners, approves the initial version, defines eligible task classes, binds the agent to an approved runtime, provisions credentials, records policy review, and establishes audit capture before production work begins.
After onboarding, evaluation keeps the identity current. A new version, capability change, owner change, runtime change, policy exception, incident, or material shift in task behavior should trigger review. Evaluation evidence should include test results, approved task classes, known limitations, incident history, risk posture, and any conditions attached to continued operation.
Offboarding or retirement has to leave the enterprise with control and evidence. The enterprise should disable the identity for new work, stop new grants, revoke or rotate credentials, block runtime bindings where needed, and preserve the audit record. The agent identity in the registry should outlast the running agent, the runtime instance, and the deployed version so the enterprise can reconstruct actions later for audit, incident response, regulatory review, or legal discovery.
How an Agent Proves Its Identity
A registry entry does not prove who is calling at runtime. The receiving service needs to verify that the presenting caller is the registered agent or an approved runtime acting for that agent.
Long-lived API keys are a poor fit for this model. They are hard to bind to a runtime instance, hard to rotate safely, and often survive beyond the agent version or task that justified them.
Governed agents should prove identity through enterprise-issued credentials: a workload identity, mTLS certificate, OAuth2 client credential, signed JWT, SPIFFE/SPIRE identity, or equivalent short-lived credential issued by a trusted identity provider. Stronger patterns use signed tokens, audience restrictions, issuer validation, key rotation, workload binding, and short expiry. Aembit describes the resulting credentials as “short-lived, often expiring in minutes rather than months.”[3]
The receiving service should verify issuer, signature, audience, expiry, subject, tenant, runtime binding, and revocation status before accepting the agent as known. That check establishes the caller’s identity. It does not authorize the work.
Credential verification and task authorization answer different questions. Identity says which registered agent is calling. The task grant, discussed in the next article in the series, says whether that agent may retrieve a skill, call a tool, publish to a route, or release an output for a specific execution.
When identity, authorization, and enforcement collapse into one token, standing privilege returns under a new name. The token becomes both proof of identity and permission to act, which makes authority harder to limit to one task, one tenant, one policy context, and one time window.
How Agent Identity Is Used at Runtime
At runtime, identity lets services attach an action to a known agent instead of a loose credential. Services use identity to authenticate the agent, check lifecycle state, evaluate task eligibility, bind the agent to a tenant or environment, and write the audit record. Trust Authority also uses identity when deciding whether to issue a task-scoped grant.
Multi-agent workflows make identity harder because delegation can blur accountability. Identity has to follow the work through every node rather than stopping at the parent orchestrator. When an orchestrator delegates work, the subagent should present its own identity and receive its own derived task authority. OWASP defines the risk directly: “Identity & Privilege Abuse exploits dynamic trust and delegation in agents.”[5] Tallam describes the broader authorization problem as “transitive delegation, aggregation inference, and temporal validity.”[6]
The parent identity remains part of the execution lineage, but it should not become a credential that the child inherits. Audit should show the parent agent, child agent, delegation event, derived grant, and actions taken by each runtime instance. If the delegation chain is not tracked at the identity level, the enterprise cannot tell whether the parent, the child, or the handoff created the risk.
External or federated agents create a separate trust boundary. This article assumes agents are registered inside the enterprise identity and agent registry model. An outside agent should not be treated as known simply because it presents a token from another system. Federation requires explicit issuer trust, tenant mapping, agent registration, policy agreement, credential validation, and limits on what external identity claims can mean inside the enterprise. Without those controls, external identity imports someone else’s trust decisions into the enterprise runtime.
Identity Gives Control Before Trust
Unknown agents cannot be governed. Registration gives the enterprise control over ownership, lifecycle, eligibility, credentials, and audit before trust is extended.
The control chain is identity -> task-scoped grant -> runtime enforcement. Enforcement without a grant is guesswork. A grant without stable identity cannot be attributed or audited.
Once identity exists, the enterprise can suspend the right actor, issue narrower grants, enforce policy at Skill Service and Tool Service boundaries, reconstruct parent and child agent activity, rotate credentials, and revoke trust without disabling unrelated workflows.
A known agent can still attempt the wrong action, use the wrong tool, access the wrong data, or release the wrong output. Identity does not make an agent safe by itself. It gives the next layers a reliable actor to bind to. Without it, the grant cannot be tied to a durable agent, the audit record is incomplete, and runtime enforcement has no stable reference point.
Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda
🎧 Follow The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!
Endnotes
[1]: Cloud Security Alliance, “New Cloud Security Alliance Survey Reveals 82% of Enterprises Have Unknown AI Agents in Their Environments,” April 21, 2026, https://cloudsecurityalliance.org/press-releases/2026/04/21/new-cloud-security-alliance-survey-reveals-82-of-enterprises-have-unknown-ai-agents-in-their-environments.
[2]: Carla Urrea Stabile, Auth0, “Why Your AI Agents Need an Identity Layer: Lessons from OWASP Top 10 for Agentic Applications,” February 20, 2026, https://auth0.com/blog/owasp-top-10-agentic-applications-lessons/.
[3]: Ashur Kanoon, Aembit, “IAM for Agentic AI: The New Perimeter of Trust in 2026,” May 2026, https://aembit.io/blog/iam-agentic-ai/.
[4]: Ken Huang, Vineeth Sai Narajala, John Yeoh, Jason Ross, Ramesh Raskar, Youssef Harkati, Jerry Huang, Idan Habler, and Chris Hughes, “A Novel Zero-Trust Identity Framework for Agentic AI: Decentralized Authentication and Fine-Grained Access Control,” arXiv, May 25, 2025, revised May 28, 2025, https://arxiv.org/abs/2505.19301.
[5]: OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications for 2026,” December 9, 2025, https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/.
[6]: Krti Tallam, “Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure,” arXiv, May 6, 2026, https://arxiv.org/abs/2605.05440.