AI Agent Delegation Is Getting Standardized. Enforcement Is the Part That Isn't.

The identity industry is quietly standardizing how AI agents carry authority delegated from a human. It has not made headlines, but if you are putting agents into production, this is the plumbing your identity provider will speak within a year or two. It is worth understanding, because it solves a real problem and leaves an equally real one on your side of the line.

What the standards are actually doing

The direction is consistent across several efforts. Agents are becoming first-class identities that carry a scoped, delegated token that says, in effect, "this agent is acting for this human, for this task."

The work builds on a stable OAuth foundation, RFC 8693 token exchange, and extends it for agents in a few ways: a standard way to express the full human-to-agent-to-sub-agent chain, a way to cryptographically limit a sub-agent so it can never hold more authority than the agent that created it, a way to provision and de-provision agents as identities with a human owner attached, and a way to signal in real time when an agent's access should be cut off.

Taken together, this is genuine progress. It gives agents a proper identity and a precise, revocable statement of what they are allowed to do. Every enterprise running agents should welcome it and plan to adopt it.

One caveat worth keeping straight is how finished any of this is, because it changes what you can rely on today. RFC 8693 has been an approved Standards Track RFC since 2020, and CAEP reached a final 1.0 specification in 2025, so those two are stable ground. The agent-specific pieces, the attenuated tokens, the SCIM agent resource, and the actor profile, are still early Internet-Drafts at their first revision. They point in a clear direction, and it is the right direction, but they will change, and they are not yet something you can build a control or a compliance program around.

The one line worth knowing

There is a single sentence in the foundational standard that tells you where all of this stops, and it matters that this is the approved, Standards Track piece rather than an early draft that might still move. RFC 8693 lets a token carry the whole chain of delegation, human to agent to sub-agent. Then, in Section 4.1, it says plainly:

Prior actors identified by any nested act claims are informational only and are not to be considered in access control decisions.

Read that twice. The standard captures who delegated authority to whom. It explicitly does not use that chain to decide whether an action should be allowed. That is not an oversight, and it is not a gap that a later draft will quietly close. It is the boundary of what a token is for. A token states authority. Deciding whether a given action actually stays within that authority, at the moment an agent acts, is a different job.

A token is a grant, not a guarantee

Every one of these standards describes the authority an agent may carry. Not one of them, on its own, sits between an agent's next action and your systems and decides whether that specific action is allowed, and then proves it happened.

For an architect, the practical consequence is that handing an agent a token, even a cryptographically limited one, still leaves three things undone:

• It does not check every action, across a chain of sub-agents moving at machine speed, against the authority that was granted.
• It does not make that decision before the action reaches a system, based on what the agent is actually trying to do at that moment.
• It does not leave a tamper-evident record of what was decided and why, which is exactly what an auditor or a regulator will ask for.

Those are runtime responsibilities, and the standards deliberately leave them open.

What it means for your architecture

The clean way to think about this is as two layers. Your identity provider issues the agent's identity and its scoped, delegated token. An Agent Runtime Governance layer enforces that token on every action and proves the outcome.

The standards are maturing the first layer quickly, and that is good. The second layer is the one you have to design for on purpose, and it is where the risk actually concentrates, because it is the layer that stands between an autonomous agent and the systems it can affect. Treating token issuance as if it were enforcement is the mistake to avoid. A grant is not a guarantee.

Where Watchlight fits

This is the layer we built Watchlight AI Beacon to be. It sits downstream of your identity provider and is built around the same delegation model these standards describe, so whichever ones your provider adopts to issue and revoke agent tokens, Watchlight consumes them and does the part they leave open. It enforces that an agent, and any sub-agent it spawns, stays within the authority it was granted, decides before an action executes rather than reporting on it after, and records the result as tamper-evident proof. It is identity-provider-neutral by design, so it works the same underneath Okta, Ping, or any OIDC provider.

The standards are defining the token, and enterprises should track that closely, because a well-defined, revocable agent identity is real progress. Just be clear about what a token is. It is a statement of what an agent is allowed to do. Making that statement true when the agent acts, on every action, across the whole chain, with proof, is Agent Runtime Governance. That is the part the standards leave to you.