What happens when developers rely on vague prompts like ‘make this better’ in security-sensitive code?

Why This Matters for Security Teams

Vague prompts create a control-preservation problem, not just a coding-quality problem. When a developer asks an AI to “make this better,” the model may improve readability or reduce duplication while silently changing the security properties that were embedded in the original code. In security-sensitive code, those properties often live in small details: an authorization check, a validation branch, a token comparison, or a cross-site request forgery control.

The risk is highest when the code already reflects hard-won defensive decisions that are not obvious from the surrounding logic. A prompt that lacks constraints gives the model permission to optimize for generic software quality rather than explicit security intent. That can be especially dangerous in CI pipelines where AI-generated diffs are reviewed quickly and merged because they look clean.

Current guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need to preserve access control, input validation, and secure development controls as explicit requirements rather than implied expectations. In practice, many security teams discover prompt-driven regressions only after an access path has already been simplified away or a defensive check has been “cleaned up” into something weaker.

How It Works in Practice

In day-to-day development, vague prompts tend to produce broad refactoring behaviour. The model may rename variables, consolidate conditionals, move code into helper functions, or remove branches it interprets as dead code. That is useful when the target is ordinary maintainability, but it is risky when the code contains security logic whose purpose is not self-evident.

• Authorization logic can be collapsed into a simpler path that no longer distinguishes privileged from unprivileged users.
• Input validation can be softened if the model assumes a check is redundant with downstream handling.
• CSRF or session protections can be relocated or omitted if they are not described as mandatory constraints.
• Secret handling can be altered if the prompt focuses on readability instead of immutability and masking requirements.

The safer pattern is to treat the prompt like a change request with guardrails. Specify the security objective, the exact files or functions that may be modified, and the invariants that must remain intact. For example, a prompt can allow performance improvements while forbidding changes to authentication flows, cryptographic comparisons, logging redaction, or request validation. When a model is asked to preserve the existing security posture, it is less likely to “helpfully” remove the very control that mattered.

This is where AI-assisted coding intersects with governance: the prompt becomes part of the control plane. Teams should review generated diffs for security semantics, not just syntax, and require human approval for any changes touching trust boundaries, identity checks, or secret-dependent code. These controls tend to break down when a codebase mixes business logic and security logic in the same functions because the model cannot reliably infer which lines are non-negotiable.

Common Variations and Edge Cases

Tighter prompt constraints often increase review overhead, requiring organisations to balance speed against the risk of unintended security regression. That tradeoff becomes sharper in codebases where security checks are scattered, undocumented, or duplicated across services.

There is no universal standard for prompt wording yet, but current guidance suggests that security-sensitive prompts should be specific about exclusions as well as desired outcomes. A request to “refactor this safely” is still too vague if it does not say what must not change. More reliable prompts name invariants such as “preserve role checks,” “do not alter token validation,” or “leave antiforgery logic untouched.”

Edge cases appear when the model is asked to work across generated code, legacy code, or partial context. In those environments, the model may infer that a control is redundant because it cannot see the full dependency chain. That is especially common when security is enforced across middleware, decorators, gateways, or shared libraries rather than within a single function. Best practice is evolving, but the operational rule is simple: the less context the model has, the more explicitly the prompt must define the security boundary.

Related resources from NHI Mgmt Group

• What happens when teams rely on only code scanning and dependency alerts for application security?
• How should security teams govern browser-based AI prompts that may contain sensitive data?
• How should security teams govern AI prompts that include sensitive data?
• How should security teams handle device code phishing in environments that rely on CLI sign-in?