AI Identities: The Role of Agentic Systems in Governance

Agentic AI systems are rapidly emerging in enterprise environments. To govern them safely, each agent needs to be recognized as a first-class identity with its own credentials, permissions, and audit trail.

Just as human users authenticate and authorize actions through established identity systems, agents require distinct, verifiable identities that define who they are, what they are allowed to do, and how their actions can be traced and controlled.

We will discuss two approaches:

1. User identity approach: Agents act under the user’s credentials.
2. Agentic identity approach: Agents have their own identity.

Challenge: Identity and consent don’t “stretch” to agents

The traditional web model is built on the idea that agents are invisible extensions of the user, relying on borrowed credentials or shared sessions. 

In practice, this breaks down in five critical ways:

• Who is acting? Without distinct agent identities, it is unclear whether a human or an agent performed the action.

• What was authorized? Broad credentials allow “do anything I can do” access; agents require granular scopes.

• Can this agent be trusted today? Agents can be misconfigured, exploited, or malicious. You need behavioral reputation that updates in near real time (violations, fraud flags, dispute rates).

• Where is the human? The human may be offline when the agent acts. You still need a high-assurance link to the right person, not a nagging one-time password for every step.

• Who accepted the terms? Checkbox click-throughs by an agent are not enforceable consent. Legal assent must come from the human, recorded at authorization, and cryptographically tied to the agent’s later actions.

1. The user identity approach

When considering how to manage agent behavior, one suggestion is to simplify the process by allowing agents to use the same credentials as the user.

In other words, the agent would act with the same permissions as the user, essentially passing the user’s credentials to the agent. This approach avoids the need to create separate identities for each agent.

When this approach works:

At first glance, this approach appears reasonable, particularly for tool-like agents that operate solely within the user’s session and under their direct control. 

This mirrors how traditional identity standards, such as OAuth 2.1 and OpenID Connect (OIDC), work: a user authenticates, receives tokens, and the client (in this case, the agent) simply reuses those tokens to act with the user’s full permissions.¹

While effective for short-lived, human-driven sessions, this model does not extend well to autonomous agents that may operate without a user present. This model works when:

• The agent operates exclusively within the user’s session
  
• Every action is explicitly initiated by the user
  
• The agent acts as an extension of the user’s interaction
  
• Responsibility for the agent’s outcomes rests entirely with the user

When this approach doesn’t work:

However, unlike traditional “human” or “non-human (system/API)” identities, today’s agents interact in fundamentally different ways:

• Dynamic entities: Agents don’t follow static workflows; their actions and pathways change in response to context.
  
• Complex handoffs: They often delegate or collaborate with other agents, producing unpredictable and multi-step flows.

Limitations of relying solely on user identity:

Insufficient permissions and access control:

Some agents need access to data or systems beyond what the user is authorized for. For example, a compliance agent needs to scan enterprise-wide data, access audit logs, and cross-check regulatory requirements. These agents require permissions that go beyond any individual user’s role.

In this case, a distinct agent identity with tailored permissions is needed to safely and effectively manage these actions.

Attribution of autonomous decisions:

The agent’s actions are highly dependent on what it knows at the moment, meaning it might make a different decision based on the data available at the time. The agent’s behavior changes depending on the context, which complicates determining who is accountable for its decisions.

Tracking accountability across complex interactions:

Agentic systems often work on tasks that are short-lived and temporary, meaning their interactions are fleeting. For example, an agent might delegate work to a sub-agent, and the sub-agent might interact with multiple systems or databases. 

Since the tasks are ephemeral and cross various systems, it’s hard to track the full chain of responsibility unless you can identify the agent’s actions at each step.

2. The agentic identity approach (conceptual)

The shortcomings of relying solely on user identity highlight the need for a new model. 

The agentic identity extends governance by giving agents their own verifiable identities, scoped permissions, and auditable actions. This approach recognizes agents as distinct digital actors bound to human intent.

Key principles of the agentic identity approach:

1. First-class identities for agents: 

Each agent has a stable ID, cryptographic keys, and metadata like publisher, version, and purpose. All requests are signed, making actions traceable and preventing impersonation.

2. Human-in-service authorization:

Instead of handing credentials to the agent, the user logs in directly with the service (for example, using a passkey, digital ID, or enterprise SSO). 

The service then shows a clear request describing the agent, what it wants to do, any limits, and the terms that apply. When the user approves, that consent is stored in a signed record, making the authorization explicit and enforceable.

3. Scoped, revocable tokens:

Agents use short-lived tokens linked to the user’s grant. Permissions are narrow and enforced as actions occur, with sensitive tasks requiring re-authorization. Keys can be rotated quickly if compromised, ensuring agents stay within approved boundaries.

4. Reputation and runtime controls:

Reputation signals (violations, dispute rates, and publisher trust) separate reliable agents from risky ones. New or unknown agents can be sandboxed, while guardrails like spend limits and anomaly detection keep misuse in check.

