Because many AI risks emerge only after the system starts acting on real data, tools, and prompts. Pre-deployment review can validate design intent, but runtime controls determine whether the system stays constrained when conditions change. That is where abuse, drift, and unsafe delegation usually appear.
Why runtime controls matter more than pre-deployment review
Pre-deployment review is necessary, but it only proves that the design looked acceptable at one point in time. Runtime controls answer the harder question: did the system stay within policy when it encountered live prompts, changing context, external tools, new data, or unexpected user behaviour?
The distinction matters because many AI failures are not static coding defects. They are emergent behaviours: the model sees fresh inputs, reaches for tools, inherits permissions, or is steered into actions that were not obvious in a lab review. Runtime controls are what keep those decisions bounded when reality diverges from test conditions.
That is why runtime oversight usually includes input filtering, tool and action approval, output constraints, rate limiting, audit logging, and emergency shutdown paths. Without those controls, a system can be “safe on paper” while still being able to leak data, invoke sensitive workflows, or execute unintended actions once deployed.
What changes once the AI system is acting live
At runtime, the security problem shifts from “was the system built correctly?” to “is the system behaving safely right now?” Live operation introduces new trust boundaries, including real users, production data, upstream services, and downstream tools. Each of those can change the risk profile even if the pre-deployment review was thorough.
Runtime controls also matter because AI systems can be manipulated after deployment. Prompt injection, jailbreak attempts, indirect instruction poisoning, and tool misuse are all runtime phenomena. A pre-launch assessment may identify the possibility of abuse, but only runtime enforcement can decide whether the system is allowed to comply, escalate, or ignore a suspicious instruction.
This is where the operational design of the AI programme becomes visible. If the system can act, call APIs, or access sensitive context, the programme needs guardrails around delegation, not just documentation around model approval. A practical agent policy should define who owns the agent, what it may do, and when it must stop or ask for human review.
What runtime controls must actually constrain
Good runtime controls do not try to eliminate every model error. They reduce blast radius by constraining the parts of the system that can cause harm: prompts, context, tools, secrets, and authority. That usually means separating low-risk inference from high-risk action, and making sensitive actions require stronger checks than ordinary responses.
For agentic or tool-using systems, the most important runtime controls are those that govern authorization in the moment of action. If an agent can read a ticket, send an email, create a record, or trigger a workflow, the programme must decide whether each action is permitted under current conditions. AI agent identity controls are relevant here because the identity, permission set, and session boundary determine what the system can do once deployed.
Runtime controls should also be able to distinguish between normal variation and unsafe drift. A model that starts producing longer chains of tool calls, wider data access, or higher-impact outputs may still be “functioning,” but not safely. AI security platforms are often evaluated on whether they can monitor and block those live behaviours, not just whether they can score a model before release.
Risk and Threat Considerations
AI systems become materially riskier after deployment because the attack surface expands from a controlled test path to real inputs, real privileges, and real business data. The main danger is not only model failure, but unsafe delegation: a compromised prompt, connector, or tool path can turn a routine interaction into data exposure or unauthorised action.
Failure mechanism: Static review misses runtime abuse paths such as prompt injection, context poisoning, overbroad tool access, and secret leakage from live environments. When the system is allowed to act without ongoing constraint, an attacker or careless user can steer it into decisions that were never exercised during pre-launch testing.
Impact: The consequence can be confidentiality loss, unauthorised workflow execution, production misuse, or a wider blast radius if the AI is connected to sensitive systems. In agentic settings, the risk compounds because one unsafe action can cascade into several downstream actions before anyone notices.
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 surface, NIST AI RMF and NIST AI 600-1 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Runtime controls must limit agent authority at the moment of action. |
| ASI02 — Tool Misuse | The question centers on live control of tool calls and delegated actions. | |
| Recommendation — Constrain agent permissions and require runtime checks before sensitive actions execute. Gate tool use with policy checks, allowlists, and human approval for high-risk operations. | ||
| NIST AI RMF | GV.1 — Govern, map, and measure AI risks | The answer compares pre-deployment review with ongoing runtime governance. |
| Recommendation — Define runtime monitoring and escalation criteria as part of AI risk governance. | ||
| NIST AI 600-1 | MA.2 — Map and measure GenAI risks | The subject is how risks emerge after deployment and need live controls. |
| Recommendation — Measure deployed-system behavior and update controls when runtime risk changes. | ||
| ISO/IEC 42001:2023 | 8.2 — AI risk treatment | The question is about moving from review to operational AI risk controls. |
| Recommendation — Implement operational controls that keep AI risks within accepted limits after deployment. | ||
Practitioner Guidance
What to prioritise: Put runtime controls around the highest-impact actions first, especially tool invocation, data retrieval, outbound communication, and any step that can change state outside the model. Pre-deployment review should inform those controls, not replace them.
What to verify: Confirm that live enforcement exists for the same paths your review approved, including logging, authorization, and stop conditions. If a reviewer cannot point to the runtime gate that would block an unsafe action, the control is not yet operationally real.
Decision rule: If the AI can influence external systems or access sensitive context, require runtime policy enforcement and monitoring before broad rollout. If it only generates low-stakes text, lighter controls may be acceptable, but only if the deployment cannot silently gain new privileges later.
Practitioner takeaway: Pre-deployment review tells you whether the design was reasonable; runtime controls tell you whether the deployed system is still safe when reality, users, and tools start pushing back.
Related resources from NHI Mgmt Group
- Where do AI security controls fail in practice when teams rely on post deployment review instead of shift left testing?
- How should security teams govern cloud AI agents at runtime instead of relying only on pre-deployment reviews?
- How do security teams balance pre-deployment testing and runtime validation for AI systems?
- What is the difference between pre-deployment testing and runtime security for AI agents?