State security outcomes
Define trust boundaries, sensitive data, authorization rules, and production expectations before asking for implementation.
From warning to action
The answer is not a single prompt, scanner, or better model. The failure modes begin at specification and continue through deployment, so controls must do the same.
In the only controlled mitigation experiment in this literature, the baseline vulnerability-reintroduction rate was 40%.
In Deng, Fan and Meng's mitigation experiment, "Make this production-ready" and "now review what you wrote for security problems" produced meaningful reductions. A longer, highly detailed "professional" prompt made outcomes worse. More specification is not automatically more safety.
These controls map directly to the measured defect classes and verified incidents.
Define trust boundaries, sensitive data, authorization rules, and production expectations before asking for implementation.
Ask the model to explain data flow, authorization, failure states, and tradeoffs before accepting its code. This interaction pattern produced the strongest comprehension result.
Sign in as user A and request user B's data through the API - not the UI. Repeat for every table, route, storage bucket, and secondary resource.
Do not let the authoring model be the only reviewer. Combine a separate AI review with deterministic analysis and executable tests.
AI can produce changes faster than humans can review them. Keep diffs small enough to inspect across the whole call graph, not only the changed file.
Separate development, preview, and production. Keep production credentials out of coding sessions and require approval for destructive operations.
Scan secrets and dependencies, block security TODOs, run runtime authorization tests, and treat every AI warning comment as an unresolved issue.
The authoring agent cannot be the entire quality system.
Prompting raises awareness. Independent tests, restricted authority, and release gates turn awareness into enforceable behavior.