An Agent Is Not Its OAuth Client

An enterprise runs thirty agents on a vendor’s agent platform. They reach the company’s analytics service through the platform’s integration, one OAuth client registered once. One night the service’s audit log shows a bulk export of customer reports, made for Alice, a finance analyst, by that client. Nothing in the requests identifies an agent, so the security team cannot tell which of the thirty ran the export, and disabling the client would stop the other twenty-nine as well.

The team’s fix is a client per agent. It holds until an agent moves. The platform migrates the agent to a new runtime with a new client, and unless someone maps the new registration to the old one, the restriction the analytics service keyed to the old client_id does not follow the agent. The agents also reach their tools through an MCP gateway that calls the analytics service as itself, so behind the gateway all thirty look the same again.

An OAuth client tells an authorization server which software is requesting access. A workload credential identifies an execution as its issuing authority sees it. Neither necessarily identifies the logical agent the enterprise means to govern. The identifiers can coincide, and their meanings still differ: an agent can run behind a shared client, move between platforms, rotate credentials, or reach resources through a gateway while remaining the same governed agent, and one runtime can run several agents that are governed separately.

An enterprise can already map several workloads to one agent inside its own IAM system. What is missing is a common contract for how an OAuth client presents evidence of which agent it represents, how the identity provider keeps binding an identity apart from permission to use it, and how independent resource domains recognize and authorize the resulting principal. Agent Principal Profiles propose that contract. The enterprise identity provider (IdP) resolves trusted execution evidence to a stable Agent Principal, authorizes each client’s use of that principal as a separate decision, and conveys the principal in OAuth grants. Each resource domain correlates it with its own records and keeps its own authorization decisions, so identity is federated and authorization stays local. The result is continuity of governance across execution changes, not proof that every deployment of an agent is equivalent.

I write these drafts. All seven are individual drafts under development, published as editor’s copies; none has been submitted to the IETF, and the reference implementation has not been tested against another implementation.

Three Identities, One Governed Principal

An Agent Principal is a logical agent in the IdP’s namespace: the unit the enterprise authorizes, delegates to, attributes actions to, and disables as one. Replicas, restarts, sessions, and rotated credentials can all run as the same principal. An execution needs a principal of its own when it needs separate authorization, delegation, attribution, correlation, or disablement, even when it shares a runtime, client, or credential with another agent. The principal’s identifier is unique and never reassigned within the IdP’s issuer, and moving the agent to a different governing authority creates a new one.

An execution becomes that agent only through an Identity Binding, an approved association from one exact client or workload identity to one principal. Similar names, a shared signing key, or a process or replica identifier never establish it, and a mapping that does not select exactly one agent is rejected. Binding is a privileged decision. The core calls identity continuity “an explicit decision by the governing authority to preserve the same principal,” and a new binding lets a new execution exercise the agent’s existing authorizations. An IdP administrator makes that decision, or a platform’s connector holding a separate permission for it.

The guarantee has a boundary. The IdP validates the platform’s evidence under trust configured in advance, and the enterprise controls the mapping from that evidence to agents. A platform that can issue valid credentials for workload-7, whether misconfigured or compromised, can make the IdP recognize its caller as agent-42, and neither the binding nor the Client Association shows what code is running. Three properties are easy to conflate:

Nor do the profiles isolate agents that share a runtime. A grant bound to a shared client’s key proves possession by the client, not by any one agent behind it.

Why Now

In April I argued that enterprise SaaS needs OAuth federation: issuer-signed assertion in, local access token out, with the enterprise governing the grant and each SaaS keeping its own token. That post had two lanes, generic assertion grants for workloads and services and Cross App Access for user delegation, and it warned that federation “does not rescue weak issuer governance.” This post is its follow-up. It defines what the issuer governs: which principal an assertion names, which clients may use it, and how each resource domain recognizes it.

