Imagine an employee asks an AI assistant to renew a software subscription. The assistant gives the pricing research to one agent, the contract review to another, and the purchase request to a third. A few minutes later, a record appears in the finance system.
The transaction may look routine, but the chain behind it is not. The person who expressed the intent is different from the software that planned the work, which may be different again from the agent that finally called the finance API. Along the way, several systems may have supplied instructions or data that influenced the result.
Most organizations are not set up to preserve that chain of authority. Human identity, agent identity, delegated purpose, and application action are often collapsed into a single API credential or service account. The final log entry shows that something happened, but not the complete path that made it happen.
The problem grows as agents delegate work to other agents. By the time an action reaches an application, the distance between human intent and machine execution may already be several hops long.
The common response is to govern the agent: maintain an inventory of agents, approve their tools, and define which applications each one can access.
That is necessary, but I am no longer convinced it is the right place for the final control.
I think we should invert the model:
Instead of only governing which applications an agent can access, every application should govern which agents may access it, what they may do, and under whose authority.
In other words, agent governance should move closer to the application boundary.
The application understands the risk better than the agent platform
An agent platform can understand that an agent is calling a finance API. The finance application understands that read_invoice, change_bank_account, and release_payment are three completely different levels of risk.
A collaboration platform knows the difference between reading a public channel, reading an executive channel, and sending a message as the CEO. A source-control platform knows the difference between reading a public repository, changing a branch-protection rule, and approving a production deployment.
These distinctions matter because access is not simply a connection between an agent and an application. It is a specific action against a specific resource, under particular conditions.
The application already owns those semantics. It knows:
- Which data is sensitive
- Which operations are reversible
- Which actions affect money, customers, production, or regulated records
- Which thresholds require additional approval
- Which combinations of actions create separation-of-duties problems
The application is therefore in the best position to make the final decision.
This is not a completely new security idea. Zero-trust architecture already places policy enforcement close to the resource being protected. NIST describes a policy enforcement point that guards access to enterprise resources and applies decisions for each request. The difference is that our authorization model now has to understand agents, delegation, and machine-speed execution—not only employees and service accounts.
Do not let the agent become the human
One of the most dangerous shortcuts is to give an agent a person’s normal session or access token.
If Alice can approve a payment, and an agent simply inherits Alice’s identity, the finance application may record:
Alice approved the payment.
But that is incomplete. Alice may have described a goal, an orchestrator may have planned the work, and a specialist agent may have submitted the transaction. Treating all of that as Alice destroys the evidence needed to govern the system.
An application should receive both the human principal and the agent actor. A useful authorization envelope might include:
Human principal: Alice
Agent identity: procurement-agent-v4
Agent owner: Finance Automation Team
Acting for: Alice
Task: Renew an approved software subscription
Delegation chain: Alice → orchestrator → purchasing-agent
Allowed action: Create purchase order
Resource constraint: Approved vendor only
Value limit: $5,000
Expiration: 15 minutesThe application can then make a much better decision. It can permit the agent to draft the purchase order but require Alice to approve it. It can allow purchases from an approved vendor but reject a bank-account change. It can apply a lower transaction limit to an autonomous action than it would to an interactive human action.
Most importantly, the audit log can say:
purchasing-agentcreated the purchase order, acting for Alice, after receiving delegated authority fromorchestrator.
That is far more useful than pretending the agent was Alice.
Delegation should reduce authority, never silently expand it
Agent-to-agent delegation is where the traditional access model starts to break.
Suppose a manager asks an executive assistant agent to organize an offsite. The assistant delegates venue research to one agent, travel planning to another, and purchasing to a third. None of those child agents needs all of the manager’s access.
The research agent may need to browse approved external sites. The travel agent may need employee locations but not compensation data. The purchasing agent may create a draft request but should not release the payment.
A child agent’s authority should be calculated as:
Child authority =
parent authority
∩ requested task authority
∩ enterprise policy
∩ application policyEvery delegation hop should create a new, short-lived credential with less or equal authority. A child agent should never receive the parent’s reusable credential.
Applications should also be able to enforce conditions such as:
- Maximum delegation depth
- Approved agent owners or publishers
- No delegation for particular high-risk operations
- Human approval beyond a defined threshold
- Per-task rate, time, data, or monetary limits
- Immediate revocation of the entire delegation chain
This creates a simple invariant: authority can stay the same or shrink as work moves through the agent chain, but it cannot grow without a new authorization decision.
Application-side enforcement is necessary, but it is not sufficient
Moving enforcement to the application does not mean every application should become an isolated governance island.
An individual application cannot see the complete behavior of an agent across the organization.
Imagine an agent that reads confidential material from a document repository and then pastes it into an external support ticket. The repository may consider the read legitimate. The ticketing system may consider the write legitimate. Neither application sees the dangerous combination.
The agent runtime also sees information that the destination application may not have: which prompts the agent received, which retrieved content influenced its decision, whether that content was trusted, and which tools were considered before the action was taken.
That means we need three complementary layers:
| Layer | Primary responsibility |
|---|---|
| Agent runtime | Contain untrusted content, restrict available tools, preserve task context, and detect suspicious behavior |
| Organization control plane | Register agents, define enterprise policy, manage identities and delegation, revoke authority, and correlate activity across applications |
| Application boundary | Make and enforce the final decision for each operation against the resource it owns |
The principle I keep coming back to is:
Applications own enforcement. The enterprise owns policy. The agent runtime owns containment.
Governance cannot live in only one of these layers.
What an agent-aware application should evaluate
An application does not need to understand how every model or agent framework works. It needs a consistent contract that answers a small number of security questions for every request:
-
Who is requesting the action?
A verifiable workload identity for the specific agent—not merely the name the agent placed in a request header. -
For whom is it acting?
The human, team, service, or business process that delegated the authority. -
What is the task?
A bounded purpose, not a permanent entitlement such as “finance access.” -
What exactly is allowed?
The action, resource, data type, transaction limit, and other relevant constraints. -
How did the authority arrive here?
The delegation chain, including every agent that handled the task. -
What conditions still apply?
Expiration, approval requirements, location, risk level, rate limits, and revocation state. -
How should the action be recorded?
Both the human principal and the machine actor, along with the task and authorization decision.
OAuth standards already provide some useful building blocks. Token Exchange supports impersonation and delegation, including an actor claim. Rich Authorization Requests can express fine-grained authorization details rather than relying only on broad scopes such as read or write. These standards do not solve agent governance by themselves, but they point toward the right kind of authorization envelope.
This changes how we think about blast radius
Today, teams often estimate an agent’s blast radius by listing the tools available to it.
That is only potential blast radius. The real blast radius is determined by what the destination applications will actually accept.
If an agent has a finance connector, that sounds dangerous. If the finance application will only allow it to read invoices for one business unit for ten minutes, the effective blast radius is much smaller. If the same credential can modify every vendor and release unlimited payments, the connector is not the core problem—the authorization model is.
Application-side controls can make blast radius explicit:
- Which records can be read
- Which fields can be changed
- How many actions can be performed
- How much money or data can move
- How long the authorization remains valid
- Whether a human must confirm the final step
- Whether the operation can be reversed
This is a more useful security boundary than a binary answer to “Can the agent access the application?”
A practical path for organizations
Organizations do not need to redesign every application before using agents. A staged approach is more realistic.
Start by treating agents as distinct workload identities. Do not hide them behind human accounts or shared integration users.
Next, include both the human principal and agent actor in authorization decisions and logs. Even if the first policies are simple, preserving that distinction prevents a large audit gap.
Then focus application-side enforcement on high-impact actions: payments, production changes, identity administration, customer communications, sensitive exports, and destructive operations. Put approval thresholds, short-lived credentials, and transaction limits around those paths first.
For agent-to-agent work, require every delegation to be explicit and non-escalating. Mint a new credential for the child agent, restrict it to the destination application, and give it only enough time and authority to complete the task.
Finally, correlate these decisions centrally. The organization still needs an inventory of agents, owners, models, connected applications, delegated identities, and recent activity. It also needs the ability to revoke an agent or task across every application quickly.
The centralized platform should make policy and provide visibility. The application should enforce the decision where the consequence occurs.
The governance question is changing
The original governance question was:
Which applications can this agent access?
That question is becoming too broad to be useful. As agents become more dynamic and begin delegating work, a static allowlist will not tell us enough about intent, authority, or impact.
The better question is:
Should this application allow this agent, acting for this principal, through this delegation chain, to perform this specific action on this resource right now?
That is a longer question, but it is the question our systems actually need to answer.
I do not think agent governance will be solved by one central dashboard that attempts to understand every possible agent and application. Nor will it be solved by asking agents to police themselves.
The scalable model is shared: strong identity and policy across the organization, containment inside the agent runtime, and final enforcement at the application boundary.
When an agent goes sideways, the application should not have to trust that some upstream component will stop it. The application should already know exactly how far that agent is allowed to go.
