Identity for AI

Securing Digital Assistants

Secure your organization’s AI-driven digital assistants by treating them as first-class identities, distinct from the humans they act on behalf of, and enforcing least-privilege access at runtime.

AI agents are serving both consumers and employees (for example, as chatbots on retail websites helping users navigate products, and as workforce assistants managing employee calendars and drafting emails). Securing these assistants means verifying not just what the agent is doing, but whose identity and permissions it’s exercising at any given moment. Runtime identity distinguishes the agent from the human while ensuring the agent has explicit authority to act on the user’s behalf.

Key Concepts

Explicit agent identity

Register every digital assistant as a unique identity with its own credentials and lifecycle. This enables centralized management of your agents, their owners, and their resource permissions from a single console across your customer and workforce use cases.

Delegation, not impersonation

Using OAuth 2.0 token exchange, agents swap a user’s token for a delegation token that has an act (actor) claim, explicitly identifying both the user and the agent. The actor claim provides a clear audit trail of which agent took what action, enabling enforcement decisions at runtime based on both the user and the agent. The agent never sees the user’s credentials.

Least-privilege permissions

The delegation token is short-lived and might require additional token exchanges as the agent performs new actions or accesses different resources. Audience restriction ensures the token is only valid at a specific resource server, preventing acceptance of unauthorized tokens.

Runtime Enforcement

The agent gateway acts as a security proxy, validating tokens and enforcing fine-grained policies before an agent can reach backend resources such as APIs or Model Context Protocol (MCP) servers. The gateway provides a consistent security layer for AI developers building on MCP or traditional REST architectures.

How this works

As an example scenario, consider a chatbot embedded in a banking app. Customers use the chatbot to retrieve account balances and make transactions. Acting on behalf of the customer, the chatbot accesses backend account resources.

Diagram showing the request flow from users to an AI agent requesting access to a resources secured by the agent gateway.

To secure these interactions, an authorization server issues and exchanges tokens. An agent gateway validates the tokens, acting as a security proxy in front of account resources.

Example process flow:

UML diagram of token exchange flow for an AI agent secured with an authorization server and agent gateway.

  1. User authentication: The customer signs on to the banking app and receives an initial access token (the subject token).

  2. Request for action: The customer asks the chatbot for their account balance. The banking app passes the customer’s subject token to the chatbot.

  3. Token exchange: The chatbot sends the customer’s token and its own credentials (the actor token) to the authorization server.

  4. Issuance of delegation token: The authorization server issues a new, short-lived token. This token includes the customer as the sub (subject) and the chatbot in the act (actor) claim.

  5. Gateway validation: The chatbot sends the request to the backend. The agent gateway intercepts the call, validates the act claim, the user (sub), and target resource (aud), and ensures the chatbot has the specific scope (account:read_balance) required for the task.

  6. Secure execution: The backend account API processes the request, knowing exactly which agent performed the action for which user.

A delegation token issued by the authorization server carries a precise record of the delegation:

{
  "iss": "https://as.example.com",
  "aud": "https://acount.api.example.com",
  "sub": "customer@example.com",
  "act": {
    "sub": "https://bank-agent.example.com"
  },
  "scope": "account:read_balance",
  "iat": 1742200000,
  "exp": 1742200300
}

The token contains the following claims:

Claim Description

sub

The human user who authorized the action.

act.sub

The AI agent performing the action.

scope

Constrained permissions granted to the agent for this action.

aud

Restricts the token to a specific downstream resource.

The delegation token provides downstream services with everything they need for authorization decisions: who is the human, who is the agent, what are they allowed to do, and how to trace this specific action.

Ping Identity authorization servers that support this scenario include PingOne, PingOne Advanced Identity Cloud, and Ping Identity software, such as PingFederate and PingAM. PingGateway serves as the agent gateway.

What’s next

Get started with your preferred platform: