Static rules fail because agentic systems produce risk through combinations that change at runtime, not through one fixed permission state. A rule can flag one issue, but it often misses the toxic mix of exposure, privilege, and sensitive data that makes the path dangerous in practice.
Why static rules miss agentic risk
Static rules usually assume a stable condition: one permission, one data source, one action path. Agentic systems change the security picture at runtime, because the risk comes from how tasks, context, tools, memory, and authority combine in sequence. That means the dangerous state is often emergent, not visible from any single rule check.
Agent behaviour also shifts with prompts, retrieved context, tool outputs, and delegated approvals. A rule that looks correct for one step can fail once the agent chains actions, reuses context, or crosses a trust boundary. The security question is not only “is this action allowed?”, but “what happens when allowed actions interact?”
That is why a narrow allow or deny rule can miss the real hazard. A system may appear compliant at the individual-control level while still creating a path for escalation, data leakage, or unintended execution when the agent assembles multiple benign permissions into one harmful workflow.
What makes the dangerous state emergent
Agentic risk is often compositional. A low-privilege agent can become risky when it can read sensitive context, invoke external tools, and act on behalf of a user or workflow. None of those capabilities is necessarily unsafe alone, but together they can create a path that static policy rules do not model well.
Runtime context is also unstable. The same agent may behave differently depending on what it retrieves, which tool it selects, which intermediate output it trusts, and whether a human approval step is actually meaningful or just procedural. That is why practitioners need to think in terms of action chains, not isolated permissions.
For a practical threat model, the right lens is how an agent can move from input to decision to external effect. NHIMG’s Agentic AI Security Guide is useful here because it treats inputs, memory, tools, orchestration, and identity as a single security path rather than separate checkboxes.
Why controls must reason about identity, tools, and trust together
Static rules fail most visibly where authorization is fragmented. An agent may be allowed to read one source, call one tool, or forward one request, yet the combination can still create overreach. That is the same basic failure mode behind excessive agency: the policy engine evaluates pieces of the workflow, but not the cumulative effect of the workflow itself.
That is also why least privilege must be per action, not just per account. If the agent can obtain sensitive context, invoke a tool, and pass results onward without a fresh decision point, the policy has already lost the chance to evaluate the full risk of the next step. NHIMG’s AI Agent Authorisation Guide focuses on task-scoped access, just-in-time privilege, delegated authority, and human approval as a single control pattern.
Identity is part of the control path, but it is not enough by itself. An agent can be authenticated and still unsafe if its available tools, memory, or downstream reach are not bounded. Zero Trust for AI Agents is a good fit when you need continuous verification, no standing privilege, and per-action policy decisions instead of a one-time trust grant.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic systems fail when runtime privilege and identity combine across steps. |
| ASI02 — Tool Misuse | Static rules miss harmful tool chains that only emerge during execution. | |
| ASI08 — Cascading Failures | The question is about harmful combinations that grow as agent actions chain. | |
| Recommendation — Enforce step-level authorization and limit delegated privilege for each agent action. Constrain tool selection and validate each tool call against current task intent. Design controls to interrupt failure propagation across chained agent actions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agentic systems need privilege bounded by action, not just account state. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Runtime combinations need logs that show the full action chain and context. | |
| IA-5 — Authenticator Management | Delegated agent access depends on how credentials and tokens are issued and controlled. | |
| Recommendation — Apply least privilege to each agent capability and remove unnecessary standing access. Review agent audit trails for chained actions, privilege changes, and abnormal sequences. Rotate and scope agent credentials so they cannot persist beyond the intended task. | ||
| NIST Zero Trust (SP 800-207) | AC-04 — Microsegmentation | Dynamic agent workflows need boundaries that limit what a successful action can reach. |
| DP-04 — Continuous Diagnostics and Mitigation | Agent risk changes at runtime, so verification must be continuous rather than one-time. | |
| Recommendation — Segment agent reach so a compromise or misuse cannot traverse the full environment. Continuously reassess agent requests, context, and trust before allowing the next step. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agentic actors become risky when permissions exceed the minimum needed for the task. |
| NHI-07 — Long-Lived Secrets | Static rules fail when long-lived credentials let agents keep acting outside the intended window. | |
| Recommendation — Reduce agent privilege to the narrowest task scope and remove excess entitlements. Replace long-lived agent secrets with short-lived, tightly scoped credentials. | ||
Practitioner Guidance
What to prioritise: Model the agent as a sequence of decisions and side effects, not as a single user session. The first question is whether any one action can combine with retrieved context or tool access to create a larger blast radius than the individual permission suggests.
What to verify: Confirm that policy enforcement happens at the moment of action, with current context, current tool intent, and current data sensitivity. If the control only checks initial login or coarse role membership, it will miss the runtime combinations that matter most.
Common mistake: Treating prompts, tools, memory, and authorisation as separate controls owned by separate teams. In practice, the failure often sits at the boundary between them, so the review must cover the whole chain from instruction to external effect.
Practitioner takeaway: Static rules work for fixed states, but agentic security needs controls that re-evaluate intent, context, and privilege at each step where the system can still change the outcome.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org