The user lane has since shipped. The Identity Assertion JWT Authorization Grant (ID-JAG), an OAuth working group draft at -06, carries Okta’s Cross App Access, and MCP’s Enterprise-Managed Authorization extension, stable since July 28, profiles it for MCP servers (what actually shipped). ID-JAG lets a request carry an actor token and a grant carry an optional act claim, but it defines no normative processing for the actor token, leaving its validation, its authorization, and any resulting act to future profiles. Its security considerations add that “the authenticated client identity is also not a substitute for actor identity.” The first resource domains to accept these grants are choosing now how to key agent policy, and if they key it to client_id, or to whatever each IdP chooses to put in act, a portable agent identity will later have to displace that convention.

Platforms are multiplying an agent’s identities, from cloud role credentials and SPIFFE IDs to the agent identity services of AWS, Google, and Microsoft. NIST’s design tenets for agent identity, published October 27, open with Distinct Agent Identification, ideally tied “to a specific workload, environment, and approved configuration.” The profiles bind each exact workload identity and leave the approved configuration to deployment assurance.

How the Federation Boundary Works

The core draft, the OAuth 2.0 Profile for Agent Principal Federation, is an OAuth deployment profile with no new credential format and no new endpoint. The IdP holds four kinds of relationship, and each answers one question:

The split between the first two is the profile’s central decision. Suppose the platform’s JWT for workload-7 resolves to agent-42. That JWT is bearer evidence unless it is key-bound, so any OAuth client that obtains it could present it, and if resolving the identity also authorized its use, holding the evidence would be enough to act as the agent. The Client Association is a second gate. It names which authenticated client may use the agent, through which binding, with which credential class, and for which acting relationship, so permission for delegated access does not imply self-acting access. An act claim in a token names an agent; these two decisions are what make the name governed. They are separate checks, not necessarily separate records: for a dedicated client, the SCIM management companion administers both in one binding.

In the opening’s terms, the platform keeps its one shared client, registered at the IdP as platform-sso and at the analytics service’s authorization server (RAS) as platform-api; the IdP maps one to the other from configuration, never from the request. The platform issues each agent’s workload a JWT with its own subject, and bindings map workload-7 to agent-42 and workload-8 to agent-43. Alice’s sign-in gives the client her ID Token, but it does not authorize either agent to act for her. Her Delegation Authorization for each agent does.

The grant for agent-42:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "iss": "https://idp.example/",
  "sub": "alice-ras",
  "aud": "https://ras.example/",
  "iat": 1789646463,
  "exp": 1789646763,
  "jti": "grant-7",
  "client_id": "platform-api",
  "resource": "https://api.example/tenants/acme-data/",
  "scope": "reports.read",
  "act": {"iss":"https://idp.example/", "sub":"agent-42"},
  "cnf": {"jkt":"JKT_K"}
}

The grant for agent-43 differs only in act and jti. Both carry the platform’s RAS registration as client_id, while act names the agent by the IdP’s issuer and its identifier. The RAS correlates that exact pair with its local principal and never keys agent authorization on a bare sub, and the RAS and the API both apply the actor gate, the check that this agent may act for this user here. The grant sets a ceiling, and the RAS decides again within it.

The delegated path is the more fully specified composition: the profile fills the actor extension point that ID-JAG leaves open. When an agent acts for itself, the IdP issues a Workload Authorization Grant with the agent as the subject instead. That path is a stricter governance profile of WAG that changes its operating model, and its interoperability and lifecycle are still under discussion (appendix).

The attribution comes from the evidence. If thirty agents ran under one AWS role, the role’s token would represent that shared calling identity, and no binding could tell them apart; the core then requires distinct credential identities or trusted selectors, and a caller-supplied agent name does not qualify. The key in cnf is the client’s, so the platform client is trusted to keep its agents’ tokens apart, and the core forbids reusing one agent’s token for another.

