Runtime controls for AI coding tools: closing the policy gap

At a glance

What this is: Fiddler says AI coding policy fails when it lives only in documents, IDE settings, or pre-merge checks, because the real exposure happens on the runtime request and response path.

Why it matters: For IAM and NHI practitioners, this shifts governance from configuration hygiene to inline enforcement over prompts, tool calls, and generated outputs that can carry secrets or sensitive data.

Context

AI coding policy is only effective when it is enforced at the point where data enters and leaves the agent. In practice, that means the control must sit on the runtime path, not in a wiki, a rules file, or a post-commit scan.

The governance gap is especially relevant where AI coding tools interact with internal tools, model gateways, and machine-readable credentials. Once prompts, tool outputs, or logs can carry secrets or personal data, the problem becomes one of runtime control and identity-aware data handling, not just developer guidance.

Key questions

Q: Where does AI coding policy fail when it is only written in documents or IDE settings?

A: It fails at the point of use. Documents and per-machine settings can guide behaviour, but they do not intercept prompts, tool calls, or model responses in real time. If a secret, customer record, or hostile instruction passes through the agent workflow before a later scan runs, the exposure has already happened and the policy was never enforced.

Q: Why do runtime guardrails matter more than post-merge scanning for AI coding tools?

A: Because post-merge scanning sees the code artifact after the sensitive material may already have left the environment. Runtime guardrails can redact or block the content before the model processes it or before the output reaches the developer, which is the only point where both inbound contamination and outbound leakage can still be stopped.

Q: What signs show that AI safety policies are not being enforced well enough?

A: Warning signs include high bypass rates, repeated jailbreak success, and a large gap between categories the model claims to recognise and the prompts it actually blocks. When custom policy rules fail under adversarial variation, the problem is enforcement depth, not policy breadth.

Q: How should teams govern AI coding tools that read files, logs, and MCP outputs automatically?

A: Treat the assistant's input surface like a controlled trust boundary. Limit which artefacts enter context, review high-risk text sources, and require human approval for changes that affect security logic, credential handling, or other sensitive control paths.

Technical breakdown

Why IDE settings and pre-merge scans miss the enforcement point

IDE controls, allowlists, and CI/CD scans are useful, but they do not sit on the path every request and response takes. That matters because AI coding assistants can consume tool output, generate code, and export traces before any later scan runs. In other words, configuration reduces exposure, but it does not make policy binding. Runtime enforcement requires a control point that can inspect inbound prompts, outbound tool calls, and model responses before the data leaves trust boundaries.

Practical implication: Put the policy control where the agent actually transacts, not where developers are asked to remember it.

Pre-LLM and post-execution guardrails solve different problems

Pre-LLM guardrails inspect inputs before they reach the model, which is where secrets, tokens, customer records, and hostile instructions can be stopped or redacted. Post-execution guardrails inspect outputs before they reach the developer or the next tool, which is where generated code, leaked PII, or unsafe responses can be intercepted. These are not interchangeable. A complete runtime policy needs both because inbound contamination and outbound leakage are separate failure modes.

Practical implication: Treat input and output inspection as separate controls, and do not assume one guardrail covers both directions.

Why an LLM and MCP gateway changes the control model

An LLM and MCP gateway is not just a network choke point. It sees the full request and response payloads, including tool traffic, which means it can make policy decisions on content rather than destination alone. That is crucial for AI coding tools because the highest-risk material often arrives through internal tools, not just direct prompts. Once the gateway applies allow, redact, or block verdicts inline, policy becomes an executable decision rather than a written preference.

Practical implication: Centralise enforcement on the gateway so tool-mediated data flows are governed consistently across users and models.

Threat narrative

Attacker objective: The objective is to move sensitive data, secrets, or hostile instructions through the coding workflow before any later control can stop the exposure.

