Understand It
An AI agent is no longer just generating an answer.
It can search your systems, read customer data, call APIs, create records, make decisions, and perform actions on someone's behalf. Once an agent can do these things, your systems need to know which agent is acting, what it is allowed to do, and who it is acting for.
Consider a customer using a travel application. They ask an assistant to find flights for an upcoming trip. The assistant searches available flights and returns the options. The customer selects one and asks the assistant to book it.
To the customer, this is one conversation. To your backend, however, the two actions can represent different identity situations:
- The agent searches for flights using its own authority.
- The agent books a flight on behalf of the customer.
That distinction matters. Your APIs need to be able to tell not only what happened, but also which agent performed the action and whose authority it was using.
The Problem
When an agent is first introduced into an application, it is tempting to give it an existing API key, service account, or application credential and start making calls.
That works until the agent becomes a real participant in your system.
A shared or borrowed credential can tell you that something trusted made a request, but it does not give you a reliable identity model for the individual agent. As your agents become more capable, you start facing questions such as:
-
Which agent actually made this call? If several agents share the same application or service credential, your APIs and audit trails cannot reliably distinguish them. You need an identity that belongs to the agent itself.
-
What is this agent allowed to do? An agent that can search bookings should not automatically be able to cancel them. Its identity needs to carry permissions that match what the agent is actually allowed to access.
-
What happens if an agent's credential is compromised? A long-lived credential stored in configuration or infrastructure can become a broad point of access. You need credentials and tokens that can be managed, rotated, and revoked without treating the entire application as one identity.
-
Is the agent acting for itself or for a user? When an agent performs an operation because a customer requested it, your services need to distinguish the customer who authorized the action from the agent that actually performed it.
-
Can I trace an action back to the agent that performed it? When something goes wrong, logs that only identify a generic application or service account are not enough. You need to know which agent performed the operation and under whose authority.
-
Who is allowed to use the agent? An agent may expose capabilities that should not be available to every user or application. Access to the agent itself needs to be authenticated and authorized.
-
What about work that happens without a user present? Scheduled or autonomous agents may perform work without an interactive sign-in. They still need a verifiable identity and controlled permissions when they access protected resources.
These are not separate problems. They all come back to one fundamental requirement:
An agent that can act in your system needs an identity of its own.
How It Works
AgentID management gives each agent a distinct identity that your systems can recognize, authenticate, authorize, and trace.
Instead of treating an agent as an extension of another application or user, the identity layer registers the agent as its own principal. The agent gets credentials of its own, and its access can be controlled through the roles and permissions associated with that identity.
When the agent calls a protected API, it presents a token issued for that identity. Your services can then make authorization decisions based on what the token represents rather than trusting information supplied by the agent itself.
The identity represented by the token depends on how the agent is acting.
When the agent acts on its own, the agent is the subject of the token. The receiving service can determine that the request came from that specific agent and authorize it according to the agent's permissions.
When the agent acts on behalf of a user, the token can represent the user as the subject while identifying the agent as the actor. This lets a service answer both questions at once:
- Who authorized the action? The user.
- Who performed the action? The agent.
This distinction is important for both authorization and accountability. Your services can enforce the appropriate permissions while retaining a clear record of the agent involved in the operation.
Each protected service can verify the token itself or rely on the identity layer to validate it, and then authorize the request based on the identity and permissions represented by the token.
The result is an identity model where agents are no longer anonymous pieces of application logic. They become manageable, independently identifiable principals with controlled access and traceable actions.
- Your users sign in to a consumer application and no agent is involved: see Secure Consumer Access to Your Application.
- You are protecting a Model Context Protocol (MCP) server rather than an agent: see Securing MCP.
None of this is a proprietary protocol. It is standard OAuth2 and OpenID Connect, so the token your services already know how to verify is the token an agent presents. By the end of this section you will have agents registered with their own credentials, roles that decide what each one may reach, and APIs that authorize every call against the token it presents.