A dedicated client per agent is the other way in, and it is the mandatory interoperability path. Existing Enterprise-Managed Authorization deployments remain compatible, governed attribution requires adopting the profile, and a bound variant adds DPoP at issuance and redemption. For the opening’s gateway, the continuation companion has the IdP issue an onward grant naming the same agent and user, with the gateway as its client and never as an added actor; a gateway the IdP has not associated with the agent gets nothing and does not fall back to calling as itself. Five other companions add evidence inputs, SCIM registration of agents and clients, lifecycle provisioning, and human oversight (list).

Why Existing Mechanisms Are Not Enough Alone

The strongest alternative is a client per agent with a stable identifier. A Client ID Metadata Document (CIMD) lets one URL serve as a client’s identifier at every authorization server without prior registration, and workload federation can authenticate that client from its runtime. When one stable client corresponds to one independently governed agent, that client identity may be enough, and the profiles accept it: a dedicated client is their mandatory path, and an Agent Principal may reuse the client’s identifier. The separate principal matters when the identities diverge: when the agent works through several clients, shares a client with other agents, or continues through a gateway whose client identity is not its own. For those cases the core states that a client identifier, including a CIMD URL, “identifies the client, not the agent.”

Each existing mechanism supplies a part:

Microsoft’s agent identity platform, for one, onboards agents from AWS Bedrock and n8n through its SDK sidecar or workload identity federation, so recognizing agents from several platforms in one product is not new. The remaining gap the profiles target is the contract described at the top, implemented the same way by independent IdPs, platforms, and resource domains.

Two other drafts of mine, both submitted individual drafts at -01, answer adjacent questions. The OAuth Actor Profile for Delegation defines how a token names the actor acting for a subject, and OAuth 2.0 Client Instance Identifiers identifies which installation of a client is running. The Agent Principal answers a third question, which persistent agent the enterprise governs. In the core, the actor in a grant is the resolved Agent Principal rather than an identity copied from the presented credential, and an instance identifier selects an agent only through installation-level resolution that an input profile defines.

The core places itself inside the agent identity management framework that the WIMSE working group’s AIMS draft describes, as one concrete profile of it rather than a competing architecture. That is compatibility with the architecture, not conformance to every AIMS requirement. AIMS requires agent credentials to provide “a cryptographic binding to the agent identifier,” and where the profiles accept bearer evidence or rely on a shared client’s key, the IdP relies on the platform’s attribution rather than on each agent proving possession of a key of its own. In the terms of The Runtime Mints the Identity, it proposes the principal-binding part of the binding layer on the ID-JAG rail (scored against that essay’s tests).

Not Only Agents

Nothing in the contract is specific to AI. The core defines an Agent Principal as a non-human principal “representing an independently governed workload or agent,” so a build pipeline, a backend service, and an AI agent are governed the same way, and thirty pipelines behind one integration client fail the way the opening’s thirty agents do. Read against the April post’s lanes, the profiles cover enterprise API access generally:

The workload lane can keep using generic assertion grants today, as the April post recommended. The governed WAG is where that lane goes once it settles: a subject resolved from evidence the enterprise binds, and a separate permission for each client to use it.

What It Guarantees and What It Does Not

