Reference Implementations and Patterns
This section provides actionable implementation patterns and real-world examples that demonstrate how organizations can effectively apply IAM principles to support AI agents.
Agent Onboarding
Onboarding involves provisioning an AI agent as a unique, non-human, entity in the IAM system.
Onboarding Managed Agents
These are the agents managed by the organization, most likely API interacting agents such as chatbots or digital workers.
Create a dedicated client/application for the agent. The agent will identify itself using the client-id assigned to this client – even if the agent is integrated into the existing client application UI.
Enable access delegation flows for this client (e.g. device-flow, token-exchange, assertion-grant) and assure the agent supports the selected flow type. Device-flow is the simplest and most commonly supported flow in most use-cases.
Assign scopes according to the minimal desired privileges to the agent. Consider least privileges principal – assign minimal permissions by default and support increasing permissions using step-up authentication and consent when needed.
Set token configuration such as expiration duration, refresh token etc. suitable to the agent’s needs. Shorter-lived sessions are recommended for agents.
Tag the agent’s access-tokens. If supported by the authorization server, add custom claim to the access-token that clearly indicates the token is being issued to an agent. If custom claims are not supported, the agent’s dedicated client-id will serve as the tag.
Onboarding Bring-Your-Own-Agents (BYOA)
These agents are not managed by the organization. Rather, individual users may hire agents to do tasks on their behalf.
API Interacting Agents
If you wish to support API interacting agents not managed by the organization it is recommended to apply dynamic client registration (DCR) – the agents will need to register themselves, and each will get a dedicated client-id and authorization configuration according to the organization’s policies (scopes, expiration etc. as described above for managed agents).
Computer Using Agents
For CUAs hired by individual users, there is no real onboarding flow (since they use standard user-agents like browsers). Instead, these agents will be identified similar to how you identify human-controlled user agents - e.g. device fingerprinting.
Authentication & Access Delegation
As mentioned earlier, agents acting on behalf of users should be granted access on behalf of the user and never impersonate the user.
API Interacting Agents
Use standard OAuth access delegation flows as configured for the agent’s specific client (identified by the client-id used by the agent, as described in the onboarding section above).
Computer Using Agents
A CUA attempting to authenticate should be routed to a suitable authentication flow, ideally automatically (based on CUA detection), or as an authentication option available in the UI that the agent can select.
The CUA authentication flow will trigger a delegated access flow, like device-flow, similar to the one applied for API interacting agents. This way the human user will authenticate and explicitly delegate access to the agent without exposing their credentials to the agent.
Limiting the Agent’s Permissions
As suggested in the above implementation patterns, an agent will be using an access-token that clearly indicates it is an agent and may also include a reduced set of scopes (compared to the user’s standard scopes when interacting directly).
An authorization policy, protecting a resource, will be aware of the agentic client and will enforce stricter permissions where needed.
For example, let’s assume a business policy that requires agents to have read-only for the “orders” resources. Here’s some examples of how an access-token may reflect that it was issued to an agent:
// standard client application access token for user-X
{
"sub": "user-X",
"client_id": "app-client-123",
"scope": "read:orders write:orders",
"aud": "https://api.example.com",
"exp": 1712399999
}
// API interacting agent access token for user-X
{
"sub": "user-X",
"client_id": "agent-client-456", // different client-id
"scope": "read:orders", // limited scopes for read-only
"aud": "https://api.example.com",
"exp": 1712399999
}
// CUA intercting with the standard client application on behalf of user-X
{
"sub": "user-X",
"client_id": "app-client-123", // the client id is of the standard client-app that the agent is interacting with
"scope": "read:orders", // limited scopes for read-only
"aud": "https://api.example.com",
"exp": 1712399999,
"act" : {"client_id" : "agent-client-789"} // actor claim pointing to the agent
}
Standard client application – an example of access-token used by the standard application (e.g. web application) once the user logged in
The user is the token subject (sub claim)
The client-id belongs to the web application
The scope mentions both read and write access
API interacting agent – an example of access-token an API interacting agent may get following user authentication and access delegation to the agent
The user is the token subject
The client-id belongs to the agent
The scope only mentions read access
CUA – an example of access-token the client application will get when controlled by a Computer Using Agent, following access delegation to it by the user
The user is the token subject (sub claim)
The client-id is belongs to the web application
The scope only mentions read access
act claim representing the actor that is acting on behalf of the user, indicating it is an agent based on the agent’s client-id
Human-in-the-Loop Authorization
In some cases, instead of limiting the permission of an agent, it may be allowed to proceed following an explicit authorization by the user in context (the access-token subject).
An authorization policy in that case may require an out of band, step-up authentication by the user and an explicit consent by the user to approve the agent’s operation on their behalf.
For example, consider the following illustrative policy:
{
"if": {
"access_token.client_id": "agent-client-*",
"requested_resource": "/orders",
"access_token.scope": "!contains:write:orders"
},
"then": {
"action": "deny",
"status": 403,
"error": "insufficient_scope",
"required_scope": "write:orders",
"message": "This operation requires user confirmation via step-up authentication."
}
}
Following that response, the agent will trigger an out of band user-conformation flow which will send an OPT to the user.
Agent Activity Monitoring
Since the agents’ access-tokens are tagged as such, it is possible to rely on the access-token as a standard tagging mechanism to indicate agentic interactions with the IAM system and with protected resources.
For example, looking at the audit log based on the access-token.client-id will expose the interactions done by the relevant agent on behalf of any user.
Based on the audit log, it is possible to monitor the agent’s activity and alert on abnormal / undesired agent behavior that may be a result of hallucination, wrong reasoning process, or even malicious attempts to “jailbreak” the agent.
Start Today
Contact Sales
See how Ping can help you deliver secure employee, partner, and customer experiences in a rapidly evolving digital world.
