This edition builds on our earlier exploration of agent permissions and effective authority, focusing on how that authority can drift after an access review.
In this edition
- Why unchanged permissions can hide newly reachable actions.
- How to distinguish intended, reachable and observed authority.
- Six practical capabilities for governing agent authority.
Imagine your organization deploys an AI agent to process supplier invoices.
The security team reviews its access.
The agent receives permission to read supplier information, retrieve documents, and create approval requests.
Everything looks appropriate.
Three months later, the agent still has exactly the same identity and assigned permissions.
But something has changed.
A new MCP tool has been connected.
Another agent has received additional privileges.
A downstream API now supports payment initiation.
A service credential has been granted broader access.
Suddenly, the original agent may be able to initiate actions that were never considered during its initial security review.
The agent didn't change. Its reachable authority did.
This is a problem I believe enterprises will increasingly encounter as they move from AI assistants that generate responses to autonomous agents that execute business processes.
I call it Authority Drift.
And it exposes a fundamental limitation in how many organizations currently approach AI-agent security.
Granted permission is not the same as effective authority
Traditional enterprise access management focuses on a relatively straightforward question:
Who has permission to access which resource?
We establish an identity, assign roles, grant permissions, and periodically review those entitlements.
For conventional applications, these controls remain essential.
But agentic systems introduce another dimension.
An agent may invoke tools, use delegated credentials, communicate with other agents, and execute multi-step workflows across different systems.
Consider a simplified example.
Agent A has permission to read CRM records and create service tickets.
Agent B has permission to update supplier records.
An MCP tool provides access to an ERP API.
If Agent A is permitted to delegate a task to Agent B, and the downstream controls allow that operation, Agent A may indirectly cause an ERP modification.
The original agent does not need direct ERP write permission for this path to exist.
That distinction matters.
Granted permissions describe what an identity has been assigned.
Effective authority describes the consequential actions that identity can actually cause through permitted execution paths.
An entitlement list can therefore be technically correct while providing an incomplete picture of an agent's operational capability.
Illustrative authority graph: granted permissions and reachable actions are not the same.
The graph makes an important architectural point: enterprise security must increasingly consider the entire execution path, not only the permissions assigned to the initiating agent.
Why this problem is becoming urgent
The industry is beginning to recognize that securing autonomous agents requires more than authenticating them.
On September 22, 2026, Okta's Blueprint Alliance brought together organizations across identity, cloud, cybersecurity, data, and enterprise software to advance a shared architecture for agent security.
Its principles include distinct agent identities, task-scoped permissions, traceable delegation, continuous runtime monitoring, and reversible containment.
The underlying questions are remarkably practical:
Where are our agents?
What can they do?
What are they doing?
How do we respond when something goes wrong? Okta Investor Relations
Meanwhile, Microsoft Entra Agent ID reflects a similar shift by providing identity constructs specifically designed for agents, including support for autonomous and delegated access.
But perhaps the strongest reminder came this week.
An October 8, 2026, incident roundup hosted by the OWASP GenAI Security Project documented several cases in which agents, tools, or their surrounding infrastructure crossed intended operational boundaries.
One particularly relevant example involved a malicious MCP server distributed through attempted contributions to AI projects.
The server initially behaved normally. After several tool calls, it changed its tool metadata to influence the connected agent toward sensitive credentials and configuration files.
The campaign involved 23 attempted pull requests. None were merged, and no downstream compromise was confirmed.
Nevertheless, the demonstrated technique is important.
A tool that appears acceptable during approval may not behave the same way later.
This is not proof that every MCP integration is dangerous. It demonstrates why initial approval alone is insufficient when connected capabilities and their behavior can change. OWASP Gen AI Security Project
The enterprise challenge is therefore moving beyond identifying agents and granting permissions.
It is understanding their authority continuously.
The hidden problem: Authority Drift
Consider an agent approved on Day 1.
Its authorized capabilities are limited to retrieving customer information and preparing internal service requests.
By Day 90, several changes have occurred elsewhere in the environment.
Another agent has gained write permissions.
A new finance API has been connected.
A service account has received additional privileges.
An existing tool now exposes a new operation.
The original agent's configuration remains unchanged.
Yet its reachable execution paths may have expanded.
A conventional access review might report:
Agent permissions: No changes detected.
A more comprehensive review might reveal:
Agent can now indirectly initiate a financial transaction.
That is the essence of Authority Drift.
It is not necessarily caused by an administrator making an incorrect change to the original agent.
It can emerge from otherwise legitimate changes across connected systems.
Illustrative authority drift: unchanged agent entitlements can coexist with expanded reachable actions.
This introduces an important architectural requirement.
Organizations need to distinguish between three things:
Intended authority: What the agent was designed and approved to do.
Reachable authority: What its current permissions and execution paths make possible.
Observed authority: What the agent has actually attempted or executed.
These are not interchangeable.
A reachable path is not evidence that an action occurred. An observed action does not establish that every reachable path is known.
Effective governance requires visibility into all three.
What enterprises are getting wrong
1. Treating agent identity as the complete solution
Giving each agent a unique identity is necessary.
It improves attribution, ownership, lifecycle management, and access control.
But an identity alone does not reveal every action that can be performed through delegated agents, shared credentials, or connected tools.
Agent identity is the foundation of governance, not the entire governance model.
2. Reviewing permissions without reviewing execution paths
Many organizations can answer which permissions an agent possesses.
Far fewer can confidently explain what those permissions enable through other connected systems.
For example, a read-only agent may be connected to a tool that invokes another service with broader privileges.
Security teams need to understand the permitted chain of execution and the downstream operations it exposes.
3. Giving agents permanent privileges for temporary tasks
An agent may need elevated permissions to complete a particular workflow.
That does not mean it needs those permissions continuously.
A better approach is:
Task → Temporary Authority → Execute → Revoke
This reduces the period during which a compromised or malfunctioning agent can misuse elevated access.
4. Treating prompts as security controls
Instructions such as “never modify production data” may influence an agent's behavior.
They do not replace enforceable authorization.
An agent should not be able to bypass a restriction simply by reasoning differently, receiving an unexpected tool response, or encountering malicious instructions.
Critical authorization decisions must be enforced at the appropriate application, tool, API, and resource boundaries.
5. Ignoring memory and persistent context
There is another dimension that deserves attention.
Agents increasingly retain information across sessions.
That memory can influence future planning, tool selection, and execution decisions.
But memory should not become an independent source of authority.
A remembered instruction to use a privileged tool does not establish permission to use it.
Organizations should distinguish between trusted policy, authoritative business data, retrieved information, and agent-generated memory.
Provenance, freshness, scope, and explicit forgetting are important here.
A useful rule is:
Memory can inform an action. It must not authorize an action.
The OWASP agentic-security guidance identifies memory and context poisoning as a distinct risk, reinforcing the importance of protecting persistent agent state. OWASP Gen AI Security Project
6. Building containment after deployment
Organizations frequently focus on preventing unauthorized actions but give less attention to stopping an agent once it begins behaving unexpectedly.
For consequential workflows, containment should be designed before production deployment.
Security teams should be able to revoke a credential, terminate a session, disable a tool, suspend a delegation, or stop an agent without unnecessarily disrupting unrelated services.
A practical framework for controlling agent authority
I would approach this problem through six capabilities.
1. DISCOVER — Know which agents exist
Maintain an inventory of production agents, including those deployed through third-party platforms.
Each agent should have an identifiable owner, purpose, environment, and lifecycle.
Without discovery, governance begins with an incomplete picture.
2. MAP — Understand effective authority
Map relationships between agents, users, tools, credentials, APIs, and resources.
The objective is to identify consequential actions that can be reached directly or indirectly.
For example:
Agent → Delegation → Tool → Credential → Resource → Action
This becomes the foundation of an Agent Authority Graph.
3. BOUND — Define what is allowed
Establish an explicit authority envelope for each agent.
That envelope should describe its permitted tools, resources, operations, delegation rights, and execution conditions.
For high-impact actions, use task-scoped permissions, short-lived credentials, and human approval where appropriate.
4. OBSERVE — Monitor runtime behavior
Capture meaningful execution events across the workflow.
A useful trace should establish which agent acted, on whose behalf, through which tool, against which resource, and with what outcome.
Logging every model token is not the objective.
The priority is preserving the evidence needed to understand consequential actions.
5. DETECT — Identify authority drift
Compare the approved authority envelope with current reachable capabilities and observed behavior.
Re-evaluate the agent when tools, credentials, downstream permissions, delegation relationships, or policies change.
This is where governance becomes continuous rather than purely periodic.
6. CONTAIN AND PROVE — Respond and demonstrate control
Provide targeted mechanisms to stop or restrict an agent.
Preserve sufficient evidence to reconstruct the authorization and execution chain.
A mature implementation should answer:
Who initiated the workflow?
Which agent performed the action?
What authority was used?
Which policy allowed it?
What changed?
How was the action contained?
The objective is not simply to collect logs.
It is to produce reliable operational and audit evidence.
What this means for different industries
The underlying problem is consistent, even though the consequences vary.
Manufacturing: An agent supporting procurement or production planning may interact with ERP, supplier systems, and operational workflows. Uncontrolled authority can affect orders, inventory, or production decisions.
Financial services: An agent connected to payment, reconciliation, or customer-account systems requires particularly careful control over write operations, delegated authority, and approval boundaries.
SaaS companies: Customer-support and operations agents may interact with multiple tenants and administrative APIs. Tenant isolation and scoped credentials are essential.
Consulting organizations: Agents may operate across different client environments. Identity, memory, credentials, and delegated authority must remain isolated between engagements.
Mid-market companies: The challenge is often limited security and platform-engineering capacity. Reusable controls and targeted monitoring may be more practical than building an elaborate governance platform.
Across these environments, the business question remains similar:
How do we give agents enough authority to create value without losing control over what they can do?
What CTOs and Heads of AI should do next
I would not recommend starting with a large enterprise-wide governance transformation.
Start with one production agent that can modify business data or invoke operational systems.
Map its identity, delegated authority, tools, credentials, resources, and possible actions.
Then answer five questions.
Can we identify the agent independently of the human?
Can we see its direct and indirect execution paths?
Can we detect when its reachable authority expands?
Can we reconstruct consequential actions afterward?
Can we stop the agent without disrupting unrelated systems?
If the answer to any of these is unclear, that is a concrete architecture backlog item.
For an initial assessment, I would measure four things:
| Measure | What it tells you |
|---|---|
| Percentage of agents with an accountable owner | Whether the organization has basic governance coverage |
| Percentage of consequential actions with traceable execution paths | Whether authority can be reconstructed |
| Number of unapproved reachable action paths | Where effective authority exceeds the approved envelope |
| Time required to revoke an agent's operational access | Whether containment is practical |
These measurements are more useful than simply reporting how many agents have been deployed.
They connect security controls to operational readiness.
The bigger picture: Enterprise Agent Control Plane
As organizations scale autonomous workflows, I expect governance to become increasingly centralized at the control layer while execution remains distributed.
Different business units will use different models, frameworks, MCP servers, APIs, and SaaS applications.
Trying to force every agent onto one technology stack may be neither realistic nor desirable.
But enterprises still need consistent control over identity, delegation, authority, policy, runtime behavior, memory, cost, observability, containment, and audit.
An architectural concept for common governance across heterogeneous agent systems.
The control plane should make it possible to govern heterogeneous agent systems through common principles.
It should not become another layer of unnecessary complexity.
The objective is to make autonomous execution understandable, bounded, and reversible.
The larger shift
Chatbots generated answers.
Copilots made recommendations.
Agents perform actions.
And actions require authority.
The traditional assumption of granting permissions and periodically reviewing them becomes increasingly difficult to sustain when an agent's execution environment changes continuously.
Enterprise AI security therefore needs to evolve from:
Authenticate → Authorize → Periodically Review
toward:
Identify → Map → Bound → Observe → Detect → Contain
This does not mean eliminating autonomy.
It means making autonomy safe enough to scale.
Because the most important question is no longer:
What permissions did we give this agent?
It is:
What can this agent actually do right now?
And can we prove that its authority remains within the boundaries we intended?
A question for technology leaders
If you reviewed your most capable production agent today, could you identify every consequential action it can reach directly or indirectly—and detect when that changes?
I'd be interested in hearing how organizations are approaching this challenge, particularly across multi-agent systems and enterprise integrations.
— Atul Yadav
Technology • AI • Strategy • Impact
Continue reading
Agent permissions and effective authority · Agent memory and trust
Keep a clearer view of what’s next
Subscribe to XTechStacks Weekly for practical perspectives on enterprise AI, architecture and engineering. If this edition helped you frame a decision, share its published link with a colleague.
Working through agent authority in your organization? Talk to XTechStacks about your architecture questions.
About the author — Atul Yadav
Atul Yadav writes XTechStacks Weekly, exploring enterprise AI, technology architecture and practical engineering decisions. This newsletter connects emerging technology with the controls and tradeoffs involved in real systems.
Follow XTechStacks on LinkedIn · Explore newsletter editions