5. Auditability and user control:

Every agent action is logged under its grant. Users can review and revoke grants through a portal, with revocations applied instantly to active sessions.

Expanding the concept of agentic identity

This is a good example of how agentic identity works in practice, showing fine-grained access control when a single agent requests data. It illustrates not only that the bot has an identity, but also how that identity is enforced and governed throughout the workflow.

But, agentic identity also applies to other critical areas such as human authorization, revocation, reputation management, and cross-agent collaboration.

We’ll explore those broader real-world agentic identity applications in the section below.

What this workflow does:

• RiskAnalyzerBot: The AI agent. It initiates the request, asking to query the InternalDB-SalesFigures table.

• Adapter Enforcement Middleware (AEM): The gatekeeper. It intercepts the request before it reaches the database and triggers checks.

• Policy Information Point (PIP): The data collector. It gathers context such as the agent’s identity (DID), credentials, declared capabilities, resource attributes, and requested action.

• Policy Decision Point (PDP): The decision maker. It evaluates the gathered context against access policies and issues an allow or deny decision.

• InternalDB-SalesFigures: The protected resource. If the PDP says allow, the query executes and results are returned. If deny, access is blocked.

Real-world agentic identity applications

Now that we’ve defined the agentic identity approach. The next step is to see how this takes shape in practice.

Standards bodies, open-source groups, and enterprise vendors are beginning to embed these principles into real systems. Some solutions map closely to the agentic identity model (like MCP-I or Entra Agent ID), while others address narrower layers such as discovery, naming, or orchestration.

Below are examples of emerging standards and enterprise applications that put agentic identity concepts into action:

1. Standards & frameworks

✅ Agentic-identity ready:

These are built (or extended) specifically to treat agents as first-class principals, with their own lifecycle, credentials, and controls:

• MCP-I (Model Context Protocol – Identity): Adds distinct agent IDs, scoped delegation, auditability, and reputation tracking to MCP. It is still evolving;it  requires developer effort to adopt.³
  

• Zero-trust Agentic AI identity framework: Applies zero-trust principles to agents; decentralized IDs, fine-grained access, and session revocation. It is more of a model than a plug-and-play solution today. ⁴

❌ Supportive agent identity:

These provide important building blocks like discovery, naming, or extensions of existing IAM, but don’t by themselves cover full delegation, consent binding, or autonomous governance:

• Authenticated delegation frameworks: Extends OAuth/OIDC to include agent metadata and delegation records. Mostly early research/proposals; tooling is limited.⁵
  

• Agent registry (Cisco Proposal): Provides a registry for agent metadata, credentials, and trust signals (like DNS but for agents). But, still conceptual.⁶

• Agent name service (ANS): Proposes a DNS-like service for naming, discovering, and authenticating agents globally. Mostly academic at this stage.⁷

Enterprise implementations

✅ Agentic-identity ready:

• AGNTCY agent identity (Cisco Outshift): Issues and verifies AI agent credentials (like passports for agents).
  • Best for: Early adopters testing open, standards-driven agent identity in pilots.⁹

• Maverics Identity Orchestration (Strata): Orchestrates multiple IAM systems (Okta, Ping, Entra) to provide unified agent identity governance.
  Best for: Large enterprises with multiple IAM systems needing central control.¹⁰

• Descope agentic Identity Hub: Provides plug-and-play authentication/authorization for AI agents in enterprise systems.¹¹

• Zero-trust agent architecture (Microsoft + WSO2): Adds OAuth-style continuous authentication for every agent action.¹²
  

• Microsoft Entra Agent ID: Extends Entra (Azure AD) to provision, manage, and retire agent accounts automatically.¹³
  

External Links

• 1. https://www.secureauth.com/agentic-ai/white-paper-identity-101-for-ai-agents/
• 2. https://arxiv.org/pdf/2505.19301
• 3. https://modelcontextprotocol-identity.io/
• 4. https://arxiv.org/abs/2505.19301
• 5. https://arxiv.org/html/2501.09674v1
• 6. https://community.cisco.com/t5/security-blogs/a-new-identity-framework-for-ai-agents/ba-p/5294337
• 7. https://arxiv.org/abs/2505.10609
• 8. https://arxiv.org/abs/2505.10609
• 9. https://outshift.cisco.com/blog/ai-agent-identity-framework-agntcy
• 10. https://www.strata.io/maverics-platform/identity-orchestration-for-ai-agents/
• 11. https://www.forbes.com/sites/janakirammsv/2025/04/23/descope-builds-authentication-framework-for-ai-agent-integration/
• 12. https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/zero-trust-agents-adding-identity-and-access-to-multi-agent-workflows/4427790
• 13. https://techcommunity.microsoft.com/blog/microsoft-entra-blog/announcing-microsoft-entra-agent-id-secure-and-manage-your-ai-agents/3827392