Why static IAM isn't enough for the agentic enterprise
Imagine approving an AI agent for a straightforward task:
“Review this supplier invoice and prepare it for payment.”
The agent authenticates, retrieves supplier information, invokes a tool, calls another agent for validation, obtains a credential and eventually reaches the payment system.
Every individual connection may be legitimate.
But now ask a different question:
What can this agent actually do?
Not what its IAM role says.
Not what its developer intended.
Not what somebody approved three months ago.
What can it actually reach, invoke, delegate and change right now?
That distinction leads to a problem I think enterprises will encounter repeatedly:
Granted Permission ≠ Effective Authority
IAM was built for a more predictable world
Traditional enterprise authorization generally follows a recognizable model:
Identity → Role → Resource
We authenticate someone, assign entitlements, periodically review access and revoke it when circumstances change.
AI agents complicate that model.
An agent can select tools dynamically, operate autonomously or on behalf of a user, call other agents, interact with APIs and enterprise applications, and continue multi-step workflows without a person explicitly authorizing every individual action.
Microsoft has now formalized agent identities in Entra specifically to distinguish AI-agent activity from conventional workforce and workload identities. Its architecture supports both autonomous access and delegated access where an agent acts on behalf of a human. Microsoft Learn
Microsoft's guidance makes another point particularly relevant here:
The agent can reason about what to do next. The surrounding application and identity controls should still determine whether the action is allowed. Microsoft Learn
So the authorization question changes from:
Who are you, and what role do you have?
to:
Who is this agent, on whose behalf is it acting, through which tools, for what purpose, and what can it ultimately cause to happen?
The industry is moving toward runtime governance
This is no longer only an architectural thought experiment.
On September 22, Okta announced the Blueprint Alliance, bringing together companies including AWS, CrowdStrike, Databricks, Docker, Google Cloud, Proofpoint, Salesforce, ServiceNow, Wiz and Zscaler around a common architecture for securing AI agents. Okta
The principles are revealing:
Treat the agent as a first-class identity.
Prefer task-scoped access over standing privilege.
Keep delegation traceable.
Monitor runtime behavior continuously.
Make containment immediate and reversible.
This week, NIST added another strong signal. On September 29, the NCCoE said it had received feedback from more than 600 commenters on its software and AI-agent identity work, and that its first implementation use case will demonstrate how agents can be identified, authenticated and authorized in DevSecOps. NIST
Different parts of the ecosystem are arriving at the same conclusion:
Authorization cannot end when an agent receives a token.
Static entitlements tell you what was granted. The Authority Graph shows what is reachable.
Suppose an agent's approved permissions are:
Read CRM Read SharePoint Create ServiceNow ticket
That describes its granted permissions.
Now suppose that same agent can invoke another agent.
That second agent can use an MCP tool.
The MCP tool authenticates using a credential.
That credential can modify supplier information in the ERP system.
The original agent may have no direct ERP permission.
Yet a valid execution path exists through which it can cause ERP data to change.
That is closer to its effective authority.
A useful mental model is:
Effective Authority = Direct Permissions + Delegated Authority + Tool Capabilities + Credential Scope + Downstream Permissions + Reachable Agent Actions
Authorization has become transitive.
And once authority becomes transitive, a flat entitlement table stops telling the whole story
Why MCP makes this more visible
MCP itself is not the problem.
It makes the problem easier to see because it makes enterprise capabilities easier for agents to discover and invoke.
An agent may be connected to:
SharePoint | Databases | ServiceNow | GitHub | Cloud | Finance
The relevant security question isn't merely:
Can this agent access the MCP server?
It becomes:
Which tool can it execute, using whose authority, against which resource, under what conditions—and what can happen downstream?
The Blueprint Alliance specifically frames downstream resource visibility as part of securing agent execution across SaaS, data systems, infrastructure and other connected services. Okta
That is why I think enterprises will increasingly need something conceptually similar to an:
Agent Authority Graph
An authority graph answers questions that an entitlement list cannot.
Reachability: What can this agent ultimately reach?
Transitive authority: What can another agent or tool do on its behalf?
Blast radius: If the agent is compromised, what becomes reachable?
Delegation provenance: Who originally authorized this chain?
And perhaps most importantly:
Has the reachable authority changed since we approved the agent?
The agent may not change. Its authority can.
Imagine Agent A passes its security review today.
Its role remains unchanged for the next 90 days.
But during those 90 days:
a new MCP finance tool is connected;Agent B receives additional privileges;an API gains a write operation;a service account receives a wider scope;a new SaaS integration is introduced.
Agent A itself hasn't changed.
But what Agent A can ultimately cause to happen has changed.
I call this:
Authority Drift
A conventional entitlement review might report:
Agent A permissions: unchanged.
An authority-aware review could instead discover:
Agent A can now indirectly modify supplier records or initiate a payment.
That is the difference between reviewing configuration and understanding actual capability.
Why this becomes an expensive recurring problem
For five experimental agents, architects and security teams may be able to reason about these relationships manually.
At enterprise scale, the problem changes.
The relationships multiply across:
Agents × Humans × Tools × Credentials × Resources × Delegation Paths
And unlike a one-time security review, these relationships can change continuously.
The pain appears in several places.
Security
A compromised agent can have a much larger blast radius than its direct permissions suggest.
Compliance
Auditors need to reconstruct who initiated an action, which identity performed it and what policy permitted it.
Operations
Incident teams need a targeted way to stop an agent without shutting down unrelated workloads.
Financial exposure
Agents connected to purchasing, payments, infrastructure or customer systems can perform actions with real economic consequences.
Engineering productivity
Every new agent can otherwise become another bespoke security exercise.
But there is a less obvious cost:
Poor authorization architecture can slow AI adoption itself.
If security teams cannot establish an agent's effective authority, their safest response may be:
Don't let the agent act.
The company then invests in agent technology but restricts it to chatbot-like behavior.
Security risk and lost automation value become two sides of the same problem.
Six mistakes enterprises should avoid
1. Reusing the human's identity
If an employee and an agent appear as the same actor, accountability becomes weak.
Microsoft's current architecture provides dedicated agent identities precisely so agent operations can be distinguished and governed separately. Microsoft Learn
2. Giving agents standing privilege
An agent may need elevated access for 30 seconds.
That doesn't mean it should retain the permission indefinitely.
The better model is increasingly:
Task → Temporary Authority → Execute → Revoke
3. Treating authentication as authorization
A valid token confirms identity.
It does not prove that every downstream action is appropriate.
4. Reviewing each agent in isolation
Some of the most consequential authority exists between agents, tools, APIs and credentials.
5. Treating prompts as security policy
“Only read the database” is an instruction.
It is not an enforceable security boundary.
Authorization belongs at deterministic tool, API and resource layers.
6. Designing containment after deployment
Every consequential agent should already have a way to:
revoke → terminate → disable → quarantine → require approval
A practical operating model
I would approach the problem through seven stages:
DISCOVER
Find both sanctioned and shadow agents.
If you don't know where the agents are, authorization is already secondary.
IDENTIFY
Associate every production agent with:
Identity → Owner → Purpose → Version → Environment
BOUND
Define the intended authority envelope.
Ask:
Who may invoke it?
Which systems may it reach?
Which tools may it call?
Which actions may it perform?
Can it delegate?
For how long?
OBSERVE
Capture the execution chain:
Agent → Delegator → Tool → Credential → Resource → Action → Result
DETECT
Continuously compare:
Intended Authority ↔ Effective Authority
Unexpected differences are candidates for authority drift.
CONTAIN
Revoke the smallest necessary unit:
Token | Session | Tool | Delegation | Agent
Containment should be precise and reversible.
PROVE
Be able to reconstruct:
Who authorized the agent?
What could it access?
What did it actually do?
On whose behalf?
Which policy allowed it?
That's where authorization becomes auditability.
What technology leaders can do now
You don't need to build a complete agent-governance platform immediately.
Pick one production agent that has write access.
Map:
Identity → Delegation → Tools → Credentials → Resources → Actions
Then ask five questions:
Can we distinguish the agent from the human?
Can we see every consequential direct and indirect action it can reach?
Are elevated permissions temporary?
Can we reconstruct what it did afterward?
Can we stop only this agent without disrupting unrelated workloads?
If any answer is unclear, you've found a concrete architecture backlog.
For high-impact systems—payments, production infrastructure, regulated data or manufacturing controls—I would go further:
Standing write authority should be the exception, not the default.
Where this is heading: the Enterprise Agent Control Plane
Agent identity is necessary.
But identity alone will not solve the problem.
As enterprise agents mature, I expect a shared control layer to emerge around them.
The control plane needs to answer:
Identity — Who is the agent?
Delegation — On whose behalf is it operating?
Authority — What can it actually do?
Policy — What should it be allowed to do?
Runtime — What is it doing now?
Memory — What may it retain?
Economics — What may it spend?
Observability — Can we explain its behavior?
Containment — Can we stop it?
Audit — Can we prove what happened?
Below that control plane may sit different agent frameworks, models, MCP servers, SaaS applications, APIs, clouds and enterprise systems.
The goal isn't to force everything onto one vendor.
It is to create consistent enterprise control across a heterogeneous agent ecosystem.
The larger principle
Chatbots produced answers.
Copilots made recommendations.
Agents perform actions.
And actions require authority.
The more autonomy we give an agent, the less comfortable we should be with:
Authenticate once → Authorize once → Trust continuously
The model needs to evolve toward:
Identify → Bound → Observe → Detect → Contain → Prove
This isn't about preventing autonomous systems.
It is about making autonomy:
Observable. Bounded. Reversible.
Because the most important authorization question in an agentic enterprise will no longer be:
What permissions did we give this agent?
It will be:
What can this agent actually do right now?
One question for technology leaders
Take your most capable production agent.
Could you show me:
every system it can reach directly or indirectly, every consequential action another agent or tool can perform on its behalf, and how you would stop those actions within seconds?
If you're already working through this problem, I'd be interested in comparing approaches.
— XTechStacks
Originally published in XTechStacks Weekly on LinkedIn on October 3, 2026. Read the original edition.