Per-resource roles define ongoing access to a named resource, so they answer what an identity can generally do there. Per-invocation approval governs a single call or time window, so it answers whether one specific action should proceed now. Roles control standing authority. Approval controls occasions, especially when the action is destructive or externally visible.
How standing roles differ from one-time approvals
Per-resource roles are an authorization model for persistent access. They define the baseline permissions an identity carries whenever it reaches a named resource, so they are best when the action is routine, low variance, and easy to bound by role design. Per-invocation approval is a decision point at request time, which lets the system re-check context before a single action is allowed.
The practical difference is not just granularity, but timing and durability. A role answers, “does this identity generally have this kind of access here?” An approval answers, “should this exact action proceed now?” That means roles are cheaper to operate at scale, while approvals are better when every execution has meaningful business or security consequences.
Roles also tend to encode entitlement structure. They work well when the same access pattern repeats across many requests and the main problem is keeping the permission model coherent. Per-invocation approval is better when the control objective is to prevent a specific act unless a current condition, reviewer, or policy gate says yes. In practice, teams often use both: the role gets the identity to the right resource, and the approval gates the sensitive operation.
When each model is the better fit
Use per-resource roles when the resource has a stable access pattern, the action set is predictable, and overbroad standing access can be kept under control through role design and review. This is the cleaner model for everyday read/write access, service integration, and workflow access that should not depend on repeated human intervention.
Use per-invocation approval when the action itself is the risk event. Typical cases include destructive operations, privileged changes, externally visible actions, or requests that should be checked against current business context before execution. The approval can be manual or policy-driven, but the key property is that authorization is evaluated for that single occasion rather than granted as an enduring right.
The decision often comes down to blast radius and frequency. If the same action is common and low risk, standing roles are usually the right primitive. If the action is uncommon, high impact, or sensitive to timing, per-invocation approval gives better control. The more reversible and routine the action, the more roles make sense; the more consequential and context-dependent it is, the more approval makes sense.
Why the distinction matters in fine grained authorization
fine grained authorization is not only about making permissions smaller. It is about choosing the right control point for the kind of decision you are making. A per-resource role constrains access at the entitlement layer, while per-invocation approval constrains execution at the moment of use. Those are different control surfaces, and confusing them leads to either excessive standing access or slow, brittle operations.
That difference becomes especially important when you need both predictability and restraint. Roles provide stable operating authority and support automation, delegation, and auditability. Approvals provide a friction point for high consequence actions where “allowed in general” is not enough. If you treat approval as a substitute for good role design, you create workflow drag without fixing entitlement sprawl. If you rely on roles alone for sensitive actions, you risk granting more standing power than the business actually needs.
In mature designs, the two layers are complementary rather than competing. The role defines the allowed surface area, and the approval determines whether one specific use of that surface area is acceptable now. That separation is what keeps fine grained authorization precise without turning every request into a manual exception.
Risk and Threat Considerations
Standing roles increase exposure if they are too broad, stale, or reused across workflows that do not share the same risk profile. Per-invocation approval reduces that standing exposure, but it can be bypassed in practice if approvals are treated as ceremony, automated without sufficient conditions, or granted so frequently that they no longer represent a meaningful control.
Failure mechanism: Excessive per-resource roles create durable overpermission, while weak per-invocation approval creates a false sense of control because the sensitive action still proceeds on a routine basis.
Impact: The result can be unauthorized changes, destructive operations, or externally visible actions taken without adequate current review, especially when privileges are reused across systems or requests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Roles and approvals both shape how much access an identity can exercise. |
| AC-3 — Access Enforcement | Per-invocation approval is an execution-time access decision enforced at request time. | |
| Recommendation — Limit standing permissions to the minimum needed for each resource and action. Enforce a fresh authorization decision before allowing each sensitive action. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The question is about how access is granted and constrained at fine granularity. |
| Recommendation — Separate baseline access roles from time-bound approval gates for high-impact actions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Per-resource roles and per-invocation approval are both access control design choices. |
| Recommendation — Define access rules so standing permissions and per-action approvals are distinct and reviewable. | ||
| OWASP ASVS | V8 — Authorization | Fine grained authorization is directly about who may do what and when. |
| Recommendation — Verify that sensitive operations require the intended authorization path, not just a broad role. | ||
Practitioner Guidance
What to verify: Check whether the action is genuinely repeatable enough to justify standing access, or whether the business really wants a current decision each time. If the action can cause material harm in one execution, treat per-invocation approval as the primary control and keep the underlying role narrow.
Decision rule: If the resource access is routine and the risk is in overreach, favour per-resource roles with tight review. If the risk is in the act itself, not merely in reaching the resource, favour per-invocation approval and make sure the approval criterion is specific enough to be auditable.
Practitioner takeaway: The real design choice is between managing standing authority and managing execution-time risk; good fine grained authorization usually keeps the role small and reserves approval for the moments that truly need a current gate.
Related resources from NHI Mgmt Group
- What is the difference between coarse-grained and fine-grained authorization in a modern API stack?
- What is the difference between Firebase security rules and externalized fine-grained authorization?
- What is the difference between gateway-level authentication and fine-grained authorization for APIs?
- What is the difference between RBAC and fine-grained authorization in customer banking applications?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
