Runtime controls for AI coding tools: closing the policy gap

At a glance

What this is: This article argues that AI coding tool policy only works when enforced inline at runtime, not when left in documents, IDE settings, or post-commit scanning.

Why it matters: It matters to IAM practitioners because AI coding agents increasingly handle sensitive data and tool access, which turns runtime policy enforcement into an identity, privilege, and governance problem.

By the numbers:

• 80% admit to bypassing security policies when using AI coding tools.

👉 Read Fiddler's analysis of runtime policy enforcement for AI coding tools

Context

AI coding assistants create a governance gap when policy exists only as guidance instead of enforcement. The core problem is not whether teams can write rules, but whether those rules sit on the path where prompts, tool calls, and model responses actually move. In AI coding workflows, that path increasingly carries secrets, customer data, and untrusted model output.

The identity angle is real because coding agents and MCP-connected tools act on behalf of users, pull data from systems, and can propagate that data into external services or logs. For IAM and PAM teams, the control question is no longer only who can access a resource, but what an agent is allowed to send, receive, and forward at runtime. That starting position is becoming common, not exceptional.

Key questions

Q: How should security teams enforce AI acceptable use policies at runtime?

A: Security teams should pair the written policy with discovery, intent-based controls, and audit logging. The policy defines what is allowed, but runtime enforcement decides whether a prompt is warned, blocked, routed, or recorded. Without that layer, employees can bypass the document through normal work patterns, and the organisation cannot prove what happened during an AI interaction.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

Q: What breaks when security controls sit only in IDE settings or rules files?

A: Coverage drifts across machines, users can bypass local settings, and the control never sees tool responses that bring sensitive data back into context. The result is advisory policy with no enforcement. Teams get a false sense of coverage while prompts, secrets, and PII still move through the agent path.

Q: Who should own accountability for AI data access risk?

A: Accountability should sit with the teams that own identity, data governance, and security operations together. If AI can access enterprise data, then ownership must cover entitlement design, monitoring, and incident response across the full workflow. The governance gap is not just technical, because without a named owner, no one can prove who approved or contained the access.

Technical breakdown

Why IDE settings and rules files fail to enforce policy

IDE settings, content exclusions, and repo rules can shape behaviour, but they do not enforce it at the moment a prompt or tool call is executed. They are local, configurable, and easy to drift across machines. Once a developer bypasses a setting or the agent pulls data through an MCP tool, the policy document is already out of the loop. Pre-merge scanning catches artefacts in code, but it cannot intercept a prompt that already exposed a secret or customer record. Enforcement needs to sit where the request is made and the response is returned.

Practical implication: Move control points off the workstation and onto the runtime path where every AI coding request and response can be inspected.

How pre-LLM and post-execution guardrails split control

Pre-LLM guardrails examine inputs before they reach the model, which makes them suitable for redacting secrets, PII, or PHI in prompts and tool payloads. Post-execution guardrails inspect outputs before those outputs reach the developer or another tool, which is how hardcoded credentials or unsafe responses are caught. The distinction matters because outbound and inbound risks are different. A complete policy needs both directions covered, especially when tool responses can introduce sensitive data into agent context without the user explicitly typing it.

Practical implication: Deploy separate guardrails for input and output paths so redaction and blocking match the direction of risk.

Why MCP traffic changes the control model for coding agents

MCP expands the trust boundary because the agent is no longer only generating text. It is calling tools, requesting records, and receiving data that may never have belonged in model context. That means security controls need to inspect not just prompts and completions, but also tool responses that can inject sensitive information into the workflow. This is where outbound-only data loss prevention fails. If the guardrail does not see the MCP exchange, it cannot govern the identity and data flow that the agent is actually using.

Practical implication: Treat MCP servers and tool endpoints as governed access paths, not just integration plumbing.

NHI Mgmt Group analysis

Runtime enforcement is now the minimum viable control for AI coding tools. Policy written in a wiki does not govern behaviour when the agent is already moving data through prompts and tools. The security model has shifted from documentation to execution, and the execution point is the gateway path that sees every request and response. Teams that keep relying on advisory controls are describing desired behaviour, not enforcing it.

