What breaks when AI security relies only on policy and review?

Why This Matters for Security Teams

Policy and review are necessary, but they are not sufficient when the workload is autonomous. AI agents do not follow a fixed human workflow, and they can chain tools, retry actions, or pursue goals in ways that a pre-approved policy cannot predict. That makes static approval models fragile: they document intent, but they do not stop a live agent from reaching restricted data, calling an unexpected API, or escalating through a connected system.

This gap is visible in NHI operations as well. NHIMG’s The State of Non-Human Identity Security reports that only 1.5 out of 10 organisations are highly confident in securing NHIs, while 85% lack full visibility into third-party vendors connected via OAuth apps. The lesson for agentic systems is direct: if the identity can act at runtime, control must also exist at runtime. Current guidance from the NIST Cybersecurity Framework 2.0 still depends on continuously enforced safeguards, not one-time review.

In practice, many security teams encounter unsafe agent behaviour only after an unauthorized tool call or data exposure has already been logged, rather than through intentional prevention.

How It Works in Practice

Effective control for AI security starts by treating the agent as a workload with a runtime identity, not as a user surrogate. Static RBAC can define broad boundaries, but it cannot express the actual intent of a task at the moment the agent tries to execute it. For that reason, current best practice is evolving toward context-aware authorization, where policy is evaluated at request time and can consider task scope, data sensitivity, tool destination, and environment state.

That usually means combining workload identity, short-lived credentials, and policy-as-code. A system can issue ephemeral access for one task, validate the agent’s workload identity, and revoke access immediately when the task ends. This is closer to the control model described in NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which emphasizes lifecycle discipline over standing access. In agentic environments, that lifecycle must be much shorter and more granular.

Practical teams also evaluate each high-risk action against live context using policy engines such as OPA or Cedar, and they pair that with monitoring for tool chaining and unusual prompt-driven behaviour. Frameworks such as the CSA MAESTRO agentic AI threat modeling framework help teams model how an agent could move from one approved action to a more dangerous one. The right question is not whether the agent was reviewed, but whether the next action is safe to allow now.

• Use workload identity to prove what the agent is before granting any tool access.
• Issue just-in-time credentials with short TTLs and automatic revocation after task completion.
• Evaluate policy at request time, not only during design review or quarterly audit.
• Log the decision path for each tool call so security teams can investigate intent, context, and outcome.

These controls tend to break down in multi-agent pipelines with shared tool buses because one agent’s approved output can become another agent’s unauthorized input.

Common Variations and Edge Cases

Tighter runtime control often increases engineering overhead, requiring organisations to balance prevention against latency, workflow friction, and operational complexity. That tradeoff is real, especially when teams are trying to secure both traditional NHIs and autonomous agents in the same stack.

There is no universal standard for this yet. Some environments can enforce every tool call with strong policy-as-code, while others only apply runtime checks at the highest-risk steps. In highly regulated workflows, review still matters for accountability and auditability, but it should be treated as evidence of governance, not as a substitute for enforcement. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because it separates control design from audit proof.

One common edge case is vendor-managed AI tooling, where organisations may not control the full identity chain or logging depth. Another is prompt-injection risk, where the agent appears compliant in review but is redirected at runtime. That is why emerging guidance increasingly favours layered controls instead of paper approval alone. The Top 10 NHI Issues remains relevant because over-privilege, weak visibility, and poor rotation still show up as root causes even when governance looks mature on paper.

Related resources from NHI Mgmt Group

• How do security teams know whether AI review outputs are actually trustworthy?
• What breaks when AI assistants reason over fragmented cloud security data?
• What is MCP in the context of AI security?
• What are the security risks associated with AI agents?