On-behalf-of authorization: what actually proves who acted?

TL;DR: On-behalf-of authorization is often misread because different token patterns place the human, the software actor, and the audience in different claims, so sub alone does not prove a person acted, according to Agentic Fabriq. The practical test is to decode a real token and verify whether the credential carries both principals and the correct audience before trusting audit trails.

Editorial analysis by NHI Mgmt Group, based on content published by Agentic Fabriq: “What On-Behalf-Of Authorization Actually Proves”.

Key questions

Q: What breaks when an API treats sub as the user by default?

A: The audit trail breaks first.

Q: Why does audience validation matter for delegated access?

A: Because attribution is only meaningful if the token was issued for the service that is consuming it.

Q: What do security teams get wrong about agent authorization?

A: They often treat role checks as sufficient because every call appears schema-valid and authorised.

Practitioner guidance

• Decode one real production token Inspect the token that the resource server actually receives, not the one the client claims it sent.
• Separate attribution from authentication in audit design Store both the human subject and the acting software identity when the flow supports delegation, and do not collapse either into a generic user field.
• Validate audience before interpreting claims Reject tokens whose aud does not correspond to the resource server before you rely on sub, act, or client identity for logging, approvals, or investigations.

Bottom line: On-behalf-of language hides two different accountability patterns, and only one of them preserves enough structure to prove a human action downstream.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →