When should organisations prioritise runtime AI controls over static approvals?

Why This Matters for Security Teams

Static approvals are useful for documenting intent, but they do not govern what an AI system does once it is live. The decision point changes when a system can generate text, call APIs, transfer data, or chain actions without a person approving each step. That is where runtime AI controls become the primary safeguard, especially for agentic workflows that behave differently from traditional applications. NIST’s NIST Cyber AI Profile (IR 8596) frames this as a risk management problem, not a paperwork problem.

NHI Management Group’s research on LLMjacking shows why the distinction matters: once AI credentials or tokens are exposed, attackers can move quickly and abuse them before governance catches up. A static approval may say a workflow is allowed, yet it cannot stop a prompt injection, a compromised token, or a tool call that exfiltrates data in real time. In practice, many security teams encounter the gap only after an AI workflow has already been used to move sensitive data or trigger unauthorized tool access, rather than through intentional design.

How It Works in Practice

Prioritising runtime controls means evaluating each AI request at the moment it occurs, with the current context attached. That includes the user, the model, the task, the target system, the data classification, the tool being called, and the trust level of any upstream content. Static approvals can still exist for procurement, model onboarding, or risk acceptance, but they should not be the last gate before execution.

In mature environments, runtime controls often include policy checks, short-lived credentials, scoped tool permissions, and logging that captures each action independently. For agentic systems, the practical goal is to prevent an agent from using more privilege than the specific task requires. The emerging pattern is to pair identity and access decisions with runtime evaluation so the system can allow low-risk actions while blocking high-risk ones dynamically.

• Use Ultimate Guide to NHIs — Standards to align identity and credential handling with broader NHI governance.
• Apply policy-as-code so tool use, data movement, and external calls are checked at execution time.
• Issue short-lived credentials for specific tasks instead of relying on standing access.
• Separate approval of the workflow design from approval of each live action.

This is where standards guidance from the NIST Cyber AI Profile (IR 8596) becomes operational: controls should map to observable behaviour, not just system ownership. Runtime enforcement is especially important when the AI can access customer records, internal knowledge bases, or external SaaS tools because those pathways create immediate blast radius. These controls tend to break down when legacy applications expose broad APIs with no transaction-level policy checks because the system can only approve access, not govern each action.

Common Variations and Edge Cases

Tighter runtime control often increases latency, engineering effort, and policy maintenance, so organisations have to balance safety against operational friction. That tradeoff is real, especially when an AI system is limited to low-risk summarisation or internal drafting and does not initiate external actions. Current guidance suggests static approvals may still be reasonable for narrow, read-only use cases where the system cannot change state or access sensitive systems.

The exception is any workflow that can cross a trust boundary, chain tools, or trigger side effects. In those cases, runtime controls should take precedence even if the original use case was approved months earlier. Best practice is evolving around context-aware authorisation, where the control decision reflects the actual prompt, data, and destination at the time of use. That is particularly relevant for agentic systems, where a single approved workflow can branch into many unplanned steps.

Organisations should also be careful not to treat static approval as a substitute for revocation. If a model, connector, or agent token is compromised, the approval record offers no protection. NHI Management Group’s DeepSeek breach analysis reinforces the broader point: secret exposure and over-permissive access become immediate operational risks once autonomous execution is involved.

Related resources from NHI Mgmt Group

• When should organisations prioritise runtime guardrails over model-focused AI controls?
• How do security teams decide which controls to prioritise for AI applications?
• When should organisations use AI to help manage NHIs?
• How can organisations prevent AI agents from becoming overprivileged?