If an agent can call multiple tools, retain memory, reach external systems or continue acting after the initial approval point, design review alone is insufficient. Those are signs that the real control point is execution time, where policy must constrain each action as it happens.
Why runtime guardrails become the real control point
The clearest sign is that the agent’s risk comes from what it can do after approval, not from how it was described during review. If it can chain tools, hold state, call external systems, or keep acting across multiple steps, the dangerous part is execution time. That is where you need policy enforcement, not just a one-time design verdict.
Design review is still useful for architecture choices, but it stops being sufficient once the agent can branch, persist, or re-plan. At that point, the relevant question is whether every action is constrained as it happens, with the current context, current principal, and current policy. A static review cannot reliably predict the full path of a live agent.
This is especially true when the agent has access to tools that change the environment, not just report on it. A read-only summariser can often be handled with pre-launch review. An agent that can send messages, move tickets, modify records, trigger workflows, or invoke external APIs needs runtime checks because each action can enlarge blast radius in ways the original design never fully captures.
What runtime behaviour tells you the review boundary has been crossed
The most practical indicator is whether the agent can continue making consequential decisions after the approval point. If it retains memory, receives fresh inputs, or takes multiple turns to complete a task, the system is no longer a fixed request-response flow. That makes the live policy decision more important than the initial approval narrative.
Another sign is that the agent’s permissions are broader than any single task needs. When standing access, long-lived tokens, or unrestricted connector scope let the agent reuse authority across contexts, the control problem shifts from “was this design acceptable?” to “is this specific action authorised right now?” That is the difference between upfront governance and action-level control, and it is central to AI Agent Authorisation Guide.
Execution-time controls also become necessary when the agent’s behaviour depends on live data, memory state, or tool output that could not be fully validated in review. In those cases, the safer pattern is to verify the request, the tool, and the target together at runtime, rather than trusting the original design intent to stay valid throughout the session.
Where practitioners should draw the line
If an agent can only propose actions, design review may be enough. If it can perform actions, the deciding factor is whether each action is bounded, observable, and interruptible. That is why runtime guardrails matter more for agents that can act across tools, sessions, or systems, which is the operating model discussed in Zero Trust for AI Agents.
In practice, the line moves from review to runtime control when you see any of these conditions: the agent can escalate from one tool to another, reuse access without re-checking intent, act on behalf of a user after the original request has ended, or reach systems whose state changes have real business impact. That is also why tool scope, action scoping, and step-by-step enforcement matter in the Agentic AI Security Guide.
Teams often overestimate what review can prove. Review can tell you the design is plausible; it cannot guarantee the agent will stay inside intended boundaries when prompted, retried, looped, or partially failed. Runtime guardrails are the mechanism that keeps the agent safe when the live environment diverges from the approved plan.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Runtime guardrails must constrain agent privileges at execution time. |
| ASI02 — Tool Misuse | Multi-tool agents need live limits on what each tool call can do. | |
| ASI10 — Rogue Agents | Agents that keep acting after approval need containment and stop conditions. | |
| Recommendation — Enforce per-action authorization to prevent privilege abuse by agents. Gate every tool invocation with policy and context checks. Add kill switches and containment for out-of-policy agent behaviour. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Runtime guardrails enforce least privilege at the moment of action. |
| IA-5 — Authenticator Management | Long-lived credentials and reusable access increase the need for live controls. | |
| Recommendation — Limit each agent action to the minimum required access. Shorten credential lifetime and rotate secrets that power agent actions. | ||
| NIST Zero Trust (SP 800-207) | SI-4 — System Monitoring | Runtime guardrails depend on seeing agent actions as they occur. |
| Recommendation — Monitor agent actions continuously and alert on policy violations. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Per-action policy enforcement is an access-control problem at runtime. |
| Recommendation — Apply access control at each agent action, not only at design review. | ||
| OWASP ASVS | V8 — Authorization | Agents that act on tools or systems need explicit authorization checks per action. |
| Recommendation — Verify each action is authorized before the agent executes it. | ||
Practitioner Guidance
What to prioritise: Treat runtime controls as mandatory once the agent can take more than one action, retain context, or reach anything beyond a single contained system. Those are the conditions where pre-approval loses most of its protective value.
What to verify: Confirm that the agent’s policy decision happens per action, not just per session. If access is broad, persistent, or reusable, verify that there is a live enforcement point before any tool call that can change state or expose data.
Decision rule: If the question is “Was this agent designed well?”, use review. If the question is “Can this agent safely act right now?”, require runtime guardrails, because the risk has shifted from architecture quality to execution control.
Practitioner takeaway: The more an agent can act independently after approval, the less design review can protect you on its own; safety then depends on action-by-action control, not just good intent at design time.