The biggest blind spot is inbound context, not just outbound leakage. Most organisations still think of AI coding risk as secrets leaving the environment, but tool responses can pull PII and PHI into agent context before any human review happens. That creates a data governance problem as much as a software risk problem. In identity terms, the agent is acting inside a delegated trust chain, so the control question becomes what it may ingest, not only what it may exfiltrate.

Policy and telemetry become the same system when guardrails are inline. Once allow, redact, and block decisions are enforced at runtime, every verdict becomes evidence of what the agent tried to do. That gives governance teams a fleet-level view of agent behaviour, drift, and policy exceptions instead of isolated machine settings. This is where NIST-CSF and OWASP-NHI-style thinking intersect: access, data handling, and accountability need to be observable at execution time.

Runtime policy gap: the failure mode is not absence of rules, but absence of enforcement at the request path. That gap explains why static controls keep missing sensitive prompts, tool responses, and prompt injection attempts. The practitioner takeaway is to treat enforcement location as the control, because misplaced controls are functionally equivalent to no control at all.

AI coding governance will increasingly look like identity governance for machine actors. As coding agents gain reach into repositories, tools, and external services, they behave like governed non-human actors with scoped permissions and auditable actions. That makes the bridge to NHI governance unavoidable. Practitioners should expect policy, telemetry, and access boundaries to converge around agent identity and runtime privilege.

What this signals

Runtime enforcement is likely to become the baseline expectation for AI coding governance as developers continue to adopt assistants that can call tools, read context, and write outputs across multiple systems. The control model will shift from desktop configuration to centrally governed execution, with policy events becoming part of security telemetry rather than a separate audit process.

The deeper programme signal is that AI coding tools need to be managed as machine actors with scoped access, observability, and offboarding requirements. That makes the boundary between IAM, NHI governance, and secure development operations much thinner than many programmes assume.

For practitioners

• Map control placement across the full AI coding path Inventory where policy currently sits across IDE settings, rules files, gateway controls, and CI/CD scanning, then identify every place nothing inspects prompts or responses in real time.
• Enforce redaction on inbound and outbound sensitive data Apply pre-LLM and post-execution guardrails so secrets, customer records, and protected data are stripped before they reach the model or leave it in logs, traces, or code output.
• Reserve blocking for hostile requests only Use block verdicts for prompt injection or obviously malicious instructions, while redaction handles accidental exposure without breaking the developer workflow.
• Register all coding agents in a governance inventory Track third-party and internally built agents as governed workloads so unregistered tools cannot escape policy enforcement or telemetry collection.
• Roll runtime verdicts into fleet governance reporting Use inline enforcement events to measure redaction frequency, blocked requests, and policy drift across the developer estate, then feed those signals into security and risk reporting.

Key takeaways

• AI coding policy fails when it is written as guidance instead of enforced inline at the runtime path.
• Inbound context from tool responses is as risky as outbound leakage from prompts, and often harder to see.
• Security teams should govern coding agents as machine actors with runtime controls, auditability, and scoped access.

Key terms

• Pre-llm guardrail: A pre-LLM guardrail inspects prompts and tool payloads before they reach the model. It is used to redact or block sensitive content early enough to prevent data exposure, hostile instructions, or unsafe context from entering the generation flow.
• Post-execution guardrail: A post-execution guardrail reviews model outputs and tool responses before they are returned to a user or forwarded to another system. It catches unsafe code, leaked secrets, and sensitive data that the agent may have received or generated during execution.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.

What's in the full article

Fiddler's full blog covers the operational detail this post intentionally leaves for the source:

• The exact three-layer enforcement model for AI coding tools, including where gateway control sits relative to IDE settings and CI/CD.
• Concrete examples of allow, redact, and block verdicts applied to secrets, prompt injection, and sensitive tool responses.
• How Fiddler describes inline policy telemetry and governance roll-up across developer fleets.
• The implementation distinctions between pre-LLM guardrails and post-execution guardrails in runtime workflows.

👉 Fiddler's full post covers the inline guardrail model, enforcement examples, and fleet governance implications.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to runtime risk in modern automation and AI-enabled environments.