A control model that evaluates each request as it happens rather than trusting a session after login. For agentic systems, it matters because the same authenticated identity can produce different risk outcomes depending on context, target system, and current instructions.
Expanded Definition
Per-action authorization is a decision model in which each request is evaluated at the moment it is made, rather than assuming a previously authenticated session remains safe for every later operation. In NHI and agentic AI environments, that distinction matters because the same service account, token, or agent identity may behave safely in one context and dangerously in another.
This approach is closest in spirit to Zero Trust, where trust is continuously re-evaluated instead of granted once and reused indefinitely. NIST’s NIST Cybersecurity Framework 2.0 reinforces the need for ongoing access governance, while the practical NHI guidance in Ultimate Guide to NHIs shows why static trust is fragile when secrets, workloads, and agents change rapidly. Definitions vary across vendors on whether per-action authorization must include environmental signals, policy engines, or human approval, so the term should be read as an architectural principle rather than a single product feature.
The most common misapplication is treating a logged-in session as blanket permission, which occurs when teams authorize the identity once and then allow high-risk actions to proceed without re-checking context.
Examples and Use Cases
Implementing per-action authorization rigorously often introduces latency and policy complexity, requiring organisations to weigh stronger control against the operational cost of evaluating more decisions in real time.
- An agent requests access to a production database after a normal task run, and the policy engine blocks the action because the target is outside the agent’s approved scope.
- A CI/CD pipeline token can read artifact metadata but must be re-authorized before it can publish to a release registry, reducing blast radius if the token is reused.
- A service account authenticated through workload identity may still be denied when it attempts a destructive API call outside the expected deployment window.
- An LLM tool call to send an email or transfer funds is allowed only after per-request checks confirm the prompt, destination, and current approval state are acceptable.
- Per-action controls become especially important when secrets are discovered in code or configuration, a risk highlighted in Ultimate Guide to NHIs, because a stolen credential should not automatically inherit unlimited runtime power.
For workload identity design, SPIFFE’s workload identity model is often paired with per-action policy enforcement, although the exact enforcement point depends on the architecture and no single standard governs implementation details yet.
Why It Matters in NHI Security
Per-action authorization is central to limiting the damage that follows credential theft, prompt injection, token replay, or agent misrouting. NHIs often hold broader privileges than human users, and Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which means a single unchecked request can become a major incident path. In practice, the value of this control is not just prevention but containment: even if an identity is compromised, each action can still be constrained by current purpose, destination, and risk posture.
This matters for governance because static allowlists and long-lived sessions create hidden trust that attackers can reuse. NIST’s NIST Cybersecurity Framework 2.0 supports continuous access review, but per-action authorization makes that principle operational for agents, APIs, and service accounts. Organisations typically encounter the real need for this control only after a stolen token, rogue agent action, or unauthorized API call has already crossed the boundary, at which point per-action authorization becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Per-action checks reduce the blast radius of compromised NHI secrets and overprivileged requests. |
| NIST CSF 2.0 | PR.AC-4 | Supports continuous access enforcement instead of one-time session trust. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of access decisions, not assumed session trust. |
Re-evaluate every NHI request before execution and deny actions that exceed current policy or context.
