Cursor and AI coding tools expose the runtime governance gap

At a glance

What this is: This is a governance analysis of why Cursor and similar AI coding tools ignore prompt rules and generate insecure outputs when context changes.

Why it matters: It matters because IAM, DevSecOps, and security teams need enforceable controls for AI-assisted code generation, not advisory prompts that can be overridden by context or model behaviour.

By the numbers:

• Over 70% identified regulatory compliance and governance as one of their top three challenges when deploying GenAI productivity assistants.
• Only 23% of respondents reported being very confident in their organization’s ability to manage security and governance components for GenAI deployments.
• 45% of AI-generated code introduces security flaws, even when developers aim to enforce standards.

👉 Read Knostic's analysis of Cursor rule erosion and AI coding governance

Context

Cursor and similar AI coding tools create a governance problem because they generate plausible code, but they do not enforce enterprise policy deterministically. In practice, prompt instructions behave like preferences, not access controls, and later context can override earlier rules without the user realising it. That makes this an AI coding governance issue, not just a prompt quality issue.

The larger identity concern is that these tools act inside development workflows with access to code, secrets, repositories, and sometimes file systems or dependency installation paths. Once an AI coding assistant can modify code or execute tool calls, security teams have to treat it as a governed runtime actor, even if it is not autonomous in the strict agentic sense. External enforcement becomes the control boundary, not the prompt itself.

Key questions

Q: How should security teams govern AI coding assistants that can write code and install dependencies?

A: Security teams should govern them as controlled development runtimes, not as trusted helpers. Put policy enforcement outside the model, block disallowed output before commit or execution, and tie permissions to repository, role, and environment. Prompt instructions alone are not enough because they can be overridden by later context and cannot enforce hard boundaries.

Q: Why do prompt rules fail in long AI coding sessions?

A: Prompt rules fail because the model does not preserve a fixed hierarchy of instructions across a long context window. As new text arrives, earlier constraints lose priority, so important requirements can be displaced without warning. That makes session length, prompt order, and context clutter governance variables, not just usability details.

Q: What breaks when AI-generated code is reviewed only after it is written?

A: Late review misses the point at which unsafe code becomes a real governance event. If the assistant can emit secrets, insecure defaults, or banned dependencies before review, the organisation is already relying on remediation rather than prevention. Effective controls must intercept output before it reaches the codebase.

Q: Who is accountable when an AI coding tool introduces insecure code into production?

A: Accountability stays with the organisation that allowed the tool to operate without enforced guardrails. The model is not the accountable party. Security, engineering, and platform owners share responsibility for defining policy, enforcing it at runtime, and logging the decision trail that proves controls were applied.

Technical breakdown

Why prompt instructions decay in long AI coding sessions

Cursor and similar tools rely on token-based context windows, so instruction priority is not stable over time. Earlier constraints compete with later prompts, nearby text, and the model’s internal preference for plausible continuation. That creates context erosion: security rules can be present, acknowledged, and still ignored when the session becomes crowded or ambiguous. This is not an access-control failure because no access-control layer exists in the model path. It is a design property of generative systems that optimise for output quality, not policy compliance.

Practical implication: Treat prompt rules as advisory only and move enforcement into a separate runtime control point.

Why a language model is not a policy engine

A policy engine must deterministically allow, block, or transform actions based on predefined rules. A language model does none of those things consistently. It can imitate compliance language, but it cannot guarantee that the next generated line will obey a requirement such as no secrets, approved dependencies only, or mandatory sanitisation. That distinction matters because enterprise policy is binary, while model output is probabilistic. In governance terms, the model may understand the policy in a linguistic sense, but it does not enforce policy as a control system.

Practical implication: Define allowed and disallowed behaviours outside the model and evaluate outputs before commit or execution.

How runtime tool access turns coding assistants into governed runtimes

When a coding assistant can touch the file system, install dependencies, or trigger refactors, the risk shifts from text generation to action execution. Even without full autonomy, tool calling expands the attack surface because unsafe outputs can become live changes immediately. In MCP-style or browser-integrated workflows, that execution path can be influenced outside the original user intent. The governance question is therefore not whether the model is smart enough, but whether its actions are constrained, observed, and reversible before they reach production assets.

Practical implication: Apply approval gates, logging, and environment-aware restrictions around every action the assistant can trigger.

Threat narrative

Attacker objective: The objective is to smuggle insecure code, unsafe dependencies, or hidden data exposure into trusted development workflows without deterministic enforcement.

