Per-action policy is a governance pattern where each agent step, API call, or delegated operation is checked before execution continues. It is stronger than a one-time login decision because it evaluates the agent’s behaviour as it unfolds, not just its initial access grant.
Expanded Definition
Per-action policy is a runtime governance pattern for NHI and agentic systems in which each step is checked before execution continues. That includes tool calls, API requests, delegated actions, and any state-changing operation an NIST Cybersecurity Framework 2.0 implementation would treat as a material control point. The policy decision is not a one-time approval at login; it is applied repeatedly as the agent’s intent, context, and destination evolve.
In NHI security, this matters because a service account or AI Agent can begin with legitimate access and still become risky after a prompt change, tool misuse, token exposure, or a shift in workflow. Definitions vary across vendors on whether per-action policy is enforced by the agent runtime, an external policy engine, or an API gateway, so the operational requirement is consistency rather than a single product design. Per-action policy is closely related to Zero Trust Architecture and just-in-time governance, but it is narrower because it evaluates each action instead of only the identity session. It is also different from RBAC alone, because roles do not inspect the live context of each call.
The most common misapplication is treating a successful initial authentication as sufficient, which occurs when organisations grant broad standing access and fail to re-evaluate individual actions before execution.
Examples and Use Cases
Implementing per-action policy rigorously often introduces latency and policy complexity, requiring organisations to weigh tighter control against faster agent execution. That tradeoff is usually justified when the action can move data, spend money, alter infrastructure, or cascade into further delegated access.
- An agent requests access to a production API, and the policy engine allows the call only if the request matches the approved resource, time window, and purpose.
- A build bot tries to pull a secret from a vault, and the action is denied unless the request originates from the expected pipeline stage and workload identity.
- An AI Agent attempts to send data to an external service, and the action is allowed only after the destination is checked against a permitted egress list and data classification rule.
- A privileged workflow in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is interrupted midstream because the delegated token is no longer valid for the next step.
- A response team uses Top 10 NHI Issues as a reference point to identify where unchecked action chaining created avoidable exposure.
These patterns are also consistent with NIST Cybersecurity Framework 2.0 expectations for ongoing control enforcement rather than static trust decisions.
Why It Matters in NHI Security
Per-action policy closes the gap between identity proof and operational trust. Without it, compromised secrets, overprivileged service accounts, and misbehaving agents can continue acting long after the initial access decision should have been reconsidered. This is especially important in environments where NHIs outnumber human identities by 25x to 50x and 97% of NHIs carry excessive privileges, because a single unchecked action can turn a routine workflow into a breach path.
NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes post-authentication control even more important than the initial login event. Per-action policy gives security teams a practical place to enforce least privilege, constrain delegated tool use, and stop action chaining before damage spreads. It also supports auditability when regulators or internal reviewers need to trace why a specific agent step was allowed, blocked, or escalated, as discussed in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives.
Organisations typically encounter the need for per-action policy only after an agent has already called the wrong API, exfiltrated data, or reused a valid token in an unintended workflow, at which point the control 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-05 | Per-action checks limit abuse of agent steps and delegated operations. |
| NIST CSF 2.0 | PR.AC-4 | Ongoing access enforcement aligns with least-privilege access management. |
| NIST Zero Trust (SP 800-207) | PA | Policy enforcement at each request reflects Zero Trust decision-making. |
Evaluate every NHI or agent action before execution and block out-of-policy calls.
