Identity chained authorisation is a pattern for preserving who approved a task and what authority was delegated as work moves across agents and services. Each receiving system uses that evidence alongside its own policy, so access decisions can be tied back to the originating approval, the acting principal, and the intended scope of use.
What Identity Chained Authorisation Does
Identity chained authorisation is about preserving delegated authority as a request moves across systems, so each participant can see not just that an action was approved, but also who approved it, who is acting, and what scope of authority should still apply.
That makes it more than a handoff token or a static permission grant. The chain is the evidence path that lets later systems make an access decision using the original approval context rather than treating every downstream hop as a brand-new, fully trusted request.
Why the Authorisation Chain Matters
The value of chaining is that authority can narrow, expire, or be re-evaluated as work is delegated. A downstream service may accept the request only if the approving identity, the acting principal, and the intended task still match policy, which helps preserve least privilege across boundaries. Concepts such as Authorisation Models Guide and AI Agent Authorisation Guide are useful reference points for understanding how policy-based decisions and delegated action scope fit into this pattern.
In practice, chained authorisation is most useful where a task is split across tools, services, or agents that should not inherit open-ended trust. It lets each step carry evidence of the original approval while still requiring the receiving system to apply its own controls, rather than assuming that upstream approval alone is sufficient.
How It Differs From a Simple Approval or Token
A simple approval records consent; a chained authorisation records consent plus continuity of authority. That distinction matters when the original approval needs to survive multiple hops, because the receiving system must know whether the delegate is still within the approved scope and whether any new action exceeds that scope.
It also differs from a bearer credential or ambient session. The chain is supposed to preserve provenance and delegated intent, not just authenticate a caller. Where the chain is well designed, the downstream system can evaluate the current request against both the active principal and the originating approval context, rather than relying on a single opaque credential.
Where It Fits in Security Architecture
Identity chained authorisation is strongest when combined with policy enforcement, scoped delegation, and clear evidence of who initiated the work. That is why it aligns naturally with access governance, fine-grained authorisation, and task-scoped controls. The same principle appears in broader identity governance guidance such as IAM and IGA Basics, and in lifecycle thinking such as NHI Lifecycle Management Guide where access should remain traceable as it is provisioned, used, and eventually withdrawn.
For systems that move work between people, workloads, or autonomous agents, the architecture has to preserve both trust and accountability. If the chain is broken, the downstream system loses the ability to tell whether the action is still legitimate, still in scope, and still tied to the correct initiating authority.
What Can Break the Chain
Chained authorisation fails when approvals are not bound to the acting principal, when scope is not carried forward, or when downstream systems treat the chain as advisory rather than enforceable. That is why lifecycle and governance controls matter even more than the initial approval event, especially where delegation is repeated across service boundaries. For a broader risk view, Top 10 NHI Issues and Ultimate Guide to NHIs, Key Challenges and Risks both frame the practical consequences of excessive privilege, weak visibility, and unmanaged credentials.
When the chain is weak, downstream systems may over-trust delegated actions, preserve authority for too long, or lose provenance entirely. That creates a familiar security failure pattern: the original approver no longer meaningfully controls what the delegate can do, and the receiving service cannot prove that the action still matches the approved intent.
Risk and Threat Considerations
Chained authorisation is valuable precisely because it can fail in ways that create overreach, persistence, and blurred accountability. If the approval evidence is not strongly bound to the acting identity and its scope, an attacker or a sloppy integration can reuse delegated authority beyond the intended task.
Failure mechanism: The chain is weakened when scope, provenance, or expiry is dropped at a service boundary, allowing a downstream system to treat inherited authority as more general than it really is.
Impact: That can lead to privilege escalation, unauthorised task execution, and a loss of auditability over who actually authorised the action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Covers delegated access, authorization, and identity governance across systems. |
| Recommendation — Bind delegated authority to enforceable IAM policy at every receiving service. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Chained approval depends on governed identities and lifecycle-managed access paths. |
| AC-6 — Least Privilege | The chain should preserve narrow, task-scoped authority across hops. | |
| AU-2 — Event Logging | Preserving who approved and who acted requires auditable provenance across systems. | |
| Recommendation — Track delegated access paths and revoke them when the approved task ends. Limit each hop to the minimum authority needed for the approved action. Log the approver, actor, scope, and delegation path for each decision. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Downstream services must not trust inherited approvals to exceed function scope. |
| Recommendation — Verify that each service enforces function-level authorization on chained requests. | ||
Practitioner Guidance
Governance implication: Treat the approval chain as an enforceable part of the access decision, not as metadata that only helps with audit. The receiving system should be able to evaluate who approved the action, who is acting, and whether the current request still matches the approved scope.
What to watch for: Pay close attention when delegation crosses systems, identities, or trust domains, because that is where scope drift and provenance loss are most likely to appear. Authorisation Models Guide is a useful reminder that the policy decision, not the original approval alone, should remain authoritative at each hop.
