Should AI Agents Have Their Own Identity? Okta Thinks So.

Most AI agents inside an enterprise today don't have an identity of their own. They borrow one. An agent runs on a static API key someone pasted into a config file, on a shared service account, or on an OAuth grant an employee approved once and then forgot about. When that agent calls an API, the downstream system sees the key or the service account, not the agent.

Okta's 2026 release notes read like a sustained argument against that arrangement. Between August and November 2026, Okta shipped a long run of features that treat an AI agent as a first-class identity: its own directory record, its own credentials, its own policy, and its own delegation trail. Okta states the problem directly in its Agent SSO announcement: agents today operate as "anonymous traffic with no owner, no policy, and no audit trail."

An AI agent identity is a dedicated identity record for a single agent, with its own credentials, access policy, and audit trail, separate from any human user or shared service account.

Okta's answer to the title question is yes, and the release notes make a strong case for it. What identity leaves unanswered is the part security teams still have to solve.

Why borrowed identity is a problem

When an agent borrows identity, three things break at the same time.

The first is ownership. A static API key doesn't say which agent is using it, who built that agent, or whether it was approved. The same announcement splits agent sprawl into three groups: agents built in-house, agents embedded in software the company bought, and agents employees deploy without central approval. A shared key looks the same in all three cases.

The second is policy. Security teams have spent years building controls for human users: MFA, conditional access, session lifetimes, access reviews. According to Okta's AI Agents at Work 2026 report, cited in the Agent SSO announcement, only 34% of organizations apply the same security controls to AI agents as they do to human workers. An agent on a shared service account sits outside most of that.

The third is attribution. If five agents and a batch job all use the same service account, the logs on the receiving API show one caller. When something goes wrong, the investigation starts with a question nobody can answer from the data: which one of them did this?

What Okta shipped for AI agent identity in 2026

Read in order, Okta's Identity Engine release notes cover the full lifecycle of an agent identity, from registration to delegation.

One record per agent. In August 2026, Okta made unified identity for AI agents generally available. Each agent gets one authoritative record per org, regardless of how it was registered, with fields for the agent's external ID and the platform it runs on. September added an extensible agent profile schema with custom attributes, in beta.

Agents that identify themselves. Client ID Metadata Documents (CIMD) let an agent identify itself with a URL that points to its metadata, instead of a static client ID. CIMD for AI agents has been in beta since September. Okta also added beta API support for dynamic client registration of MCP servers and, in early access, mutual TLS client authentication for OAuth clients.

Access without consent prompts. Cross App Access (XAA) lets an administrator connect an agent to an application centrally, so the agent gets a short-lived token through the identity provider instead of asking the user to approve a consent screen at runtime, the way a typical OAuth 2.0 flow would. The underlying mechanism is the ID-JAG (Identity Assertion JWT Authorization Grant), an OAuth extension still in draft at the IETF. Okta began rolling XAA out to all customers in August, and it reached general availability in production with the September 2026.09.2 release. In October, Okta extended XAA to MCP servers and to tokens issued by external identity providers.

A delegation chain you can read. Okta added an actor claim to OAuth 2.0 On-Behalf-Of Token Exchange, generally available in production as of October. When one service exchanges a token to act on behalf of another, the token now records who requested it. Chained exchanges nest, up to five service apps deep. A downstream API can see not just "this user" but "this agent, acting through this service, on behalf of this user."

MCP servers as accountable clients. Also in October, MCP servers registered in Okta can act as OAuth clients when they call downstream resources. Each downstream connection has its own scopes and can be revoked individually, and the downstream system logs the actual user instead of a shared service account.

A checkpoint on every tool call. The Agent Gateway APIs put an identity-aware proxy in front of multiple MCP servers. The gateway aggregates their tools behind one endpoint and enforces identity and policy on each call. The Agent Gateway APIs have been in beta since September.

Taken together, these features answer each of the ownership, policy, and attribution problems above. Many of them are still in beta or early access. Most organizations can't deploy the full set in production yet.

What agent identity answers, and what it doesn't

Identity answers one question well: is this caller allowed to make this request? That is the authorization question, and it is settled before the API call runs. With Okta's 2026 features in place, the answer comes with a named agent, a scoped and short-lived token, and a readable delegation chain.

It doesn't answer what happened after the request was allowed. A valid token for a CRM API says the agent may read customer records. It doesn't say whether the agent read ten records or ten thousand, whether the response contained card numbers or health data, or whether the request body carried a prompt injection payload from an upstream document. Authorization happens before the call. Everything an incident investigation needs happens during and after it.

There's also a coverage limit. Agent SSO, Okta's packaging of Cross App Access inside its core SSO product, applies only to agents that support Cross App Access. Agents that don't, including many of the ones employees deploy without approval, need a separate Okta subscription to discover and govern. Some will never be registered in any identity provider at all. Those agents still call APIs. The only place they reliably show up is in the API traffic itself.

Why agent identity makes API visibility more useful

The two layers aren't competing. Identity gives runtime API data something it has always lacked for agents: a named caller.

Before agents had their own identities, API logs could show only that a service account made, say, 40,000 calls overnight. With an actor claim and a per-agent identity, the same logs can show which agent made them, on whose behalf, and through which MCP server. That's the difference between an anomaly and a lead.

The data still has to be captured, though. An identity provider sees token requests. It doesn't see the API's response. To connect "Agent X was allowed to call this endpoint" with "Agent X pulled 12,000 customer records including email addresses," something has to record the actual request and response at the API layer, every time, not on a sample. Treblle captures over 50 data points on every API request in real time, including the full request and response payloads. Custom metadata attached through Treblle's SDK can carry the agent's identity on the same record.

What security and architecture teams can do now

For security and architecture teams evaluating agent identity, a few concrete steps follow from Okta's direction:

• Inventory which agents currently run on static API keys or shared service accounts, and treat each one as an identity migration, not a configuration detail.
• Prefer agents and MCP servers that support Cross App Access, since those can carry a named identity and a delegation chain into every downstream API call.
• Require the APIs agents call to record the agent identity and actor claim from each token alongside the full request and response, so an investigation can move from "who was allowed" to "what was done" without stitching together separate systems.
• Use API traffic to track agents that sit outside the identity provider, since that's the only layer where they reliably show up.

Okta is right that an AI agent should have its own identity. Identity tells an organization who the agent is and what it may do. The API layer is where an organization finds out what the agent actually did.

Treblle's ebook Preparing your APIs for AI Agents covers the API side of this shift in more depth.