Enterprises spent decades building identity systems around humans.
An employee joins. They receive an identity. Roles determine what they can access. Their actions can be traced. When they leave, their access is revoked.
Then we added applications and workloads.
Now we are introducing something different:
AI agents that can decide what to do next.
An agent may search enterprise data, call an API, invoke an MCP tool, interact with another agent, update a CRM record or initiate a business process—all while acting autonomously or on behalf of a human.
That changes the security question.
It is no longer simply:
“Who is the user?”
It becomes:
Who is the agent, whose authority is it using, what is it allowed to do, and who is accountable when it acts?
I believe this will become one of the most important—and most frequently repeated—enterprise AI architecture problems.
We are creating a new identity population
Imagine a procurement agent.
A user asks:
“Find suitable suppliers for this component, compare existing contracts and prepare a purchase request.”
Behind that simple request, the execution path could look like:
Employee
│
▼
AI Agent
│
├── Supplier Database
├── Contract Repository
├── Pricing Data
├── ERP
└── Procurement APIGiving the agent access is relatively easy.
Governing that access is much harder.
Should the agent inherit everything the employee can access?
Should it have its own identity?
Can it read pricing but not supplier bank details?
Can it create a purchase-order draft but not approve it?
If it calls an MCP server exposing 20 tools, should access to the server imply permission to execute all 20?
What happens when the employee who created the agent leaves?
And if something goes wrong, can security immediately revoke that agent everywhere?
These aren't theoretical questions anymore.
The market is already signaling the problem
On August 24, Okta announced general availability of Agent SSO, explicitly treating AI agents as first-class identities rather than anonymous integrations using static API keys or one-off OAuth grants. Okta says only 34% of organizations apply the same security controls to agents that they apply to human workers. (Okta)
Microsoft is moving in the same direction through Microsoft Entra Agent ID. Microsoft now distinguishes agent identities from conventional application identities and supports both autonomous agent access and delegated access where an agent acts on behalf of a human. (Microsoft Learn)
Microsoft's August 6 Dataverse integration illustrates the model particularly well: an agent receives its own Entra identity and a dedicated, least-privileged security role, allowing organizations to distinguish agent activity from both human and conventional application activity. (Microsoft)
This isn't interesting because identity vendors have launched new products.
It is interesting because enterprise architecture is beginning to recognize agents as a new identity class.
Authentication is only the beginning
A common mistake will be solving this as:
Agent
↓
Authenticate
↓
Access application
↓
DoneBut authentication answers only:
Who are you?
Authorization answers:
What are you allowed to do?
Agentic systems introduce another critical question:
On whose behalf are you doing it?
That distinction matters.
Consider:
Atul
│
│ delegates
▼
Research Agent
│
▼
Enterprise MCP
│
├── Search documents ✓
├── Read approved data ✓
├── Generate analysis ✓
├── Update record ?
└── Delete record ✕The agent's identity and the user's identity are related—but they are not necessarily the same thing.
Microsoft's agent-identity model already explicitly separates autonomous access granted directly to an agent from delegated access granted when an agent operates on behalf of a user. (Microsoft Learn)
That distinction will become increasingly important as agents move from answering questions to performing actions.
Where enterprises are likely to get this wrong
Shared identities
If ten agents use one service account, attribution becomes difficult.
Security sees:
service-account-123 updated customer record
rather than:
Agent-42 acting for User-X updated customer record
That difference matters during an incident.
Long-lived credentials
Static API keys are convenient during experimentation.
At enterprise scale, they become credential-management liabilities.
Short-lived, policy-governed tokens significantly reduce that exposure; this is one of the architectural changes behind Okta's Agent SSO approach. (Okta)
Giving the agent everything the user can access
This may be convenient.
It can also produce enormous blast radius.
A user might legitimately have access to 50 systems.
The expense-report agent may need two.
User permission ≠ agent permission.
Authorizing an MCP server rather than its actions
MCP makes tool connectivity considerably easier.
But:
Agent → MCP server
should not automatically mean:
Agent → every tool → every action
Authorization increasingly needs to reach the tool—and sometimes resource/action—level.
Forgetting agent lifecycle
Employees join, move and leave.
Agents will too.
An enterprise eventually needs to answer:
Who created this agent? Who sponsors it? What is its purpose? When should its access expire? Who reviews its permissions? What happens when its owner leaves?
Microsoft's current governance model already exposes owners and sponsors and provides lifecycle controls around agent identities. (Microsoft Learn)
The problem becomes multiplicative
One agent is manageable.
Ten agents are manageable.
But imagine:
500 agents
×
200 enterprise tools/APIs
×
thousands of users
×
multiple data classifications
×
multiple environments
×
autonomous actionsYou don't merely have an AI platform anymore.
You have an identity and authorization estate.
That makes this problem particularly interesting from an enterprise investment perspective.
DimensionAssessmentPain severityVery HighFrequencyVery HighBusiness impactHighSecurity/compliance riskVery HighUrgencyHigh and increasingCostPotentially high—manual governance does not scale with agent countWillingness to payHigh, especially in regulated environmentsCross-industry applicabilityVery HighRepeatabilityVery HighProductization potentialHigh
I would avoid inventing a dollar figure for the problem. The stronger economic argument is structural:
Every additional agent creates another identity, another permission surface and potentially many new agent-to-resource relationships.
Manual governance therefore becomes progressively more expensive.
A practical framework: AGENT
Organizations don't need to wait for a complete new security platform before addressing this.
I would start with five controls.
A — Assign identity and ownership
Every production agent should have:
Unique identity
Business purpose
Human sponsor/owner
Environment
Risk classification
Lifecycle stateAvoid anonymous production agents wherever possible.
G — Grant minimum necessary authority
Start with what the agent actually needs to accomplish its purpose.
Think:
purpose-bound + resource-bound + action-bound + time-bound
rather than:
“Give the agent the same permissions as its owner.”
For higher-risk actions, require human approval.
E — Enforce at multiple boundaries
Authorization shouldn't exist in only one place.
A stronger architecture may enforce policy across:
Identity Provider
│
▼
Agent Runtime
│
▼
MCP / Tool Gateway
│
▼
Individual Tool
│
▼
API / Data Platform
│
▼
Resource / ActionThe closer an action gets to consequential enterprise data or transactions, the less comfortable we should be relying solely on upstream authorization.
N — Notice what agents actually do
Agent observability needs to answer more than:
API request succeeded.
For consequential workflows, organizations may eventually need something closer to:
Human
↓
Agent
↓
Delegated identity
↓
Policy decision
↓
Tool
↓
Resource
↓
Action
↓
ResultThis creates a trace security, audit and platform teams can actually investigate.
Microsoft's current agent controls already expose sign-in activity and can identify operations performed by agent identities separately from conventional users and applications. (Microsoft Learn)
T — Terminate access
Every agent needs a kill path.
If:
- credentials are compromised,
- behavior becomes suspicious,
- its business purpose ends,
- ownership disappears,
- or permissions become inappropriate,
the organization should be able to revoke the agent identity, rather than hunting through every downstream integration.
Microsoft already supports disabling an individual agent identity, its blueprint or—in extreme cases—agent authentication more broadly. (Microsoft Learn)
The bigger architecture shift
The evolution looks something like this:
HUMAN IAM
Human
↓
Identity
↓
Role
↓
Application
WORKLOAD IAM
Application
↓
Workload Identity
↓
Policy
↓
Resource
AGENT IAM
Human / Process
↓
Agent Identity
↓
Delegation
↓
Runtime Policy
↓
MCP / Tool
↓
API / Data
↓
Action
↓
Audit + RevokeThe final model is fundamentally more dynamic.
An application usually knows which API it will call.
An agent may decide which tool to call based on the context of a task.
That means identity, authorization and runtime policy increasingly become part of the AI architecture itself.
Three things technology leaders can do now
Inventory your agents. Include internally built agents, SaaS-embedded agents and employee-created agents. If you don't know where your agents are, authorization is already secondary.
Separate human authority from agent authority. Explicitly decide where agents act autonomously and where they act through delegated user permissions.
Define authorization below the application boundary. Especially for MCP and tool-based architectures, determine which tools, resources and actions an agent can execute—not merely which server it can reach.
Why I think this problem is worth watching
This has the characteristics of a valuable recurring enterprise problem.
It affects almost every organization adopting agents.
It becomes harder—not easier—as adoption succeeds.
It cuts across security, IAM, platform engineering, data governance and AI architecture.
And importantly, much of the solution can be standardized.
That makes it suitable for a repeatable capability such as:
Agent Security & Governance Readiness
Discover → Assess → Score → Design → Implement
An organization could inventory agents, map identity and delegation, assess tool permissions and blast radius, identify lifecycle gaps, and design reusable authorization patterns.
Eventually, parts of that assessment could potentially become software.
But that is a hypothesis worth validating with enterprises rather than a product worth building prematurely.
One question I would ask every CIO, CTO and Head of AI
Most organizations currently know who their employees are.
Many know which applications and service accounts they operate.
Soon they may operate hundreds—or thousands—of AI agents.
So before the number becomes unmanageable, there is one deceptively simple question worth answering:
If I asked you tomorrow for every AI agent operating in your company, who owns it, what it can access and what actions it can perform—could you answer?
If the answer is no, the agent identity problem may already have started.
If you're working through this problem, I'd be interested in comparing notes on where the hardest boundary is proving to be: identity, delegation, MCP/tool authorization, lifecycle or runtime governance.
— XTechStacks Newsletter team
Originally published in XTechStacks Weekly on LinkedIn on September 7, 2026. Read the original edition.