Why do AI governance programmes need both policy and runtime controls?

Why This Matters for Security Teams

AI governance programmes fail when policy is treated as the control and not the instruction set. Policies can say what should happen, but they do not stop an agent, model workflow, or integration from taking an unsafe action at execution time. That gap matters because AI systems operate across prompts, tools, data pipelines, and service accounts, where the real risk is not intent but enforcement.

For security and IAM teams, the key question is whether a sensitive action is checked where it happens. A governance statement without runtime denial, step-up approval, secret scoping, or logging is only documentation. This is why current guidance increasingly ties policy to telemetry and enforcement, as reflected in the NIST AI Risk Management Framework and NHIMG guidance such as Ultimate Guide to NHIs - Regulatory and Audit Perspectives.

The operational stakes are visible in NHIMG research: the 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect they have experienced an NHI breach. In practice, many security teams encounter policy drift only after a model or agent has already exercised a permission that nobody expected.

How It Works in Practice

Effective AI governance uses policy to define acceptable behaviour and runtime controls to enforce that behaviour at the point of decision. Policy is where teams express intent: which data can be used, which tools can be called, which actions require approval, and which outputs must be blocked. Runtime controls are where those rules become real through token scoping, allowlists, policy-as-code checks, approval workflows, content filters, data-loss protections, and immutable logs.

In mature environments, runtime enforcement is tied to the workload itself, not just the user behind it. That means the agent or AI service has a workload identity, short-lived credentials, and a policy decision made in context. The model may be allowed to draft a payment instruction, for example, but the runtime layer can require a separate approval before any funds move. This is consistent with the direction of NIST AI 600-1 Generative AI Profile and the NHIMG Lifecycle Processes for Managing NHIs guidance.

• Use policy to declare allowed actions, prohibited data classes, and escalation thresholds.
• Use runtime controls to validate each request against current context, not just preapproved roles.
• Issue short-lived secrets or tokens per task instead of relying on static credentials.
• Log the decision, the actor, the tool, and the data path so audit can reconstruct what happened.
• Revoke or narrow access automatically when the task ends or context changes.

Where this becomes especially important is with autonomous or semi-autonomous agents that can chain tools and adapt mid-task. Static IAM roles and one-time policy reviews cannot keep pace with changing prompts, retrieval results, or external tool responses. These controls tend to break down when agents are granted broad API access in loosely segmented environments because the runtime layer cannot distinguish benign delegation from unsafe escalation quickly enough.

Common Variations and Edge Cases

Tighter runtime control often increases latency, integration complexity, and exception handling, so organisations must balance stronger enforcement against operational friction. There is no universal standard for how much runtime policy belongs in the model gateway versus the application layer versus the identity layer, and current guidance suggests choosing the enforcement point that can actually deny, log, and revoke.

Some teams over-rotate on model filters while leaving tool permissions broad, which creates a false sense of safety. Others put everything into IAM roles, which works poorly when the same agent makes different decisions across different tasks. Best practice is evolving toward layered controls: policy for intent, runtime for enforcement, and audit for proof. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs - Standards both reinforce that governance only holds when controls survive real execution paths.

In regulated or high-trust environments, runtime controls also need an owner, a testable policy, and evidence that exceptions are reviewed. The practical edge case is vendor-managed AI features embedded inside existing SaaS tools, where the control boundary is less visible and runtime enforcement may be limited to what the provider exposes.

Related resources from NHI Mgmt Group

• What is the difference between attribute-based policy and role-based policy in AI governance?
• Why do AI agents make non-human identity governance harder?
• What is the difference between human identity governance and AI agent governance?
• Why do AI agents increase non-human identity risk in existing IAM programmes?