Why does on-behalf-of access create audit and accountability risk?

Why the audit trail becomes unreliable

On-behalf-of access is risky for audit because the recorded event can collapse delegation into a single principal. That makes a legitimate human request look like direct application activity, or it can make application action appear to be human action. Once that happens, the log may still show “who did something,” but not reliably “who authorised it” and “which component executed it.”

The practical problem is attribution, not just authentication. If your evidence only records the token holder or the last caller in the chain, you lose the context needed to prove delegation, reconstruct approval, and separate human intent from machine execution. That weakens incident review, access review, and any control that depends on end-to-end traceability.

When the delegation path is explicit and preserved, on-behalf-of access can support traceable workflows. The issue is that many implementations stop at a single effective identity, which is enough for runtime permission checks but not enough for later accountability. For that reason, the audit record needs to carry both the originating actor and the executing actor in a way investigators can trust.

Where accountability breaks down in practice

Accountability fails when the organisation cannot answer three separate questions from the record: who requested the action, who approved or delegated it, and which identity actually exercised the privilege. If those answers are merged, challenged, or implied rather than captured, the evidence can support access decisions but not responsibility decisions. Agentic AI Identity Guide is useful here because it shows why delegation, ownership, and actor claims must survive across the full action chain.

That matters most in environments with shared service execution, federated token exchange, or automated workflows that act on behalf of a user. In those cases, an apparently simple request can touch multiple trust boundaries, and a shallow log model hides the boundary crossings. RFC 8693: OAuth 2.0 Token Exchange is the clearest reference for delegation patterns that need explicit provenance if you want trustworthy audit evidence.

A second failure mode appears when ownership and offboarding are unclear. Even if the action was valid at the moment it ran, the organisation still needs to know which account, application, or delegated capability was responsible when later challenged. NHI Ownership and Accountability Guide is relevant because accountability is not only a control-plane issue, it is also an ownership and evidence-retention problem.

How to preserve evidence that stands up in review

The core design requirement is to preserve provenance, not merely session state. A strong audit record should retain the initiating user, the delegated application or workload, the scope or resource targeted, and the exact mechanism used to exchange or convey authority. If any of those are missing, the log may be operationally useful but weak as evidence.

Practitioners should prefer records that can distinguish approved delegation from direct impersonation, and routine automation from privileged action. That usually means capturing token exchange context, subject and actor claims, correlation identifiers, and the policy decision that allowed the handoff. NHI Authentication Guide is relevant because it covers the authentication mechanisms that create the evidence trail behind delegated access.

The strongest model is the one that lets investigators reconstruct the path without relying on application memory or tribal knowledge. If the organisation cannot explain the full chain from user intent to executed operation, then the access model is too weak for regulated or high-impact actions. RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens matters because binding the token to the client helps reduce ambiguity about which actor actually presented authority.

Risk and Threat Considerations

On-behalf-of access increases exposure when organisations rely on logs that only preserve the effective caller. An attacker, insider, or careless integrator can exploit that ambiguity to make misuse harder to attribute, especially where delegated privileges are broad or short-lived. The result is not just a weaker audit trail, but a weaker ability to prove whether misuse came from the user, the application, or a compromised intermediary.

Failure mechanism: the platform collapses delegation into one recorded identity, omits the originating actor, or fails to retain the token exchange and authorization context needed to separate human intent from machine execution.

Impact: incident reconstruction becomes less reliable, privilege reviews lose evidentiary value, and organisations may be unable to defend disciplinary, legal, regulatory, or remediation decisions with confidence.

Practitioner Guidance

What to verify: Check whether every on-behalf-of transaction preserves the initiator, the delegate, the target resource, and the authority path in a form that can be independently reconstructed. If any of those are inferred from application behaviour rather than recorded explicitly, treat the audit trail as incomplete.

Decision rule: If the action can affect sensitive data, financial outcomes, production systems, or incident evidence, require delegation-aware logging before allowing the flow into production. If the business only needs convenience, the control can be lighter, but the accountability standard should still be explicit.

Practitioner takeaway: On-behalf-of access is not inherently a logging problem, it is an evidence problem, and the test is whether a reviewer can still separate authorisation from execution after the fact.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• When does JIT access create more risk than it reduces?
• Why do non-human identities create compliance risk even when policies exist?