On-behalf-of delegation explained

What problem does delegation solve?

Many agents work for one person at a time. A mail assistant drafts replies for a manager. A coding agent opens pull requests for an engineer. A travel agent books trips for an employee.

Those agents need some of the person's access. They should never have more. And downstream systems should be able to tell the difference between the person acting and the agent acting for them.

Without delegation, teams pick one of two bad options. The agent uses the person's own token and looks like the person. Or the agent uses a broad service account and can reach far more than the person could.

What does on-behalf-of mean in practice?

Every request carries two identities: the agent and the person. Policy checks both. The agent's effective permissions are the overlap of what the agent may do and what the person may do.

So if the person cannot read payroll data, neither can the agent acting for them. If the agent is only approved for calendar access, it cannot read the person's mail, even though the person can.

The audit log records both. When something goes wrong, you can see that the agent did it and for whom.

How is this built?

The usual tool is OAuth token exchange, defined in RFC 8693. A service presents the person's token and asks for a new one. The new token is narrower: one audience, fewer scopes. It names the agent as actor through the act claim.

Cross App Access takes a related approach for enterprise apps. The identity provider issues an ID-JAG for the target app. Descope says its ID-JAG tokens preserve the link between agent, user and tenant.

Gateways can also enforce delegation without the agent handling tokens at all. NewCore's gateway shows the agent acting on behalf of a person and keeps it within that person's permissions. Silverfort's gateway enforces SSO through your identity provider and correlates each agent session to a person.

What is a delegation chain?

Agents increasingly call other agents. A planning agent hands a task to a booking agent. The booking agent calls a payment agent.

Each hop is a delegation. The chain is the record of every hop back to the person who started it. If the chain is preserved, the payment request still shows the original employee. If it breaks, the payment comes from the booking agent and nobody else.

Aembit supports delegated, autonomous or chained access, with per-user credential isolation. Cyera Identity preserves a chain of custody from human to agent to actions. Idira captures agent and user identity for every tool call in full mode.

Why does the chain matter so much?

Three reasons stand out.

First, accountability. Regulators and auditors want a person behind consequential actions. A broken chain leaves an action with no human.

Second, permission creep. If each hop can add rights, a chain can end with more access than anyone started with. Preserving the chain lets policy check the original person at every step.

Third, self-approval. If agents can call agents, one might approve another's risky action. NewCore states that an agent can never approve its own action. Ask whether that rule covers chains, not only single agents.

How is delegation different from blended identity?

Aembit uses the term Blended Identity. It means evaluating the agent and the human together in one access decision. That is close to on-behalf-of, with the emphasis on a single policy that sees both.

The difference is mostly framing. Both approaches refuse to judge the agent alone or the person alone. Check how each product logs the pair and whether policies can reference either side.

What about agents that act for nobody?

Some agents are autonomous. A nightly reconciliation agent does not act for any one person. It still needs an owner, but not a delegating user.

For those agents, delegation does not apply. Their access should be scoped to the job and tied to the owner for accountability. Aembit's model names delegated, autonomous and chained access separately, which is a useful way to classify your own agents.

How do Okta and Microsoft handle it?

Microsoft Entra Agent ID includes Identity Governance for on-behalf-of agents. Okta's Agent SSO is built on Cross App Access, which carries the user's identity to the target app. Both handle the sign-in side well.

What they cover less is per-action checking once the agent is working. An agent identity layer runs alongside your identity provider, never instead of it. It adds checks on each call that a token alone does not give.

How do I test delegation before I buy?

Pick two real people with different access. Give each the same agent. Ask the agent to do something only one of them may do.

The agent acting for the person without access should be refused. The refusal should appear in the log with both identities. Then remove a permission from the other person and try again. The agent should lose that permission on its next call, without a restart.

Repeat the test with a chain of two agents. The second agent should still be held to the first person's permissions. If any of these steps fails, the product does not really enforce delegation.

What questions should I ask vendors?

• Show me a log entry for a delegated call. Does it name both agent and person?
• If the person loses a permission, does the agent lose it on the next call?
• How deep can delegation chains go, and can I limit depth?
• Can an agent in a chain approve another agent's action?
• What happens when an autonomous agent's owner leaves?

Where do the scored platforms stand?

Our delegation criterion asks whether an agent acting for a person stays within that person's permissions, with the chain preserved.

NewCore, Aembit and Descope score highest. Cyera Identity follows on the strength of its chain of custody. Silverfort and Idira tie each session or call to a person. Astrix Security, SailPoint Entro and Token Security do not describe delegation chains in the public material we read. See the figures in the standings and the method in how we score.