## Key Takeaways

- **Standards Aren't Ready:** Agent identity standards are still emerging, so secure agents now.
- **OAuth Is the Base:** Most agent access already builds on OAuth extensions.
- **Cross-App Access Is Maturing:** Cross-App Access extends single sign-on trust to agents, but adoption is early.
- **Identity Closes the Gaps:** Governance, delegated authority, and runtime authorization secure what standards cannot.

## AI Agents: Securing a Different Kind of Actor

Everyone is talking about agents for good reason. They can provide immense value in situations ranging from consumer shopping and employee productivity to software development and customer service.

To provide that value, agents need access. They need to read data, call application programming interfaces (APIs), use tools, interact with other agents, and sometimes take action on behalf of a person.

Every one of those actions is an access decision. Before an agent can read data, call an API, use a tool, or act on someone's behalf, a system has to know which identity is making the request and what authority that identity carries. That is why identity is central to the agentic era. It is the control point that decides what an agent can reach, on whose behalf it acts, and what it is allowed to do.

Agents are often described as a fundamentally different kind of actor. That is only partly true. At their core, agents are machine processes. They contain code that executes and interacts with systems, which gives them a great deal in common with other automated tasks and workloads, such as scheduled batch jobs, data pipelines, service accounts, and build and deployment scripts.

Where agents are different is in their decision-making. Many agents evaluate context and choose what to do at runtime rather than following a completely predetermined sequence. Their behavior is therefore not deterministic. They can select different tools, chain together multiple actions, and change direction as they encounter new information. When an agent has broad access, that flexibility can produce unexpected outcomes.

Securing agents begins with the same key questions we ask about the human identity lifecycle, from where they are to who they are to what can they do and can they be trusted to do it.

