Who Is Your AI Agent? Identity, Authorisation, and the Trust Boundary in AI-Native Systems
As AI agents move from generating answers to taking actions, identity and authorization become first-class architecture concerns.
Consider a simple request: “Investigate this customer’s duplicate payment and refund it if appropriate.”
An agent may retrieve the transaction, analyze the issue, select refundPayment(), and execute it.
But the real architecture questions are:
Who is the agent?
On whose behalf is it acting?
What authority has been delegated?
Which tools can it execute?
What limits apply?
When is human approval required?
Who is accountable for the outcome?
These are not prompt-engineering problems. They are trust-boundary problems.
Identity Is Not Authority
Agentic systems often involve multiple principals: User -> Application -> Ageent -> Tool/MCP Server -> Enterprise Service
The system may need to distinguish: Human Identity + Application Identity + Agent Identity + Workload Identity
Collapsing everything into a shared service account may simplify integration, but it weakens authorization and auditability. An agent should increasingly be treated as an identifiable principal.
But identity alone is not enough.
Identity tells us who the agent is. Authority tells us what it is allowed to do.
Think in Terms of an Authority Envelope
An agent should not inherit broad application or user privileges by default.
Its authority should be:
scoped,
contextual,
temporary,
purpose-bound,
and risk-aware.
For example:
Agent: payment-refund-agent Resource: payment-123
Allowed: readPayment, requestRefund
Refund limit: ₹10,000 Purpose: duplicatee-payment-resolution
Expirty: 10 minutes Approval: required above ₹5,000
A useful rule is:
Agent Authority <= Deleegated Authority <= User Authority
The agent should usually receive less authority than the human or application invoking it.
Tool Discovery Is Not Authorization
This distinction becomes critical with tool calling and MCP.
An agent may discover:
getPayment(), retryPayment(), refundPayment(), cancelPayment(), transferFunds()
But:
Can discover ≠ Can execute
The correct boundary is:
Agent -> Proposed Tool Call -> Authorization Layer -> Allow/Deny/Require Approval -> Tool Execution
The LLM may decide:
“refundPayment is the right action.”
The enterprise must independently decide:
“Is this agent allowed to refund this payment, for this user, for this amount, under these conditions?”
That is the real trust boundary.
The Model May Propose. The System Must Authorize.
The agent should not be both the decision-maker and the enforcement point.
For example:
Agent reasoning -> Proposed Action -> Deterministic Policy Enforcement -> Allow/Deny/Approval
Authorization should evaluate context such as:
User+Agent+Resource+Action+Purpose+Risk+Delegation+Enviromment
This goes beyond simple RBAC. Agentic systems will increasingly require contextual and policy-based authorization.
Human Approval Is an Authorization Control
Human-in-the-loop is often discussed as a UX pattern. For high-impact systems, it is better viewed as a risk-based authorization decision.
Low Risk -> Agent executes
Medium Risk -> Human approval
High Risk -> Agent Prohibited
Full autonomy should not always be the target. In regulated or high-impact enterprise systems, human approval may remain a permanent architectural control.
Prompt Injection Makes Authorization More Important
Assume the model can be manipulated.
Malicious Input -> Compromised Reasoning -> Proposed Sensitive Action -> Authorization Layer -> Deny
A secure system should not depend on the model always reasoning correctly. Even if the reasoning fails, the authorization boundary should constrain the blast radius. That is defense in depth.
Agent-to-Agent Delegation Raises the Stakes
Multi-agent systems introduce another challenge:
User -> Coordinator Agent -> Payment Agent -> Fraud Agent
A child agent should not automatically inherit all permissions from its parent.
Delegation should narrow authority.
Child Agent Authority <= Parent Agent Authority
Delegation should carry explicit context:
Who delegated?
To which agent?
For what task?
For what purpose?
Which resources?
Which permissions?
For how long?
Implicit authority inheritance is a dangerous default.
Auditability Must Capture Decision Provenance
For high-impact actions, API logs are not enough.
This:
POST /refund
200 OK
does not answer:
Why did this action happen?
A useful audit record should capture: User, Agent, Agent version, Task, Action, Resource, Policy, Authorization decision, Human approval, Execution result, Trace ID
The goal is not to store unrestricted chain-of-thought. The goal is to preserve decision provenance.
A Reference Architecture
A mature design should separate reasoning from authorization:
The principle is simple:
Reasoning happens inside the agent. Authorization happens outside it.
Five Principles I Would Use
Treat agents as identifiable principals.
Separate identity from delegated authority.
Tool availability does not imply execution permission.
Delegate less authority than the caller possesses.
Authorization must remain effective even when the model reasons incorrectly.
Final Thought
As agents become capable of executing real-world actions, the most important security question may no longer be:
“Which model are we using?”
It may become:
“What authority does this agent have right now?”
Identity should not remain an implementation detail.
Authorization should not live inside a system prompt.
The agent may reason, plan, and select tools.
But before any action reaches the real world, the enterprise must independently decide:
Is this agent authorized to perform this action, on behalf of this principal, on this resource, under these conditions?
That is the trust boundary.
And in AI-native systems, it may matter more than the model itself.
Comments