Who is accountable when an application acts on behalf of a user?

The organisation is accountable for the access design, but operational accountability becomes unclear if the platform suppresses the application’s identity. That is why cloud identity models must preserve actor separation: without it, accountability shifts from evidence to inference.

Why This Matters for Security Teams

When an application acts on behalf of a user, accountability depends on preserving both the user’s intent and the application’s own identity. If a platform collapses those two actors into one log trail, investigators lose the evidence needed to answer a basic question: was the action approved, expected, and executed by the right workload? NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes actor separation more important, not less. The issue is not only access control but attribution, because approvals, audits, and incident response all depend on clear identity boundaries.

Security teams often assume user delegation is enough, but delegated access without workload identity turns every event into a reconstruction exercise. That creates gaps in audit evidence, weakens non-repudiation, and makes it harder to prove whether the application behaved within policy or simply inherited broad access. In practice, many security teams encounter accountability failures only after a suspicious API call, data export, or privilege escalation has already occurred, rather than through intentional design.

How It Works in Practice

The cleanest model is to keep the user, the application, and the session distinct. The user expresses intent, the application authenticates as its own workload identity, and the platform records both identities in a way that survives downstream processing. This is the practical foundation for traceability in cloud and agentic systems, and it aligns with the direction of NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasise accountability, auditability, and least privilege.

In modern architectures, that usually means:

• Issuing a workload identity for the application, such as an OIDC-backed token or a SPIFFE/SPIRE identity, so the system can prove what the application is.
• Binding the application action to the user’s request context, so logs show who requested the operation and which service executed it.
• Using short-lived credentials or just-in-time permissions instead of long-lived shared secrets, so delegated access expires with the task.
• Applying policy at request time, not only at design time, so authorisation reflects current context, data sensitivity, and execution path.
• Preserving immutable audit records across gateways, brokers, and downstream services, because attribution often fails at integration boundaries.

This matters because application-on-behalf-of flows often involve token exchange, service chaining, and multiple hops where identity can be degraded or replaced by platform metadata. Without explicit actor separation, logs show “something happened” but not who requested it or which application carried it out. That is why Ultimate Guide to NHIs treats visibility and lifecycle control as governance essentials, not optional hygiene. These controls tend to break down in event-driven microservice meshes where identity is normalised by gateways and downstream services never receive the original user context.

Common Variations and Edge Cases

Tighter identity separation often increases implementation overhead, requiring organisations to balance stronger attribution against system complexity and developer friction. Current guidance suggests that the tradeoff is worth it for any workflow with regulated data, privileged operations, or irreversible side effects, but there is no universal standard for this yet.

Edge cases appear when platform teams use shared service accounts, anonymous job runners, or identity translation layers that strip original claims for convenience. In those environments, accountability becomes inferential rather than evidentiary, and that is a governance weakness even if the access technically works. A second complication is third-party automation: when an external application acts for a user, organisations may retain legal accountability while operational visibility is split across vendors and cloud controls. The NHIMG research base shows why this matters, with only 5.7% of organisations reporting full visibility into service accounts, which makes delegated actions difficult to reconstruct after the fact.

For high-risk systems, best practice is evolving toward explicit workload identity, task-scoped credentials, and policy decisions that record both principal and delegate. Where that is not yet feasible, security teams should at minimum preserve original user context end to end and avoid suppressing application identity in logs, tickets, or SIEM pipelines. Otherwise, incident response will rely on guesswork instead of proof.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent runs a query on behalf of a user?
• Who is accountable when a malicious OAuth application is approved by a user?
• Who is accountable when an application keeps access after a user leaves the directory?
• Who is accountable when an AI agent acts after the user is offline?