With distinct evidence per agent, a resource domain can attribute each action to an agent, and a restriction keyed to (https://idp.example/, agent-42) survives an authorized rebinding to another platform or client. What survives a migration is the principal, the IdP’s authorizations for it until they change, and each resource domain’s correlation for as long as the domain keeps it. The domain’s authorization was always its own: the grant does not oblige the RAS to issue, the actor gate applies where access happens, and no upstream activation clears a local suspension. Withdrawing Alice’s delegation leaves the agent’s own access unchanged, and the reverse holds as well.

Continuity also limits what a resource can tell apart. It keeps applying agent-42’s policy after a migration, but the stable principal does not say whether the new deployment deserves the trust the old one had. Policy that depends on the deployment needs evidence the profiles do not carry. A stable principal also enables correlation: a resource domain can link one agent’s activity across resources and users, which serves audit and also permits tracking, and the core defines no pairwise actor translation.

Withdrawal reaches new grants first. Disabling an agent at the IdP stops new grants once the IdP applies the change, within its configured freshness limit, while tokens already issued keep working until each resource domain applies the change, through the lifecycle companion’s provisioning and events, or until they expire. Without a bound on propagation and enforcement, the drafts claim no finite end-to-end denial time, and the lifecycle companion says a deployment should document its expected and maximum disablement delay.

Some work becomes reusable and some stays per resource. A RAS and API implement correlation, the actor gate, and tenant checks once for agents from any platform the IdP governs, and a platform presents evidence it already issues to one IdP instead of teaching each resource its conventions. Each RAS still admits each client, by prior registration or, for a CIMD client, by policy for its URL, and the IdP must know which admitted client a grant names. Each agent needs a correlation record before its first redemption unless the RAS enables just-in-time correlation. An enterprise on one runtime whose resources accept that vendor’s native principal may get attribution and revocation from native IAM at lower cost.

The scope ends at the allow or deny decision for an action. Multi-agent delegation chains, identity continuity across chains of IdPs, authorization of individual client instances, enrollment and key replacement, and behavioral monitoring are outside it. So is approved work: an agent can be correctly identified and authorized and still be doing work nobody approved, which is the question Mission-Bound Authorization takes up.

Beyond the status noted at the top, the reference implementation is a test-only prototype, and the core depends normatively on the input profiles and on Client Instance Identifiers, which no working group has adopted.

The Thirty Agents Again

With the profiles in place, the export from the opening is attributed: the access token names Alice as the subject and agent-42 as the actor. The analytics service then restricts the agent, not the client. Alice may still export reports herself, but the service’s policy for (https://idp.example/, agent-42) refuses bulk exports, so the agent’s next export request fails, while agent-43, using the same client for the same user, can still run the exports its own policy allows. When the platform moves agent-42 to a new runtime, an authorized administrator or connector binds the new workload identity to it and disables the old binding, and the refusal still applies because it never named the runtime or the client.

To stop new grants for agent-42 across its bindings and clients, the security team disables it at the IdP: its continuation chains end, and the gateway obtains no onward grant for it. To stop it only at the analytics service, the service suspends it locally. Either way the other twenty-nine keep their bindings, associations, and grants, and tokens agent-42 already holds run until each resource domain applies the change or they expire.

Those are four observable outcomes: an attributed and refused export, a restriction that survives an authorized migration, a stop that reaches the gateway, and the other agents unaffected. Independent implementations should reproduce them. The conformance suite covers the delegated path, including a shared client presenting platform JWTs, and self-acting issuance and redemption, and can test a RAS and API without a governed IdP by signing grants itself; continuation and lifecycle are not in it yet. Identity teams can read the architecture overview and the playbook against how they run agents today.

Appendix: Reference Material

The Self-Acting Path

In the Workload Authorization Grant (WAG), an early individual draft at -02, a platform’s workload identity provider signs a JWT grant naming one workload, and a resource’s authorization server redeems it without “a per-workload provisioning step” and without rejecting a workload “because it has not seen it before.” The profiles have the enterprise IdP issue the grant after resolving the agent, and they trade away part of WAG’s design to do it. They require client authentication at issuance and redemption, where WAG requires none and gives client_id no meaning, and a registration for the redeeming client, which WAG never requires per agent, though one registration can serve many agents. Where WAG accepts a workload on its first assertion, the profiles accept a previously unseen agent only where resource policy turns on just-in-time correlation, which is off by default and creates a record that authorizes nothing. The core lists one open item with WAG itself, DPoP binding, and two within the family, self-acting Client Associations and a lifecycle composition for WAG; until those two close, it says, a self-acting claim has no management path for client use or lifecycle composition to be tested against.

Where the Profiles Sit

One Agent, Three Bindings

The core’s example gives agent-42 a binding for each platform it runs on:

Grants through B1 and B2 both name agent-42. Disabling B3 stops issuance through B3 alone.

The Companions

The Five Binding-Layer Tests