Per-identity reviews certify one subject at a time, while chain-based authorization evaluates the whole delegated transaction. That difference matters when a human, an agent and a service together create the access path. The governance unit becomes the composed workflow, not any single account or role.
How per-identity review and chain-based authorisation differ in practice
Per-identity access reviews look at one principal at a time and ask whether that account should keep its standing access. Chain-based authorisation asks a different question: should this specific end-to-end transaction be allowed when multiple actors, roles, tokens, and delegated steps combine to make it possible?
The distinction matters because a clean review of a single account can miss a dangerous composed path. A human may approve a request, an agent may invoke a tool, and a service may execute the action, yet none of those pieces looks excessive in isolation.
In governance terms, per-identity review is a snapshot of entitlement ownership, while chain-based authorisation is a runtime decision about effective power. The first is better for recertification and attestation; the second is better for deciding whether a delegated workflow should proceed at all.
What each model protects, and where it breaks down
Per-identity review works best when the access question is stable and attributable to a single subject. It is useful for entitlement hygiene, role cleanup, and proving that an identity still needs what it has been granted. It is weaker when access is assembled dynamically across trust boundaries or when the same outcome depends on several partial permissions that only become risky in combination.
Chain-based authorisation is better when the security decision depends on context across the whole transaction, not just the endpoint account. That includes delegated access, approval chains, service-to-service calls, and agentic workflows where one actor inherits or exercises another actor’s authority. The decision point moves from “does this identity have access?” to “does this composed action have permission now?”
This is why access review and authorisation are related but not interchangeable. Review governs standing access over time, while chain-based controls govern the immediate path to action. A mature programme usually needs both, especially where IAM and IGA basics are being extended beyond human users into workflows, services, and delegated access paths.
Why the distinction matters for humans, services, and agents
Once a human, an AI agent, and a backend service all participate in the same transaction, the governance unit is no longer the account alone. The useful control boundary becomes the composed workflow, which is why many teams now pair identity review with per-action policy decisions and explicit delegation rules.
That is especially important for non-human identities, where standing permissions often outlive the business task that justified them. Review can tell you whether a service account still exists for a valid purpose; chain-based authorisation tells you whether this specific action should be allowed when that service account is invoked through a larger workflow.
For teams formalising that shift, the practical question is whether the control is attached to the identity record or to the operation itself. AI Agent Authorisation Guide and Authorisation Models Guide are useful references when the answer depends on task scope, policy evaluation, and delegated authority rather than static role membership.
Risk and Threat Considerations
When organisations rely only on per-identity review, they can certify a set of accounts while missing the real attack surface: the path that emerges when those accounts are chained together. That creates exposure to privilege aggregation, hidden delegation, and approval abuse, especially in environments where service accounts or agents can trigger actions that look benign in isolation.
Failure mechanism: A weak control reviews accounts one by one, but the effective permission is created only after an attacker, workflow, or agent combines several otherwise acceptable grants into a high-impact transaction.
Impact: Excessive access can survive recertification, making escalation, lateral movement, and unauthorized action harder to spot until the workflow is already in motion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Chain-based authorization is about limiting effective privilege on each transaction. |
| IA-5 — Authenticator Management | Composed workflows often depend on token and secret lifecycle, not just identity records. | |
| AU-2 — Event Logging | Transaction-level authorization needs audit evidence across each delegated step. | |
| Recommendation — Enforce least privilege at the action level, not only during periodic entitlement review. Manage credentials and tokens so delegated transactions cannot outlive their intended scope. Log the full authorization chain so reviewers can reconstruct who approved and executed each step. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control must distinguish standing access governance from runtime authorization. |
| A.8.5 — Secure authentication | Delegated access chains depend on trustworthy authentication between actors and services. | |
| Recommendation — Define access rules that cover both entitlement reviews and composed transaction decisions. Require strong authentication for each participant in the delegated access path. | ||
| CIS Controls v8 | CIS-5 — Account Management | Per-identity reviews map directly to account and entitlement governance. |
| Recommendation — Review and remove unnecessary accounts, roles, and standing access on a recurring basis. | ||
| OWASP ASVS | V8 — Authorization | Chain-based authorization is a runtime authorization problem, not only an identity review problem. |
| Recommendation — Verify that each sensitive action is authorized using context, not just static identity membership. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-mediated chains can turn delegated authority into excessive effective privilege. |
| Recommendation — Constrain agent authority so chained actions cannot exceed the approved scope. | ||
Practitioner Guidance
What to prioritise: Treat per-identity review as hygiene and chain-based authorisation as enforcement. If the business risk comes from a multi-step action, build the policy around the workflow, not just the accounts involved.
What to verify: Check whether approvals, token delegation, service impersonation, and tool invocation are all visible in the same decision path. If they are not, your review process may be certifying identities while missing the operational permission actually used.
What good looks like: Standing access is recertified on a schedule, but the high-risk action still requires a fresh policy decision at runtime. The workflow cannot succeed simply because each participant individually has some authority.
Practitioner takeaway: Use per-identity reviews to manage who should have access, and chain-based authorisation to manage what composed actions should be allowed; confusing the two is how delegated excess privilege stays hidden.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between session-based access and per-request authorization?
- What is the difference between network-level access control and identity-based authorization for AI infrastructure?
- What is the difference between reviewing human access and reviewing NHIs?