AI agents are getting increasingly autonomous.
They can read data, call APIs, invoke MCP tools, create infrastructure, execute workflows, interact with enterprise applications, and even delegate tasks to other agents.
But there is a fundamental question that many enterprise architectures still struggle to answer:
Who is the agent?
Not what model is it running?
Not which application deployed it?
Not which service account it happens to use?
Who is actually authorized to perform this action — and on whose behalf?
This is where the next major identity problem in enterprise security is emerging.
We have spent decades building mature identity systems for humans: SSO, MFA, RBAC, ABAC, privileged access management, workload identity, and zero-trust architectures.
But autonomous AI agents introduce something fundamentally different.
An agent can act autonomously, operate on behalf of a human, delegate work to another agent, invoke tools across trust boundaries, and make dozens of downstream calls without a human being present for every step.
Yet many implementations still give that agent something that looks remarkably similar to what we gave applications 15 years ago:
A service account and an API key.
That model is not going to scale.
Enterprise environments are already dealing with a rapidly growing population of non-human identities.
Applications, workloads, services, containers, CI/CD pipelines, bots, and automation identities can vastly outnumber human users.
Now add autonomous AI agents to that population.
The problem becomes more complicated because an AI agent isn’t simply another workload.
An agent can make decisions.
It can interpret instructions.
It can invoke tools.
It can delegate tasks.
And critically, it can act on behalf of somebody else.
If something goes wrong, who performed the action?
The employee?
The planner?
The finance agent?
The MCP server?
Or the service account shared by all of them?
Traditional IAM models start becoming uncomfortable here.
The easiest way to give an agent access is often to provide a credential.
An API key
A client secret
A service-account credential
A long-lived OAuth token
The problem is that autonomous workloads are dynamic.
They scale
They restart
They move between nodes
They generate logs
They interact with tools
And their execution paths aren’t always deterministic.
Embedding long-lived credentials inside these environments creates an unnecessary attack surface. A compromised container shouldn’t automatically become a compromised identity.
The better model is to prove the workload’s identity and issue short-lived credentials dynamically.
Now consider a more interesting scenario.
A finance manager asks an AI agent:
“Reconcile this month’s invoices and fix any discrepancies.”
The agent calls a planner
The planner delegates to a finance agent
The finance agent invokes an MCP server connected to SAP
The final API request might look like:
User
↓
Planner Agent
↓
Finance Agent
↓
MCP Server
↓
SAP
Traditional bearer tokens often collapse this entire chain into a single identity.
Downstream systems may only see:
service-account-finance-agent
We’ve lost the most important information:
Who initiated the request?
And:
Which agent actually performed it?
For agentic systems, authorization needs to preserve the delegation chain.
This becomes even more dangerous when agents have broad permissions.
Imagine a user has access to several finance operations.
An agent is given that user’s context.
A malicious instruction or indirect prompt injection convinces the agent to invoke a privileged administrative API.
If the agent is operating through an over-permissioned service account, the downstream system may simply see a legitimate credential performing a legitimate API call.
The system may have no idea that:
Identity must therefore become part of the agent’s security context — not just an authentication mechanism.
A production-grade agent identity architecture should separate two questions:
This is workload identity.
This is delegated authorization.
One useful architecture combines:
The resulting architecture looks like this:
┌───────────────────────────┐
│ Human Principal │
│ User / Employee │
└─────────────┬─────────────┘
│
OIDC Authentication
│
▼
┌───────────────────────────┐
│ Authorization Server │
│ │
│ Token Exchange + Policy │
└─────────────┬─────────────┘
│
Short-lived delegated token
│
▼
┌────────────────────────────────────┐
│ AI Agent Runtime │
│ │
│ SPIFFE/SPIRE Workload Identity │
└───────────────┬────────────────────┘
│
Delegated Authorization
│
▼
┌─────────────────┐
│ Agent / Agent │
│ Delegation │
└────────┬────────┘
│
▼
┌─────────────────┐
│ MCP / APIs │
│ / Services │
└─────────────────┘
The important architectural principle is:
Workload identity answers “who is running?” while delegated authorization answers “what is this agent allowed to do on behalf of whom?”
Before an agent receives access to sensitive enterprise systems, its runtime environment should establish a cryptographic identity.
This is where SPIFFE and SPIRE become particularly interesting.
Instead of putting credentials inside the container, the platform establishes the identity of the workload.
Conceptually:
┌──────────────────────────────┐
│ SPIRE Server │
│ │
│ Workload Identity Authority │
└──────────────┬───────────────┘
│
Platform Attestation
│
▼
┌──────────────────────────────┐
│ SPIRE Node Agent │
└──────────────┬───────────────┘
│
Workload API
│
▼
┌──────────────────────────────┐
│ AI Agent │
│ │
│ spiffe://corp.internal/ │
│ agent/finance-reconciler │
└──────────────────────────────┘
The agent receives a short-lived cryptographic identity, such as an X.509 SVID or JWT-SVID, rather than relying on a static secret embedded in its runtime.
The exact credential lifetime and rotation policy should be determined by the platform’s security requirements.
The important idea is simpler:
The agent proves who it is instead of carrying a permanent secret that says who it is.
Workload identity alone isn’t enough.
Knowing that the request came from:
finance-reconciler-agent
doesn’t tell us why the agent made the request.
We also need delegation context.
OAuth token exchange provides a mechanism for exchanging one security token for another token appropriate for a downstream service, while preserving authorization context.
For an agentic workflow, the conceptual chain becomes:
Human
│
│ requested
▼
Planner Agent
│
│ delegated
▼
Finance Agent
│
│ invoked
▼
MCP Server
│
▼
SAP
The downstream authorization context can preserve the actor relationship rather than reducing everything to a generic service identity.
Conceptually, the token might carry actor information such as:
{
"sub": "user_finance_mgr",
"aud": "https://mcp-sap-ledger.internal",
"scope": "ledger:read",
"act": {
"sub": "spiffe://corp.internal/agent/finance-reconciler",
"act": {
"sub": "spiffe://corp.internal/agent/planner"
}
}
}
Now the downstream system can answer questions that matter during an incident:
Who initiated this?
Which agent executed it?
Which agent delegated it?
What authorization scope was granted?
That is the beginning of meaningful agent accountability.
This is one of the most important principles in agentic security.
An agent should not automatically inherit every permission available to the user.
Instead, authorization should become narrower as the request moves through the agent chain.
Think of it as a security funnel:
Human Permissions
│
▼
Agent Policy
│
▼
Task-Specific Scope
│
▼
Tool-Specific Permission
│
▼
Final API Action
For example:
User:
finance:*
Planner:
finance:reconciliation
Finance Agent:
ledger:read
MCP Tool:
ledger:read:invoice
The final permission is deliberately narrower than the original permission set.
A useful conceptual model is:
Effective Permission = User Authorization ∩ Agent Policy ∩ Task Scope ∩ Tool Policy
This prevents a powerful human identity from becoming an equally powerful autonomous identity.
There is another problem.
What happens if an access token is stolen?
A traditional bearer token essentially says:
“Whoever possesses this token can potentially use it.”
For autonomous workloads, that creates a significant replay risk.
DPoP — Demonstrating Proof of Possession — introduces another layer.
The access token is associated with a cryptographic key, and the client proves possession of the corresponding private key when making requests.
Conceptually:
Agent
│
├── Short-lived access token
│
└── Ephemeral private key
│
▼
DPoP Proof
│
▼
API / MCP
If an attacker obtains the token but not the corresponding private key, simply replaying the stolen token should not be sufficient to authenticate as the legitimate agent.
This moves the architecture from:
“Do you possess the token?”
toward:
“Can you prove you are the legitimate holder of the credential?”
After looking at these patterns, I would establish three rules for enterprise AI platforms.
Agents should not bootstrap their identity using hardcoded API keys or long-lived credentials.
Use workload attestation and dynamic credential issuance wherever possible.
The platform should establish:
Workload → Identity → Credential
rather than:
Developer → Secret → Container
An autonomous agent should never disappear behind a generic service account.
When:
Human → Agent A → Agent B → MCP → API
happens, the security context should preserve that relationship.
The downstream system should be able to determine:
Who initiated the action, which agent performed it, and which delegation path led to the final operation?
Every delegation should be an opportunity to reduce privilege.
Never allow:
User Permission
↓
Agent Permission
↓
More Agent Permission
↓
Tool Permission
Instead:
User Permission
↓
Agent Policy
↓
Task Scope
↓
Tool Scope
↓
Specific Action
Autonomy should never become privilege escalation.
Agent identity isn’t just an IAM problem.
It becomes the foundation for everything that comes later.
Without strong identity, it becomes difficult to build reliable:
Imagine an incident where an AI agent accidentally deletes production resources. The security team shouldn’t have to reconstruct the entire event from application logs.
They should be able to ask:
Who?
↓
Which human initiated it?
Which agent?
↓
Which workload executed it?
Which delegation?
↓
Which agent authorized the next hop?
Which tool?
↓
Which MCP server/API was invoked?
Which policy?
↓
What scope was granted?
Which action?
↓
What actually happened?
That is what agent identity enables.
The biggest mistake enterprises can make with agentic AI is treating an autonomous agent as just another application.
It isn’t.
A traditional application generally executes a predefined workflow.
An AI agent can interpret intent, make decisions, select tools, delegate tasks, and dynamically determine its next action.
That fundamentally changes the security model.
The first security boundary for enterprise agents should therefore not be the LLM.
It should be identity.
Before an agent gets access to data, tools, APIs, or other agents, the platform should be able to answer three questions:
Who is this workload?
Who is it acting for?
What is it allowed to do right now?
A practical enterprise architecture can start with:
SPIFFE/SPIRE → Workload Identity
OAuth Token Exchange → Delegated Authorization
Actor Claims → Delegation Traceability
DPoP → Proof of Possession
Policy Engine → Scope Attenuation
Together, these patterns establish something that today’s agent platforms desperately need:
Because an AI agent that can act without a verifiable identity isn’t autonomous.
It’s an unaccountable credential with an LLM attached to it.
I’m an Enterprise Cloud & AI Architect with 14 years of experience in the IT industry, focused on designing and scaling enterprise-grade cloud, AI, automation, and AIOps platforms.
My work spans enterprise AI architecture, AIOps, platform engineering, FinOps, cloud modernization, and production-grade Generative AI, with a particular interest in turning emerging AI patterns into secure and operationally viable enterprise platforms.
I regularly share practical architecture patterns, lessons from real-world implementations, and experiments around AI agents, cloud architecture, AIOps, platform engineering, and FinOps.
If you’re interested in these areas, feel free to connect with me on LinkedIn or X ** @jitu028**.
For 1:1 mentoring, architecture guidance, career discussions, or enterprise solution consulting, you can also connect with me through Topmate.