![Diagram showing Key Questions for securing agents](https://images.pingidentity.com/image/upload/f_auto,q_auto,w_auto,c_scale/ping_dam/content/dam/picr/img/bl/2026/7068/Securing-Agents-Key-Questions.png) 

## Why Agent Access Standards Are Still Emerging

[AI agents](https://www.pingidentity.com/en/solution/agentic-ai-identity.html) create value only when they can act. To act, they need access to data, tools, and systems. That makes identity the control point for the agentic era, and it makes the gaps in today's standards a security problem, not a theoretical one. Enterprises are already embedding agents across customer, workforce, and developer workflows faster than the standards meant to secure them can mature.

The scale is already significant. Machine identities now outnumber human identities by a wide margin in the enterprise, and AI agents are the fastest-growing part of that population. They behave differently from the machine identities that came before them.

Agents are not deterministic scripts. They reason, chain tasks, call other services, and change their plan at runtime based on what they find. A traditional service account follows a fixed path, but an agent decides its own.

Each agent also acts on behalf of someone else, rarely representing only itself. It carries the authority of a user, a team, or the business, which raises a hard question. When an agent acts, whose authority is it using, and who is accountable for the result?

The specifications themselves are also moving targets. Multiple bodies, including the Internet Engineering Task Force (IETF), the OpenID Foundation, and the Model Context Protocol (MCP) community, are defining agent identity in parallel. Their drafts change often, and the pieces do not yet fit together cleanly.

This is not about waiting for perfection. It is about recognizing that agents are already in production. The controls have to travel with them today, not arrive with a finished specification in a few years.

| Dimension | Human user | AI agent |
| --- | --- | --- |
| Speed | Comparatively slower and more deliberate. | Very fast; they can act at machine speed. |
| Scale | Usually limited to a smaller number of concurrent actions. | Many agents can operate across many systems simultaneously. |
| Accountability | Individuals generally have direct organizational and legal consequences for their actions. | No intrinsic legal or organizational accountability; responsibility must be assigned to owners and operators. |
| Acting on behalf of others | Most often act for themselves, although delegation also occurs. | Often act on behalf of a user, business process, or upstream agent. |

## What to Do Until Agent Standards Mature

Eventually, standards for agent single sign-on and delegated access may become pervasive, giving organizations more consistent ways to establish trust and control across agents and service providers. That future is worth designing toward. It is not a plan for the agents already running today.

The practical question is what to do until those standards are broadly adopted and consistently implemented. Approaches that rely solely on emerging standards may arrive too late to enable enterprises with AI safely. The organizations that succeed will secure agents now and let the standards strengthen an approach that already works.

## OAuth as the Foundation for Agent Access

Even while the specifications evolve, one thing is clear. Agent access is converging on [OAuth](https://www.pingidentity.com/en/resources/identity-fundamentals/centralized-identity-management/authentication-authorization-standards/oauth.html). Rather than inventing a new protocol, the industry is extending the authorization framework enterprises already run.

Different agents need different flows. A user-facing agent can use the authorization code flow with Proof Key for Code Exchange (PKCE). A backend agent can authenticate with a Private Key JSON Web Token (JWT) or mutual Transport Layer Security (mTLS) instead of a shared secret.

Workloads can carry an attested identity through the Secure Production Identity Framework for Everyone (SPIFFE) and SPIRE. Delegation across services can travel through OAuth [token exchange](https://www.pingidentity.com/en/resources/identity-fundamentals/authentication/token-based-authentication.html), defined in Request for Comments (RFC) 8693.

The common thread is short-lived, scoped, verifiable credentials in place of static API keys. A leaked long-lived key hands an attacker everything the agent can reach. A short-lived, narrowly scoped token limits the damage and expires on its own.

Adhering to these standards is necessary, but not sufficient. OAuth proves an agent was authorized to act, not which specific agent instance made the call. A stolen bearer token can still be replayed, so binding tokens to a key or an mTLS channel helps close that gap.

Demonstrating Proof of Possession, or DPoP, is one such mechanism. It binds a token to a key the client holds, so a stolen token is useless without that key. Across methods, the principle holds. Prove the caller is the party the token was issued to, not just that a valid token exists.

| Standard name | What the standard does | Built on OAuth? |
| --- | --- | --- |
| OAuth 2.0 Token Exchange | Exchanges one token for another audience or scope. | Yes; OAuth extension. |
| Private Key JWT | Authenticates clients using signed JWT assertions. | Yes; OAuth client-authentication profile. |
| Third-Party Token Exchange | Exchanges an external token for an OAuth access token. | Yes; OAuth extension. |
| Identity Assertion JWT Authorization Grant (ID-JAG) | Carries identity assertions as OAuth authorization grants. | Yes; OAuth grant extension. |
| Client ID Metadata Documents (CIMD) | Publishes client metadata at a URL for discovery. | Yes; OAuth client-registration extension. |
| Transaction Tokens | Carries transaction context across distributed service calls. | Yes; OAuth extension. |
| SPIFFE JWT SVID | Identifies workloads using signed, short-lived JWTs. | No; independent workload-identity credential. |
| mTLS Authentication | Authenticates OAuth clients using mutual-TLS certificates. | Yes; OAuth authentication extension. |
| SPIFFE X.509 SVID | Identifies workloads with short-lived X.509 certificates. | No; independent workload-identity credential. |
| OAuth 2.0 Authorization Server Metadata | Publishes endpoints and supported OAuth capabilities. | Yes; OAuth metadata specification. |
| OAuth 2.0 Dynamic Client Registration Protocol | Registers OAuth clients programmatically at runtime. | Yes; OAuth registration specification. |

## Agent SSO & Cross-App Access

One of the more promising developments extends a pattern enterprises already trust. [Single sign-on](https://www.pingidentity.com/en/resources/identity-fundamentals/authentication/single-sign-on.html) (SSO) lets a user authenticate once and reach many applications. Cross-App Access (XAA), defined by the Identity Assertion JWT Authorization Grant, or ID-JAG, applies that idea to agents.

With ID-JAG, the identity provider both sides already trust for single sign-on issues a short-lived, signed assertion. The agent exchanges that assertion for a scoped access token at the target application. The identity provider stays the source of truth for which app can reach which resource, and it keeps the audit trail.

The contrast with human access is simple. For a person, single sign-on means logging in once, and the browser session carries that trust from one application to the next. An agent has no browser and no one to click approve, so the identity provider issues a signed assertion that names both the user and the acting agent, along with the specific authority delegated to that agent.

This matters for agents because the old model does not fit them. Traditional OAuth consent assumes a browser and a human to click approve, and an autonomous agent has neither. ID-JAG lets an agent obtain cross-domain access without a per-app consent screen, using the trust that already exists.

Without a shared pattern, every agent needs a custom integration with every application it touches. That approach does not scale as agent populations grow into the thousands. Cross-App Access replaces those point-to-point connections with one trusted broker.

ID-JAG is an active IETF OAuth working group draft with intended Standards Track status, and the Model Context Protocol has adopted it as the basis for enterprise-managed authorization. Still, the specification is young and revised often, and broad adoption across vendors and applications is still developing. It is a direction to design toward, not a finished foundation to rely on alone.

![Diagram showing a CrossApp Access flow](https://images.pingidentity.com/image/upload/f_auto,q_auto,w_auto,c_scale/ping_dam/content/dam/picr/img/bl/2026/7068/Cross-App-Access-flow.png) 

A Cross-App Access flow, where an enterprise identity provider issues an Identity Assertion JWT Authorization Grant (ID-JAG) that a personal agent exchanges for a scoped access token to reach a protected service across the organization's trust boundary.

## Securing Coding Agents Today

Coding agents show why standards alone are not enough. These agents run on a developer's own device and connect out to [MCP servers](https://www.pingidentity.com/en/product/agent-gateway.html), code repositories, and cloud tools. They are powerful, and they are hard to attribute.

The core problem is shared credentials. When an agent uses the developer's own tokens and keys, the systems it touches cannot tell the agent's actions from the person's. If something goes wrong, the audit trail points to the human, not the agent that acted.

Picture an agent that opens a pull request, calls a cloud API, and reads a secret from a vault. If it uses the developer's credentials for all three, every log shows the person, not the agent. When dozens of agents share one developer's access, the audit trail becomes noise.

A safer pattern gives the agent its own scoped, short-lived access instead of the developer's standing credentials. Capabilities such as [Agent Privilege](https://www.pingidentity.com/en/product/agent-privilege.html) let administrators discover which agents operate on employee workstations and constrain them by tool, MCP server, repository, operation, developer, or session. Grant access just in time for the task, inject credentials at runtime rather than storing them, and monitor what the agent does.

![Diagram showing how an AI gateway secures coding agents](https://images.pingidentity.com/image/upload/f_auto,q_auto,w_auto,c_scale/ping_dam/content/dam/picr/img/bl/2026/7068/AI-Gateway-Diagram.png) 

An AI gateway secures coding agents by routing developer and agent access through agent detection, policy enforcement, runtime credential injection, and a kill switch before the agent can reach protected systems such as issue trackers, code repositories, and databases.

Record both the human and the agent on every action, so attribution stays clear. This is dual attribution in practice. It answers the two questions that matter after any incident. Which agent acted, and on whose authority?

## AI Agent Governance & Lifecycle Control

Standards govern how an agent gets access. They do not decide which agents should exist, who owns them, or whether their access is still appropriate. That is governance, and it is where most enterprises are least prepared.

The visibility gap is stark. Many [identity and access management](https://www.pingidentity.com/en/resources/identity-fundamentals/centralized-identity-management/authentication-authorization-standards.html) (IAM) teams can account for only a fraction of the machine identities already operating in their environment. You cannot govern, review, or revoke what you cannot see.

Effective [agent governance](https://www.pingidentity.com/en/product/agent-governance.html) covers the full lifecycle. It starts with discovery, a live inventory, an assigned owner, and regular access review for every agent. It also manages each agent from creation to retirement, keeps an audit record, and supports fast remediation when risk changes.

Offboarding is where the risk concentrates. When a project ends or an owner leaves, the agents they created often keep their access. An orphaned agent with live credentials and no owner is exactly what an attacker looks for.

Agent access is also spread across platforms, tools, and credentials. An agent may hold an OAuth token, a workload identity, and a set of tool permissions at once. Governance has to see across all of them, not just one system, or the picture stays incomplete.

## Streamlining Agent Standards With Identity Services

Put these pieces together and a pattern appears. Standards handle the protocol, not the controls that surround it. Core identity services are what implement the standards and fill the gaps they leave.

That means running the OAuth flows and token exchange agents need. It also means enforcing [least privilege](https://www.pingidentity.com/en/resources/blog/post/what-is-principle-of-least-privilege-polp.html), evaluating authorization at the moment of action, and recording every decision. It means treating the agent as a first-class identity with an owner, a lifecycle, and a policy, not as an anonymous process.

The goal is simple to state. Every agent action should be attributable and governable. Who is this agent, whose authority is it using, and can you prove what it did?

Standards move the industry toward interoperable answers. Identity infrastructure is what makes those answers real inside a specific enterprise, today, across the systems it already runs.

## Enabling AI Agents Without Waiting for Standards

The agents are already here, and they are already acting. Waiting for the specifications to finish is not a strategy. It is a decision to stay exposed while the standards catch up.

The organizations that move now will design around the standards that are stabilizing. They will wrap those standards in the governance, delegation, and runtime controls that agents demand. They will treat every agent as a known actor, with an owner, a boundary, and a record.

The security boundary is shifting from the login event to [the moment of action](https://www.pingidentity.com/en/resources/identity-fundamentals/agentic-ai/runtime-identity.html). That shift rewards enterprises that can decide trust continuously, in context, for people and agents alike. Build that capability now, and evolving standards become an advantage to adopt rather than a gap to fear.

Manage Your AI Agents with Confidence

Treat agents as first-class identities, enforce authorization  
 at the moment of action, and extend governance, privilege,   
 and enable auditability across the full agent lifecycle.

[Explore the Ultimate Guide to Identity for AI](https://www.pingidentity.com/en-us/docs/assets/4260-ultimate-guide-ai-identity) 

Frequently Asked Questions

### What are AI agent standards?

These standards are the emerging specifications that define how AI agents authenticate, obtain access, and act on behalf of users. Most extend OAuth 2.0 rather than replace it. Key examples include OAuth token exchange, the Identity Assertion JWT Authorization Grant, and workload identity frameworks like SPIFFE.

### Are these standards ready for production use?

These standards are not yet fully ready for production use. Many are still IETF drafts that change from version to version, and vendor adoption is uneven. Enterprises should not wait, because proven OAuth patterns, delegated authority, and short-lived scoped tokens can secure agents in production today.

### What is OAuth's role in securing AI agents?

OAuth's role is to serve as the foundation for agent access. It provides scoped, expiring tokens, delegation through token exchange, and a standard way to revoke access. OAuth proves an agent was authorized, but it does not identify which agent instance acted, so it pairs with workload identity and token binding.

### What is ID-JAG and Cross-App Access?

Cross-App Access is a pattern that extends single sign-on trust to agent API access. It is defined by the Identity Assertion JWT Authorization Grant, or ID-JAG, an OAuth extension being standardized at the IETF. The identity provider issues a short-lived signed assertion that an agent exchanges for a scoped access token.

### How do I secure coding agents today?

You secure coding agents by giving each one its own scoped, short-lived access instead of the developer's standing credentials. Grant access just in time, inject credentials at runtime, and monitor activity. Record both the human and the agent on every action so you can tell agent activity from developer activity.