Topic starter
18/08/2026 2:55 pm
TL;DR: Static policy documents and pre-merge scans do not stop AI coding tools from moving secrets, PII, or hostile instructions through prompts and tool calls, according to Fiddler. The enforcement point that matters is the runtime request and response path, where allow, redact, and block verdicts can finally turn policy into control.
Editorial analysis by NHI Mgmt Group, based on content published by Fiddler: “AI Coding Tool Security Policies: Enforcing Controls for Cursor and Copilot at Runtime”.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Inspect both inbound and outbound AI traffic Apply guardrails to prompts heading into the model and to tool responses coming back from the model.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:38 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime controls for AI coding tools: closing the policy gap