1. Entry occurs when a developer asks an AI coding assistant to help with a task that involves sensitive application context or an internal tool call.
2. Credential or data exposure follows when the assistant receives a real record, secret, or protected field through the prompt or MCP response path.
3. Impact occurs when that sensitive material is propagated into model context, output, or trace logging and leaves the intended trust boundary.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• JetBrains GitHub plugin token exposure: A flaw in the JetBrains GitHub plugin could send IDE users' GitHub tokens to an attacker via a crafted pull request. Fixed; tokens to be revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime policy enforcement is now the real control plane for AI coding tools: once prompts, tool calls, and generated outputs are part of daily engineering work, document-based policy cannot meaningfully constrain behaviour. The control has to sit where the agent requests data and where it returns results, because that is the only place every transaction is visible. For NHI and AI governance teams, the practical conclusion is that enforcement architecture matters more than policy wording.

Inbound exposure is the blind spot most organisations still under-govern: many teams think first about data leaving the environment, but tool responses can pull sensitive records into agent context before a developer ever sees them. That creates a governance gap around machine-readable data ingestion, not just outbound exfiltration. The failure mode is especially important where MCP servers, logs, and trace exports all touch the same sensitive payload.

Policy must be executable to be auditable: an allow, redact, or block decision is stronger than a document because it creates a traceable control event at the point of use. That is where governance and observability meet, and it is also where fleet-level oversight becomes possible across first-party and third-party agents. The practitioner conclusion is clear: if you cannot evidence the runtime decision, you do not yet have enforceable policy.

AI coding governance is becoming a privilege and identity problem as much as a software problem: the agent is acting on behalf of a developer, but it is also consuming and forwarding machine-readable data through tool identities and service integrations. That means the security model must account for where trust is delegated, what the agent can see, and which services are allowed to participate in the workflow. Identity governance is now part of coding tool security, not a separate concern.

What this signals

Runtime enforcement is the governance shift that AI coding tools force on security teams: policy only becomes meaningful when it can act on the live request and response path. That change matters because coding agents increasingly sit between developers, internal tools, and external models, which means the control point must move closer to the transaction itself.

AI coding governance now intersects with identity and non-human access management: the practical question is no longer only what the developer may do, but what the agent can see, request, and propagate on the developer's behalf. That pushes teams toward tighter control of tool identities, delegated access, and shadow AI discovery.

Agent observability and policy evidence need to be one system: if verdicts are not logged alongside the prompt, tool, and model context, governance stays partially invisible. Security leaders should expect runtime controls to produce audit-ready evidence, not just safer output.

For practitioners

• Map controls to the runtime path Inventory where policy currently lives, then mark the exact points where prompts, tool calls, and responses cross trust boundaries. Any gap on that path is a gap in enforcement, no matter how strong the written policy looks.
• Separate redaction from blocking Use redaction for sensitive but non-adversarial content such as secrets or PII, and reserve blocking for hostile input such as prompt injection or exfiltration instructions. The two verdicts solve different problems and should not be merged.
• Inspect both inbound and outbound AI traffic Apply guardrails to prompts heading into the model and to tool responses coming back from the model. Inbound context is where many organisations miss exposure because the sensitive data arrives through internal tools rather than direct user input.
• Register every coding agent in a central inventory Track first-party and third-party coding agents so no workload can bypass policy by remaining unknown. Unregistered agents create shadow governance gaps that runtime enforcement cannot cover.
• Log verdicts as governance evidence Record every allow, redact, and block decision with the requesting user, tool, and model context so policy and audit trail stay linked. That turns enforcement events into evidence for oversight and investigation.

Key takeaways

• AI coding policy breaks down when it is advisory only, because the exposure happens while prompts and tool responses are moving through the agent workflow.
• The key governance gap is runtime enforcement over inbound and outbound data, especially where MCP servers and external model calls handle sensitive content.
• Inline allow, redact, and block decisions create both control and evidence, which is what turns AI coding policy into something a security team can operate.

Key terms

• 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.
• 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.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It is designed for practitioners who need to connect identity control to real operational risk across modern security programmes.