AI Agent Standards Are Evolving. Security Can't Wait.

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.

AI agents 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.

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.

Even while the specifications evolve, one thing is clear. Agent access is converging on OAuth. 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, 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.

One of the more promising developments extends a pattern enterprises already trust. Single sign-on (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.

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.

Coding agents show why standards alone are not enough. These agents run on a developer's own device and connect out to MCP servers, 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 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.

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?

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 (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 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.

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, 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.

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. 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.