1. Entry occurs when developers use AI coding tools in trusted repositories, IDEs, or browser-integrated workflows that can accept hidden or conflicting instructions.
2. Escalation occurs when context erosion or tool access causes the assistant to generate insecure code, unsafe dependencies, or changes that bypass normal review expectations.
3. Impact occurs when those outputs enter shared codebases, creating downstream exposure, compliance failures, and supply chain risk in production systems.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Contextual prompting is not a control model: Prompt-based rule setting fails because it assumes stable instruction hierarchy inside a probabilistic system. In AI coding workflows, the model can accept a rule at one moment and override it later when context changes. Practitioners should stop treating prompt order as governance and treat it as a weak input signal.

Runtime enforcement, not developer intent, is the real boundary: The vendor’s core limitation is structural. If a tool can generate code, install packages, or modify files, then policy must be enforced after generation and before execution. Security teams should recognise that the control point has moved out of the prompt and into the runtime path.

AI coding assistants create identity-adjacent risk even when they are not autonomous: These tools are not autonomous agents in the strict sense, but they still operate on behalf of users inside privileged development environments. That means their actions can inherit repository trust, credential access, and deployment influence without matching human accountability. Governance teams must classify them as risky non-human participants in the delivery chain.

Policy erosion in long sessions is a governance gap, not a usability quirk: The rule that breaks is the assumption that earlier security instructions remain durable for the full interaction. That assumption fails when the system re-ranks context dynamically and later text displaces earlier policy. The implication is that teams must rethink whether session-based guidance can ever substitute for enforced controls.

Prompt obedience debt: Security programmes that rely on users remembering to restate critical rules accumulate invisible risk over time. Each new interaction increases the chance that a policy will be omitted, weakened, or overwritten. Practitioners should treat this as a governance debt problem, not a training problem.

From our research:

• Only 23% of respondents reported being very confident in their organization’s ability to manage security and governance components for GenAI deployments, according to The State of Secrets in AppSec.
• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%.
• For a broader identity lens, see Guide to the Secret Sprawl Challenge for the operational patterns that make prompt-driven governance fail in practice.

What this signals

Prompt-based governance will not scale into production development environments. As AI coding assistants become embedded in repos, IDEs, and CI/CD paths, the control model has to move from guidance to enforcement. Teams that still rely on users restating policies session by session will continue to accumulate invisible exception risk.

The governance boundary is increasingly about where policy is enforced, not whether a model can follow instructions. External controls, logging, and environment-aware restrictions need to sit beside AI coding tools the same way IAM and PAM sit beside human operators. The same logic applies wherever non-human actors can alter production outcomes.

Prompt obedience debt: Every time a team depends on context memory to preserve security rules, it adds a new layer of governance fragility. The operational question is whether your controls can still block unsafe code when the assistant, the prompt, or the session state changes unexpectedly.

For practitioners

• Move policy enforcement outside the model Use a separate control layer that can block, redact, or transform AI-generated code before it reaches the repository or runtime.
• Define explicit allow and deny rules for coding assistants Write policies for libraries, authentication patterns, sanitisation requirements, secrets handling, and licensing constraints in enforceable terms.
• Log every generation decision with policy context Capture the repository, role, policy checked, and allow or block outcome so security and compliance teams can explain each decision later.
• Restrict tool access by environment and role Limit file system changes, dependency installation, and browser-linked actions in production or regulated repositories, and require tighter controls for higher-risk environments.

Key takeaways

• AI coding assistants create governance risk because they generate plausible code without deterministic policy enforcement.
• Context erosion turns prompt rules into soft guidance, which is too weak for secrets, dependencies, and compliance constraints.
• The fix is external runtime control, with logging and environment-aware policy applied before code reaches the repository or execution path.

Key terms

• Prompt Erosion: Prompt erosion is the gradual weakening of earlier instructions as more context is added to an AI session. In coding tools, it means security and compliance rules can be displaced by newer text, making prompt order an unreliable control mechanism for enterprise governance.
• Runtime Enforcement: Runtime enforcement is the practice of checking, blocking, or transforming an action after it is generated but before it is executed. For AI coding tools, it is the only reliable place to apply policy because the model itself does not enforce rules deterministically.
• AI Usage Control: AI usage control is the external governance layer that governs what an AI system may generate, access, or change. It binds policy to repository, role, and environment context so that output can be allowed, modified, or rejected before it becomes part of the software supply chain.
• Context Window: A context window is the block of text a model can actively consider when generating output. In practice, it is a moving information boundary, which means long or conflicting sessions can change which instructions appear most salient and which rules get ignored.

What's in the full article

Knostic's full article covers the operational detail this post intentionally leaves for the source:

• Runtime enforcement design for AI-generated code, including where policy checks sit in the development workflow.
• Examples of blocked, redacted, and transformed outputs for secrets, unsafe defaults, and prohibited libraries.
• How Kirin applies repository, role, and environment context to AI coding decisions.
• Audit logging details that support investigations, compliance reviews, and exception handling.

👉 The full Knostic post covers runtime enforcement, audit logging, and policy controls for AI coding tools.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.