A
Atul Kumar
Guest
We have spent decades designing identity systems around one basic assumption: there is a human being on the other side of the screen.
A person signs in, receives a set of permissions, performs an action, and leaves behind an audit trail. Whether the system uses usernames and passwords, OAuth, SSO, certificates, service accounts, or some combination of them, the underlying model is relatively familiar. There is a person, an organisation, and also a recognisable relationship between the two.
AI agents are beginning to challenge that model. An agent can now read documents, access databases, call APIs, create tickets, review transactions, interact with customers, write and deploy code, monitor systems, and make decisions without a human manually executing every step. More importantly, an agent can continue working after the person who initiated the task has left the workflow.
That creates a different kind of identity problem. When an agent sends a request to an internal API, the question should not simply be, "Which user is making this request?" We need to understand which agent acted, what that agent was created to do, who owns it, who authorised it, what authority it was delegated, which credentials it used, which policy governed the action, and whether the agent was actually allowed to perform that operation at that moment.
A user account was never designed to answer all those questions; that is why I believe we need to treat agent identity as a first-class architectural concept rather than simply giving autonomous systems another service account and calling the problem solved.
Giving an agent a service account is an understandable starting point. It is simple, familiar, and works reasonably well when the agent is performing a small number of predictable tasks inside a controlled environment.
The problem appears when agents become more capable and more deeply integrated into business systems. Imagine an organisation running several agents: a customer-support agent, a finance reconciliation agent, a procurement agent, a security-monitoring agent, and a software-engineering agent. Each one performs a different type of work, interacts with different systems, and carries a different level of risk.
If all of them are represented simply as service accounts, the identity model quickly becomes shallow. Suppose the finance agent approves an invoice. An audit log might tell us that
Who authorised that agent? Was the invoice approval within the agent's delegated responsibility? Which version of the agent operated? Which policy was active at the time? Was the agent acting on a task initiated by a finance manager, another agent, or an automated workflow? What credentials were used? Were those credentials temporary or permanent? Was the agent still authorised to approve invoices when the action happened?
Those questions aren't theoretical. The more autonomy we give agents, the more important these details become. An identity for an autonomous agent therefore needs to represent more than authentication. It needs to establish a relationship between the agent, its authority, its owner, its delegation chain, its capabilities, and the actions it performs.
Authentication answers a relatively narrow question: who are you? That remains important, but it is only one part of the problem.
For an agent operating inside an enterprise environment, identity needs to connect several layers. We need to know who the agent is, how that identity was authenticated, what the agent is authorised to do, who delegated that authority, what action it performed, and whether the authority is still valid. I think about the relationship roughly as:
These aren't independent features that can be added later. They influence each other. An authenticated agent without meaningful authorisation boundaries is dangerous. An authorised agent without delegation context is difficult to audit. An agent that cannot be revoked quickly is difficult to operate safely. An audit system that records only a generic service account cannot reconstruct why an action was allowed.
As agents become more autonomous, these relationships need to become part of the platform rather than being left to individual application developers.
One of the first design decisions I would make is to avoid representing an agent simply as a human user. Suppose a finance manager asks an agent to review a group of invoices and identify suspicious ones. The manager has delegated a responsibility to the agent, but that does not mean the agent should appear in every downstream system as though the manager personally performed each action.
There are two different actors involved. The human provided authority, and the agent performed the work. That distinction should remain visible. A useful representation might look like this:
An audit event could then contain information such as:
This is significantly more useful than recording only the name of a service account. It also creates a cleaner separation between identity and authority. The agent has an identity, but the authority it exercises comes from a defined delegation.
This distinction becomes especially important when credentials are rotated. Consider an agent with the following identity:
Today, it might authenticate using one OAuth credential. Tomorrow, that credential expires and a new one is issued. From a security perspective, the credential changed. From an identity perspective, the agent did not. The relationship should therefore look more like:
This may sound obvious, but it has important consequences for auditability. If an API key is treated as the agent's identity, rotating the key can make historical events difficult to connect. If the identity is stable and credentials are treated as authentication mechanisms belonging to that identity, credential rotation becomes an operational detail rather than an identity change.
The same principle applies to the model powering the agent. A customer-support agent might use one model today and another model six months from now. The implementation has changed, but the business identity of the agent may remain the same; that means a useful audit record should be able to tell us both things:
Later, the same agent might operate with a different model:
The identity remains stable while the implementation evolves.
An agent identity should never automatically imply unlimited authority. Consider a customer-support agent. It might legitimately need to read customer profiles, inspect order history, create support tickets, and issue refunds below a certain amount; that does not mean it should be able to change account ownership, modify bank details, delete customer records, access payroll information, or issue unlimited refunds. A capability model makes those boundaries more explicit:
The important idea here is that the agent does not merely have a broad role such as
An agent might be aware that a payment API exists, but that doesn't mean it should have permission to invoke it. The execution layer should make that decision.
Human organisations already depend heavily on delegation. A manager gives an employee responsibility for a task. A team grants another team access to a system. A workflow authorises an automated process to perform a particular operation. Agents make delegation much more dynamic. Imagine a chain such as:
If the payment verification tool operates, the system should be able to reconstruct why that operation was authorised. It should be possible to trace the authority backwards:
This doesn't mean every action needs to expose a huge chain in a user interface. It means the system should preserve the relationship so that it can be reconstructed when necessary; that becomes particularly valuable during security investigations.
If someone asks, "Why did this agent have access to this payment system?", the answer should not be hidden inside a configuration file that was changed six months ago. The system should be able to explain the delegation.
There is a subtle problem here that becomes more important as multi-agent architectures become common.
Suppose Agent A has permission to read customer information. Agent A creates Agent B to help complete a task. If Agent B automatically inherits everything Agent A can do, the system can unintentionally create permission amplification.
A safer principle is that delegated authority should normally be a constrained subset of the authority available to the delegating actor. Conceptually:
And:
If Agent A has
I don't think agent identity should be treated as something that is created once and then left alone. An autonomous agent has a lifecycle, and its identity should reflect that lifecycle. A useful model is:
Each stage represents a different operational state.
When an agent is created, the organisation should establish its purpose, owner, environment, risk classification, and initial capabilities.
When it is registered, it should receive a durable identity that is independent of its credentials and model.
When it is provisioned, the necessary credentials and permissions can be attached to that identity.
When it is activated, the identity becomes available to perform its assigned responsibilities.
When authority is delegated, the system should capture who delegated it, what was delegated, why the delegation exists, and how long it should remain valid.
During operation, consequential actions should be attributable to the identity. Credentials will eventually need to rotate, policies will change, and the underlying model may be replaced. None of those events should require creating an entirely new business identity.
If something suspicious happens, the agent may need to be suspended temporarily while its identity and audit history remain intact. If its authority is permanently withdrawn, the identity can be revoked while historical records are preserved. Eventually, the agent can be retired. That lifecycle is much closer to how we manage important enterprise identities than simply creating an API key and leaving it active indefinitely.
A short-lived interaction and a long-running autonomous agent create very different security assumptions. A chatbot session may last a few minutes. An agent responsible for monitoring invoices or managing infrastructure might continue operating for days or weeks. That creates an important question: Does authority granted at the beginning of a task remain valid when the agent eventually performs the action? The answer cannot always be yes.
The person who delegated the task might have changed roles. The business policy might have changed. The resource might have become more sensitive. The agent's capabilities might have been reduced. The task itself might have expired. For high-impact actions, authorisation should therefore be capable of being evaluated at execution time rather than only when the agent starts. A permission granted at 09:00 is not automatically proof that the same permission is valid at 17:00. This is especially important for agents that operate asynchronously. The longer an agent lives, the more important it becomes to treat authority as something that can change over time.
This sounds obvious, but autonomous agents create unusual situations. An agent may encounter a task that requires access to a system it currently cannot reach. Its natural response might be to request additional permissions. That request is reasonable.
What should not happen is the agent deciding that it needs additional authority and then granting that authority to itself. A safer flow looks like:
The important point is that the mechanism granting authority remains outside the agent's own control. Otherwise, the agent's autonomy can become a mechanism for bypassing the very authorisation system intended to control it.
There is another distinction I think is important: having a capability is not always enough to act. An agent might be allowed to issue refunds up to $100, but that doesn't mean every $100 refund should automatically be accepted.
Authorisation can depend on context. For example:
The final decision can then be evaluated by a policy engine or authorisation layer. For example:
The agent can propose the action, but the authorisation layer should be responsible for enforcing the constraints. This is another important boundary between probabilistic reasoning and deterministic control. The model can recommend an action. The system should decide whether the action is permitted.
A useful agent audit record should help reconstruct not only what happened, but why it was allowed to happen. A consequential event might contain information such as:
There is a big difference between this and a log entry saying:
The second tells us what happened. The first gives us the context required to investigate it. It tells us which agent acted, which version was running, which model was involved, who delegated the work, which policy governed it, which credential authenticated it, and what resource was affected.
As autonomous systems become responsible for more consequential operations, that context will become increasingly important.
When an agent performs an incorrect action, saying "the AI did it" isn't particularly useful. The actual execution path may look like:
The human may have delegated the responsibility. The agent may have selected the action. The policy engine may have authorised it. A tool may have executed it. The database may have accepted it. If we want meaningful accountability, the system needs to preserve enough information to reconstruct that chain.
This doesn't mean blaming a particular component every time something goes wrong. It means making the system explainable from an operational perspective.
We should be able to answer questions such as:
Without that information, investigating autonomous behaviour becomes unnecessarily difficult.
Multi-agent systems introduce another interesting identity problem. Imagine a research agent deciding that it needs a specialised data-analysis agent. The research agent creates one, delegates a limited task, and allows the child agent to access a database. We now have:
The child agent should have its own identity, but that identity should preserve its relationship to the parent. For example:
Now the system can answer why that child agent had database access. The answer isn't simply "because it had a credential." The system can reconstruct the authority path that led to that credential and capability. This becomes increasingly important as agents begin creating specialised agents dynamically rather than having every possible agent manually provisioned in advance.
Putting these ideas together, I think an agent identity should be managed around a lifecycle rather than a single authentication event. The framework I use to think about it is the Agent Identity Lifecycle:
At creation, the system establishes what the agent is for and who owns it. Registration gives it a stable identity. Provisioning attaches the credentials and capabilities it needs. Activation makes it operational.
Delegation establishes the authority under which the agent is allowed to work. During operation, actions are associated with that identity and delegation chain. Credentials can rotate without changing the identity itself. If the agent becomes suspicious or needs investigation, its authority can be suspended. If the organisation no longer trusts or needs it, the authority can be revoked. Finally, the identity can be retired while its historical actions remain available for audit.
This lifecycle gives us something that a simple service account doesn't: a way to reason about the entire existence of an autonomous software actor.
If I were designing an agent platform today, I would not make every development team solve these problems independently. Identity should be a platform capability. Every agent should receive a stable identity that survives model changes and credential rotation. Credentials should preferably be short-lived and independently rotatable. Capabilities should be narrowly scoped to the tools and actions the agent actually needs.
Delegation should be explicit, and delegated authority should not exceed the authority of the actor granting it. High-impact permissions should be evaluated at runtime rather than being assumed to remain valid indefinitely. Every consequential action should produce an audit event that captures the agent, agent version, delegation context, policy version, credential, resource, action, and outcome.
Most importantly, revocation should be built into the platform from the beginning. When an agent needs to be stopped, we should not have to hunt through multiple systems trying to determine which API keys, OAuth grants, service accounts, and tool permissions are still active.
The goal isn't to make agents bureaucratic. The goal is to make autonomy manageable.
For a long time, the main question around AI agents was whether they could actually perform useful work. That question is changing. Agents can already perform useful work. They can search, analyse, write, classify, monitor, communicate, and interact with business systems. The more interesting question now is what happens when we give them enough authority to operate without constant human intervention.
At that point, identity stops being an implementation detail. It becomes part of the architecture. A system that gives an agent access to customer data, financial systems, production infrastructure, or internal business operations needs to know exactly what that agent is, why it has access, who authorised it, and how to stop it. This is particularly important because agent identity will often exist across multiple systems. The agent may authenticate against one service, retrieve data from another, call a third-party API, and then write to an internal database.
If each system has a different representation of the agent, the organisation can quickly lose the ability to establish a consistent identity across the entire execution chain. That is why stable identity, delegation, capability boundaries, and auditability need to be designed together.
The comparison between AI agents and employees can be useful, but it has limits. An agent isn't an employee. It doesn't have the legal, organisational, or human characteristics that make employment meaningful, but the comparison highlights one important issue: when something is given responsibility to perform work, the organisation needs to define the boundaries of that responsibility.
For humans, organisations have established mechanisms for this over many years: job roles, access badges, permissions, managers, approval processes, audit trails, and termination procedures. Agents need an equivalent technical structure, but one designed for software that can operate continuously, change models, delegate tasks, and interact with other software autonomously. That is a very different identity problem.
I don't think the future of AI agents will be determined only by how intelligent the underlying models become. It will also depend on whether organisations can trust those agents with meaningful authority.
Giving an agent a prompt, a model, and a collection of tools is relatively easy. The difficult part begins when that agent can approve a payment, modify production infrastructure, access sensitive customer information, create another agent, or make a decision on behalf of an organisation.
At that point, a service account is no longer enough. We need to know who the agent is. We need to know who owns it and who gave it authority. We need to know what it is allowed to do and under what conditions. We need to know which credentials it used, which policies were active, and what actions it performed. We also need to know which other agents it delegated work to and whether that delegation was legitimate, and when the authority is no longer justified, we need to be able to take it away without destroying the history of what the agent did. That is why I think the next stage of agent infrastructure is not simply better authentication. It is agent identity management.
The important question is no longer: "How do we authenticate an AI agent?"
It is: "How do we establish identity, authority, accountability, and control across the entire life of an autonomous agent?"
If agents are going to become real actors in our software systems, they need identities that reflect what they actually are: autonomous software entities operating within defined boundaries, and those boundaries need to be designed before we give the agents more responsibility.
A person signs in, receives a set of permissions, performs an action, and leaves behind an audit trail. Whether the system uses usernames and passwords, OAuth, SSO, certificates, service accounts, or some combination of them, the underlying model is relatively familiar. There is a person, an organisation, and also a recognisable relationship between the two.
AI agents are beginning to challenge that model. An agent can now read documents, access databases, call APIs, create tickets, review transactions, interact with customers, write and deploy code, monitor systems, and make decisions without a human manually executing every step. More importantly, an agent can continue working after the person who initiated the task has left the workflow.
That creates a different kind of identity problem. When an agent sends a request to an internal API, the question should not simply be, "Which user is making this request?" We need to understand which agent acted, what that agent was created to do, who owns it, who authorised it, what authority it was delegated, which credentials it used, which policy governed the action, and whether the agent was actually allowed to perform that operation at that moment.
A user account was never designed to answer all those questions; that is why I believe we need to treat agent identity as a first-class architectural concept rather than simply giving autonomous systems another service account and calling the problem solved.
An Agent Is Not Just Another User
Giving an agent a service account is an understandable starting point. It is simple, familiar, and works reasonably well when the agent is performing a small number of predictable tasks inside a controlled environment.
The problem appears when agents become more capable and more deeply integrated into business systems. Imagine an organisation running several agents: a customer-support agent, a finance reconciliation agent, a procurement agent, a security-monitoring agent, and a software-engineering agent. Each one performs a different type of work, interacts with different systems, and carries a different level of risk.
If all of them are represented simply as service accounts, the identity model quickly becomes shallow. Suppose the finance agent approves an invoice. An audit log might tell us that
[email protected] approved an invoice 89231 at 14:32. That tells us who the system believes acted, but it doesn't answer several questions that become important during an investigation.Who authorised that agent? Was the invoice approval within the agent's delegated responsibility? Which version of the agent operated? Which policy was active at the time? Was the agent acting on a task initiated by a finance manager, another agent, or an automated workflow? What credentials were used? Were those credentials temporary or permanent? Was the agent still authorised to approve invoices when the action happened?
Those questions aren't theoretical. The more autonomy we give agents, the more important these details become. An identity for an autonomous agent therefore needs to represent more than authentication. It needs to establish a relationship between the agent, its authority, its owner, its delegation chain, its capabilities, and the actions it performs.
Identity Is More Than Authentication
Authentication answers a relatively narrow question: who are you? That remains important, but it is only one part of the problem.
For an agent operating inside an enterprise environment, identity needs to connect several layers. We need to know who the agent is, how that identity was authenticated, what the agent is authorised to do, who delegated that authority, what action it performed, and whether the authority is still valid. I think about the relationship roughly as:
Code:
Identity
↓
Authentication
↓
Authorization
↓
Delegation
↓
Action
↓
Audit
↓
RevocationThese aren't independent features that can be added later. They influence each other. An authenticated agent without meaningful authorisation boundaries is dangerous. An authorised agent without delegation context is difficult to audit. An agent that cannot be revoked quickly is difficult to operate safely. An audit system that records only a generic service account cannot reconstruct why an action was allowed.
As agents become more autonomous, these relationships need to become part of the platform rather than being left to individual application developers.
The Agent Should Have an Identity of Its Own
One of the first design decisions I would make is to avoid representing an agent simply as a human user. Suppose a finance manager asks an agent to review a group of invoices and identify suspicious ones. The manager has delegated a responsibility to the agent, but that does not mean the agent should appear in every downstream system as though the manager personally performed each action.
There are two different actors involved. The human provided authority, and the agent performed the work. That distinction should remain visible. A useful representation might look like this:
Code:
Human / Business Owner
|
| Delegates authority
↓
Finance Review Agent
|
| Performs action
↓
Enterprise SystemAn audit event could then contain information such as:
Code:
Agent: finance-review-agent-42
Delegated by: finance-manager-781
Task: Review invoices
Capabilities: invoice.read, invoice.flag
Policy: finance-review-v12
Action: Invoice #89231 flagged
Agent version: 3.8.2
Timestamp: 14:32:17This is significantly more useful than recording only the name of a service account. It also creates a cleaner separation between identity and authority. The agent has an identity, but the authority it exercises comes from a defined delegation.
Credentials Are Not Identity
This distinction becomes especially important when credentials are rotated. Consider an agent with the following identity:
Code:
Agent:
finance-reconciliation-agent-42Today, it might authenticate using one OAuth credential. Tomorrow, that credential expires and a new one is issued. From a security perspective, the credential changed. From an identity perspective, the agent did not. The relationship should therefore look more like:
Code:
Agent Identity
|
+---- Credential A
|
+---- Credential B
|
+---- Credential CThis may sound obvious, but it has important consequences for auditability. If an API key is treated as the agent's identity, rotating the key can make historical events difficult to connect. If the identity is stable and credentials are treated as authentication mechanisms belonging to that identity, credential rotation becomes an operational detail rather than an identity change.
The same principle applies to the model powering the agent. A customer-support agent might use one model today and another model six months from now. The implementation has changed, but the business identity of the agent may remain the same; that means a useful audit record should be able to tell us both things:
Code:
Agent:
customer-support-agent-17
Model:
Model X
Agent version:
4.2.1Later, the same agent might operate with a different model:
Code:
Agent:
customer-support-agent-17
Model:
Model Y
Agent version:
5.0.0The identity remains stable while the implementation evolves.
Authorisation Should Be Attached to Capabilities
An agent identity should never automatically imply unlimited authority. Consider a customer-support agent. It might legitimately need to read customer profiles, inspect order history, create support tickets, and issue refunds below a certain amount; that does not mean it should be able to change account ownership, modify bank details, delete customer records, access payroll information, or issue unlimited refunds. A capability model makes those boundaries more explicit:
Code:
{
"agent_id": "support-agent-42",
"capabilities": [
"customer.read",
"orders.read",
"ticket.create",
"refund.create"
],
"limits": {
"refund.max_amount": 100
}
}The important idea here is that the agent does not merely have a broad role such as
support-agent. Its authority is expressed through specific capabilities and constraints; this becomes even more important when an agent can discover and use tools dynamically. Seeing a tool and being authorised to use a tool should not be the same thing.An agent might be aware that a payment API exists, but that doesn't mean it should have permission to invoke it. The execution layer should make that decision.
Delegation Is a Core Part of Agent Identity
Human organisations already depend heavily on delegation. A manager gives an employee responsibility for a task. A team grants another team access to a system. A workflow authorises an automated process to perform a particular operation. Agents make delegation much more dynamic. Imagine a chain such as:
Code:
CFO
↓
Finance Agent
↓
Reconciliation Agent
↓
Payment Verification ToolIf the payment verification tool operates, the system should be able to reconstruct why that operation was authorised. It should be possible to trace the authority backwards:
Code:
Human Authority
↓
Finance Agent
↓
Reconciliation Agent
↓
Tool
↓
External SystemThis doesn't mean every action needs to expose a huge chain in a user interface. It means the system should preserve the relationship so that it can be reconstructed when necessary; that becomes particularly valuable during security investigations.
If someone asks, "Why did this agent have access to this payment system?", the answer should not be hidden inside a configuration file that was changed six months ago. The system should be able to explain the delegation.
Delegation Must Not Become Permission Multiplication
There is a subtle problem here that becomes more important as multi-agent architectures become common.
Suppose Agent A has permission to read customer information. Agent A creates Agent B to help complete a task. If Agent B automatically inherits everything Agent A can do, the system can unintentionally create permission amplification.
A safer principle is that delegated authority should normally be a constrained subset of the authority available to the delegating actor. Conceptually:
Code:
Parent Authority
↓
Delegation Policy
↓
Child AuthorityAnd:
Code:
Child Authority
⊆
Delegated Authority
⊆
Parent AuthorityIf Agent A has
customer.read, it should not be able to create Agent B with customer.delete or payment.approveunless there is an independent authorisation mechanism that explicitly allows that expansion. This is one of the areas where autonomous systems force us to think differently about traditional access control. The problem is no longer only "what can this identity do?" It also becomes "what authority can this identity pass on?"An Agent Identity Needs a Lifecycle
I don't think agent identity should be treated as something that is created once and then left alone. An autonomous agent has a lifecycle, and its identity should reflect that lifecycle. A useful model is:
Code:
Create
↓
Register
↓
Provision
↓
Activate
↓
Delegate
↓
Operate
↓
Rotate
↓
Suspend
↓
Revoke
↓
RetireEach stage represents a different operational state.
When an agent is created, the organisation should establish its purpose, owner, environment, risk classification, and initial capabilities.
When it is registered, it should receive a durable identity that is independent of its credentials and model.
When it is provisioned, the necessary credentials and permissions can be attached to that identity.
When it is activated, the identity becomes available to perform its assigned responsibilities.
When authority is delegated, the system should capture who delegated it, what was delegated, why the delegation exists, and how long it should remain valid.
During operation, consequential actions should be attributable to the identity. Credentials will eventually need to rotate, policies will change, and the underlying model may be replaced. None of those events should require creating an entirely new business identity.
If something suspicious happens, the agent may need to be suspended temporarily while its identity and audit history remain intact. If its authority is permanently withdrawn, the identity can be revoked while historical records are preserved. Eventually, the agent can be retired. That lifecycle is much closer to how we manage important enterprise identities than simply creating an API key and leaving it active indefinitely.
Long-Running Agents Change the Meaning of Authorisation
A short-lived interaction and a long-running autonomous agent create very different security assumptions. A chatbot session may last a few minutes. An agent responsible for monitoring invoices or managing infrastructure might continue operating for days or weeks. That creates an important question: Does authority granted at the beginning of a task remain valid when the agent eventually performs the action? The answer cannot always be yes.
The person who delegated the task might have changed roles. The business policy might have changed. The resource might have become more sensitive. The agent's capabilities might have been reduced. The task itself might have expired. For high-impact actions, authorisation should therefore be capable of being evaluated at execution time rather than only when the agent starts. A permission granted at 09:00 is not automatically proof that the same permission is valid at 17:00. This is especially important for agents that operate asynchronously. The longer an agent lives, the more important it becomes to treat authority as something that can change over time.
The Agent Should Not Be Able to Grant Itself More Authority
This sounds obvious, but autonomous agents create unusual situations. An agent may encounter a task that requires access to a system it currently cannot reach. Its natural response might be to request additional permissions. That request is reasonable.
What should not happen is the agent deciding that it needs additional authority and then granting that authority to itself. A safer flow looks like:
Code:
Agent requests capability
↓
Authorization policy evaluates request
↓
Human or authorized system approves
↓
Temporary capability issued
↓
Agent performs action
↓
Capability expiresThe important point is that the mechanism granting authority remains outside the agent's own control. Otherwise, the agent's autonomy can become a mechanism for bypassing the very authorisation system intended to control it.
Runtime Authorisation Matters
There is another distinction I think is important: having a capability is not always enough to act. An agent might be allowed to issue refunds up to $100, but that doesn't mean every $100 refund should automatically be accepted.
Authorisation can depend on context. For example:
Code:
Agent identity
+
Requested action
+
Target resource
+
Amount
+
Customer state
+
Fraud state
+
Current policy
+
Delegation statusThe final decision can then be evaluated by a policy engine or authorisation layer. For example:
Code:
Can support-agent-42
refund order-9821
for $75
under policy support-refund-v12?The agent can propose the action, but the authorisation layer should be responsible for enforcing the constraints. This is another important boundary between probabilistic reasoning and deterministic control. The model can recommend an action. The system should decide whether the action is permitted.
Auditability Needs to Capture the Authority Chain
A useful agent audit record should help reconstruct not only what happened, but why it was allowed to happen. A consequential event might contain information such as:
Code:
{
"event_id": "evt-92831",
"agent_id": "finance-agent-42",
"agent_version": "3.8.2",
"model": "model-x",
"delegated_by": "user-781",
"task_id": "task-4421",
"action": "invoice.approve",
"resource": "invoice-89231",
"policy_version": "finance-policy-v12",
"credential_id": "cred-918",
"timestamp": "2026-09-25T10:32:17Z",
"result": "approved"
}There is a big difference between this and a log entry saying:
Code:
finance-agent approved invoiceThe second tells us what happened. The first gives us the context required to investigate it. It tells us which agent acted, which version was running, which model was involved, who delegated the work, which policy governed it, which credential authenticated it, and what resource was affected.
As autonomous systems become responsible for more consequential operations, that context will become increasingly important.
Accountability Is a System Property
When an agent performs an incorrect action, saying "the AI did it" isn't particularly useful. The actual execution path may look like:
Code:
Human
↓
Agent
↓
Policy Engine
↓
Tool
↓
API
↓
DatabaseThe human may have delegated the responsibility. The agent may have selected the action. The policy engine may have authorised it. A tool may have executed it. The database may have accepted it. If we want meaningful accountability, the system needs to preserve enough information to reconstruct that chain.
This doesn't mean blaming a particular component every time something goes wrong. It means making the system explainable from an operational perspective.
We should be able to answer questions such as:
- Which agent made the decision?
- Who delegated the task?
- Which authority did the agent have?
- Which policy authorised the action?
- Which credential was used?
- Which tool executed it?
- Which version of the agent was running?
- Was the action within the agent's delegated scope?
Without that information, investigating autonomous behaviour becomes unnecessarily difficult.
What Happens When an Agent Creates Another Agent?
Multi-agent systems introduce another interesting identity problem. Imagine a research agent deciding that it needs a specialised data-analysis agent. The research agent creates one, delegates a limited task, and allows the child agent to access a database. We now have:
Code:
Human
↓
Research Agent
↓
Data Analysis Agent
↓
DatabaseThe child agent should have its own identity, but that identity should preserve its relationship to the parent. For example:
Code:
Child Agent:
data-analysis-agent-81
Created by:
research-agent-22
Delegated capability:
analytics.read
Purpose:
Analyze research dataset
Expiration:
2 hoursNow the system can answer why that child agent had database access. The answer isn't simply "because it had a credential." The system can reconstruct the authority path that led to that credential and capability. This becomes increasingly important as agents begin creating specialised agents dynamically rather than having every possible agent manually provisioned in advance.
The Agent Identity Lifecycle
Putting these ideas together, I think an agent identity should be managed around a lifecycle rather than a single authentication event. The framework I use to think about it is the Agent Identity Lifecycle:
Code:
Create
↓
Register
↓
Provision
↓
Activate
↓
Delegate
↓
Operate
↓
Rotate
↓
Suspend
↓
Revoke
↓
RetireAt creation, the system establishes what the agent is for and who owns it. Registration gives it a stable identity. Provisioning attaches the credentials and capabilities it needs. Activation makes it operational.
Delegation establishes the authority under which the agent is allowed to work. During operation, actions are associated with that identity and delegation chain. Credentials can rotate without changing the identity itself. If the agent becomes suspicious or needs investigation, its authority can be suspended. If the organisation no longer trusts or needs it, the authority can be revoked. Finally, the identity can be retired while its historical actions remain available for audit.
This lifecycle gives us something that a simple service account doesn't: a way to reason about the entire existence of an autonomous software actor.
What I Would Build Into an Agent Platform
If I were designing an agent platform today, I would not make every development team solve these problems independently. Identity should be a platform capability. Every agent should receive a stable identity that survives model changes and credential rotation. Credentials should preferably be short-lived and independently rotatable. Capabilities should be narrowly scoped to the tools and actions the agent actually needs.
Delegation should be explicit, and delegated authority should not exceed the authority of the actor granting it. High-impact permissions should be evaluated at runtime rather than being assumed to remain valid indefinitely. Every consequential action should produce an audit event that captures the agent, agent version, delegation context, policy version, credential, resource, action, and outcome.
Most importantly, revocation should be built into the platform from the beginning. When an agent needs to be stopped, we should not have to hunt through multiple systems trying to determine which API keys, OAuth grants, service accounts, and tool permissions are still active.
The goal isn't to make agents bureaucratic. The goal is to make autonomy manageable.
Why This Matters Now
For a long time, the main question around AI agents was whether they could actually perform useful work. That question is changing. Agents can already perform useful work. They can search, analyse, write, classify, monitor, communicate, and interact with business systems. The more interesting question now is what happens when we give them enough authority to operate without constant human intervention.
At that point, identity stops being an implementation detail. It becomes part of the architecture. A system that gives an agent access to customer data, financial systems, production infrastructure, or internal business operations needs to know exactly what that agent is, why it has access, who authorised it, and how to stop it. This is particularly important because agent identity will often exist across multiple systems. The agent may authenticate against one service, retrieve data from another, call a third-party API, and then write to an internal database.
If each system has a different representation of the agent, the organisation can quickly lose the ability to establish a consistent identity across the entire execution chain. That is why stable identity, delegation, capability boundaries, and auditability need to be designed together.
We Don't Need Agents to Become Employees
The comparison between AI agents and employees can be useful, but it has limits. An agent isn't an employee. It doesn't have the legal, organisational, or human characteristics that make employment meaningful, but the comparison highlights one important issue: when something is given responsibility to perform work, the organisation needs to define the boundaries of that responsibility.
For humans, organisations have established mechanisms for this over many years: job roles, access badges, permissions, managers, approval processes, audit trails, and termination procedures. Agents need an equivalent technical structure, but one designed for software that can operate continuously, change models, delegate tasks, and interact with other software autonomously. That is a very different identity problem.
Final Thought
I don't think the future of AI agents will be determined only by how intelligent the underlying models become. It will also depend on whether organisations can trust those agents with meaningful authority.
Giving an agent a prompt, a model, and a collection of tools is relatively easy. The difficult part begins when that agent can approve a payment, modify production infrastructure, access sensitive customer information, create another agent, or make a decision on behalf of an organisation.
At that point, a service account is no longer enough. We need to know who the agent is. We need to know who owns it and who gave it authority. We need to know what it is allowed to do and under what conditions. We need to know which credentials it used, which policies were active, and what actions it performed. We also need to know which other agents it delegated work to and whether that delegation was legitimate, and when the authority is no longer justified, we need to be able to take it away without destroying the history of what the agent did. That is why I think the next stage of agent infrastructure is not simply better authentication. It is agent identity management.
The important question is no longer: "How do we authenticate an AI agent?"
It is: "How do we establish identity, authority, accountability, and control across the entire life of an autonomous agent?"
If agents are going to become real actors in our software systems, they need identities that reflect what they actually are: autonomous software entities operating within defined boundaries, and those boundaries need to be designed before we give the agents more responsibility.