Where do identity programmes fail when actions can be taken on behalf of a user?

Why This Matters for Security Teams

Identity programmes were built around a simple assumption: a human authenticates, a system authorises, and the resulting action is attributable to that person. That assumption weakens when an application, service, or AI agent can act on someone’s behalf. At that point, the question is no longer just “who logged in?” but “who granted authority, what scope was allowed, and how is the action proved afterward?” NIST’s control baseline in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because attribution, access enforcement, and auditability all depend on disciplined control design.

The practical risk is that delegated actions are often logged as if they were first-party user actions. That can hide token abuse, over-broad consent, stale approvals, and misuse by an autonomous workflow. Once a ticket, bot, or agent can move data, trigger payments, or approve access, the identity system must preserve provenance, not just session status. In practice, many security teams encounter the failure only after a fraud review, privilege escalation, or incident response case has already exposed that delegated authority was never separately governed.

How It Works in Practice

A resilient identity programme needs to model delegated authority as a distinct control path. That means the system should record at least four things: the principal that initiated the original permission, the entity that executed the action, the scope of the delegation, and the time bound or condition under which it was valid. Without that separation, revocation becomes ambiguous and audit trails lose evidential value.

• Use explicit delegation objects or consent grants rather than implicit “act as user” assumptions.
• Bind tokens, sessions, and API credentials to narrow scopes and short lifetimes.
• Log provenance fields that show whether an action was direct, proxied, or agent-mediated.
• Require step-up approval for sensitive actions such as payments, policy changes, or access grants.
• Review delegated entitlements alongside privileged access and service account governance.

This problem is especially sharp where an AI agent has tool access. The agent may be operating under a human’s authority, but the security team still needs to know whether the human approved a specific action, whether the agent inferred that action, or whether a workflow system performed it automatically. Guidance from OWASP Top 10 for Large Language Model Applications is useful when prompts, tool calls, and outputs can trigger downstream side effects. The control objective is not to ban delegation, but to make it observable, bounded, and revocable.

These controls tend to break down when legacy systems flatten every delegated event into a generic user session because the original actor, authoriser, and executor cannot be separated later.

Common Variations and Edge Cases

Tighter delegation controls often increase operational overhead, requiring organisations to balance stronger attribution against user convenience and automation speed. That tradeoff is unavoidable in environments that rely on workflow automation, customer support proxies, financial approvals, or AI assistants. The right answer is not always full human re-approval, but there is no universal standard for this yet on how every delegated action should be classified across industries.

One common edge case is long-lived delegation, where a manager, assistant, or integration is allowed to act over time. Best practice is evolving toward time-boxed scopes, explicit expiry, and periodic re-attestation rather than standing proxy rights. Another edge case is emergency access, where speed matters more than normal approval flow. In those cases, organisations should separate break-glass authority from ordinary delegation and ensure every use is heavily logged and reviewed.

For AI-enabled workflows, the risk becomes more complex because the human may not understand each tool invocation the agent executes. NIST AI Risk Management Framework helps frame this as a governance and accountability problem, while MITRE ATLAS is useful for thinking about adversarial abuse of AI systems and toolchains. Where delegation touches personal data or regulated transactions, organisations should also assess whether consent, disclosure, and retention requirements are still being met.

Related resources from NHI Mgmt Group

• Why do manual user access reviews fail in modern identity programmes?
• Why do identity programmes fail when they focus only on end-user experience?
• Why do user access reviews fail in mature IAM programmes?
• Why does single-vault consolidation often fail in enterprise identity programmes?