Approvals describe intent, but runtime controls decide what the model can actually see and reveal in a live session. That matters because prompts, retrieval, tools, and outputs can all expose data differently. The practical test is whether the control blocks, redacts, or logs the event at the moment the AI acts.
Why runtime controls are the real test of AI data risk
Approvals are useful for governance, but they are not the control plane that governs a live interaction. Once a model starts handling prompts, retrieval, tools, and generated output, the security question changes from “was this allowed?” to “what was actually exposed, transformed, or retained in the session?” Runtime controls answer that question in the moment.
That distinction matters because AI data risk is dynamic. A safe-looking approval does not stop a prompt from carrying sensitive context, a retriever from surfacing the wrong record, or an output channel from disclosing information in a way the approver never intended. Runtime controls are where the policy becomes observable behaviour.
For practitioners, the core issue is control timing. Approvals are upstream and often coarse, while the material exposure happens downstream, inside the live workflow. The stronger the dependency on retrieval, tool calls, or automated responses, the more important it becomes to control what can be read, written, redacted, and logged at execution time.
What runtime controls need to do that approvals cannot
Runtime controls work because they can inspect the actual event, not just the intended use case. They can block a prompt that contains sensitive material, redact fields before the model sees them, constrain which sources retrieval can touch, and prevent an output from echoing data back to the user. That is fundamentally different from approving a project or use case on paper.
The practical controls are usually boundary controls: allowlists, deny rules, content filtering, retrieval scoping, tool permissioning, response filtering, and audit logging. Each one reduces a different exposure path. If any of those are missing, the approved use case may still leak data through a path the approver never reviewed in detail.
Runtime controls also matter because AI systems behave differently across turns. A request that is safe at the start of a session can become unsafe after context accumulates, a tool is invoked, or a retrieved document is added. That is why “approved” is not the same as “continuously safe.”
How to judge whether a control is strong enough
The right test is whether the control changes the live outcome. If it only documents intent, it is governance. If it changes what the model can see, retrieve, send, or store during execution, it is a security control. In AI data risk work, those are not interchangeable.
Runtime controls are strongest when they are specific to the exposure path. For example, redaction is only useful if it happens before sensitive text enters the model context. Logging is only useful if it records the blocked event, the source, the trigger, and the decision in a form that supports investigation. Tool restrictions are only useful if they are enforced per action, not merely declared in policy.
Threat Modelling AI Agents is useful here because it forces teams to trace the actual trust boundaries, data flows, and action paths where runtime exposure appears. That is the right mindset for distinguishing policy intent from enforced control.
Risk and Threat Considerations
When teams rely on approvals instead of runtime enforcement, the main risk is false confidence. Sensitive information can still enter prompts, be retrieved from connected systems, or be emitted in outputs even though the use case was “approved” on paper. That creates disclosure, retention, and auditability gaps that only become visible after the session has already done the damage.
Failure mechanism: The control fails when the decision is made too early, too broadly, or without session-level enforcement, so the live interaction can still access data that the approval never truly governed.
Impact: The result can be unauthorized disclosure, overcollection, weak incident reconstruction, and a control story that looks sound in review but does not protect the actual transaction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Govern | AI data risk needs governance that measures and enforces live controls. |
| Recommendation — Define runtime control expectations for AI data exposure and verify they operate in production. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Runtime controls need evidence of blocked, redacted, and accessed events. |
| AC-6 — Least Privilege | Runtime data exposure depends on restricting what the AI can access in session. | |
| Recommendation — Log prompt, retrieval, tool, and output decisions at the point of execution. Restrict each model and tool path to the minimum data and action scope. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | AI tools and actions can expose data when function-level checks are missing. |
| Recommendation — Enforce per-action authorization on every AI tool and data-access operation. | ||
| ISO/IEC 27001:2022 | A.8.12 — Data leakage prevention | The question centres on preventing live disclosure rather than approving intent. |
| Recommendation — Apply leakage prevention controls to prompts, retrieval results, and outputs. | ||
Practitioner Guidance
What to prioritise: Put enforcement on the live path for prompts, retrieval, tools, and outputs before you rely on approvals as evidence of control. If the system can still see the data, the approval has not reduced the risk.
What to verify: Test the exact moment where sensitive data is blocked, redacted, or logged. A control that works in design review but cannot prove enforcement during a real session is not enough for data-risk decisions.
Common mistake: Treating a use-case approval as if it were a data-loss control. Approval may define acceptable intent, but runtime controls determine whether the model can actually expose data when it operates.
Practitioner takeaway: For AI data risk, the question is not whether the use case was approved, but whether the live system can prevent or record exposure at the point of action.
Related resources from NHI Mgmt Group
- Why do GenAI runtime controls matter for data leakage and prompt injection risk?
- Why do runtime data sources matter as much as model weights in AI security?
- When should organisations prioritise runtime AI controls over static approvals?
- Which controls matter most when AI tools touch privileged data?