What do security teams get wrong about runtime policy for agents?

Why This Matters for Security Teams

Runtime policy is attractive because it promises immediate guardrails for agents that can call tools, chain actions, and adapt on the fly. The mistake is assuming that blocking a bad request at the point of execution is equivalent to governing the identity behind the agent. It is not. Runtime policy can stop one unsafe action, but it will not expose shadow NHIs, retire stale secrets, or correct ownership gaps across the estate.

That gap matters because agentic systems are not behaving like traditional user accounts. Their access is often task-driven, ephemeral, and context-sensitive, which makes static access reviews and role assumptions fragile. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework points toward runtime controls, but both also imply the need for governance around identity, context, and accountability.

NHIMG research shows why this matters operationally: in The Ultimate Guide to NHIs, 96% of organisations store secrets outside secrets managers in vulnerable locations. In practice, many security teams encounter agent abuse only after a tool chain has already been misused, rather than through intentional lifecycle control.

How It Works in Practice

For agents, runtime policy should be treated as one enforcement point inside a broader control plane, not the control plane itself. The core question is what the agent is allowed to do right now, in this context, with this identity, for this task. That means policy decisions should be evaluated at request time using task intent, data sensitivity, trust posture, and tool scope, rather than relying only on pre-defined roles.

In mature environments, that usually means combining policy-as-code with workload identity and ephemeral credentials. A workload identity establishes cryptographic proof of what the agent is, while just-in-time secrets or tokens limit how long the agent can act. This is where guidance from CSA MAESTRO agentic AI threat modeling framework and the OWASP Top 10 for Agentic Applications 2026 becomes practical: both emphasise threat modelling, constrained tool use, and explicit control over agent behaviour.

• Use runtime policy to approve or deny each tool call based on current task context.
• Issue short-lived credentials per task, not long-lived static tokens that outlive the job.
• Bind agent permissions to a workload identity, not to a human-style role assumption.
• Log policy decisions, denied actions, and tool chaining for later investigation.
• Revoke access automatically when the task completes or the agent’s state changes.

NHIMG’s OWASP NHI Top 10 also reinforces that runtime checks are only effective when paired with inventory, lifecycle ownership, and secret hygiene. These controls tend to break down when agents are allowed to spawn sub-agents, reuse cached tokens, or invoke external tools through indirect integrations because the policy engine loses visibility into the true execution path.

Common Variations and Edge Cases

Tighter runtime control often increases latency, policy complexity, and operational overhead, so organisations have to balance containment against developer friction and service reliability. There is no universal standard for agent authorisation yet, and current guidance suggests the right pattern depends on how autonomous the system is and how much damage a single tool call could create.

One common edge case is the semi-autonomous agent that operates under human approval but still holds standing credentials. In that model, runtime policy may stop obvious abuse, but it does not solve over-privilege or stale access. Another is multi-agent orchestration, where a supervisor agent delegates to specialist agents. A denial at the edge may be meaningless if downstream agents inherit broader permissions through shared service accounts or opaque middleware.

Security teams should also be careful not to confuse observability with governance. Telemetry helps detect misuse, but it does not prevent it, and post-event review does not replace least privilege. The best practice is evolving toward layered controls: workload identity, just-in-time access, real-time policy evaluation, and estate-wide NHI governance working together. That is the difference between blocking a bad request and actually reducing the blast radius of an autonomous system.

In highly regulated or air-gapped environments, these approaches can break down when policy engines cannot reach the context they need, or when legacy applications cannot support short-lived tokens and dynamic trust decisions.

Related resources from NHI Mgmt Group

• What do security teams get wrong about argument filtering in MCP gateways?
• What do security teams get wrong about prompt engineering for AI agents?
• What do security teams get wrong about AI runtime protection?
• What do security teams get wrong about prompt filtering for AI agents?