You get secure code from an AI coding assistant by giving it your security rules as context, keeping its permissions narrow, and checking every change with the same tests and scanners as human code. Prompting improves results, but the checks after generation are what make it dependable.
Why does generated code need checking?
A coding assistant predicts plausible code. Plausible is not the same as safe. It may reproduce an unsafe pattern common in its training data, call a library function that is deprecated, or invent a package name that does not exist. It also does not know your threat model unless you tell it.
NIST SP 800-218, the Secure Software Development Framework, does not carve out an exception for code that a person did not type. Its practices on code review, testing and vulnerability handling apply to whatever enters your codebase. NIST SP 800-218A adds practices for generative AI and dual use foundation models, written for producers and acquirers of AI systems.
What can you tell the assistant up front?
Most assistants read a rules or instructions file from the repository. Use it for facts that are specific to your code:
- The approved way to run a database query, such as parameterised statements only
- How to encode output in your web framework
- Which libraries are approved for cryptography, and which are banned
- Where secrets come from, and that they are never written into source
- Logging rules, such as no personal data in log lines
Keep the file short and concrete. A rule such as "use the project's query helper for all SQL" is easier to follow than "write secure code." Review the file like any other code, because it is an input that shapes what gets written.
What should you check after generation?
Run, in this order: unit tests, a static analysis scan for the language, dependency scanning on any new package, and secret scanning. Then review the diff.
Pay special attention to new dependencies. OWASP lists supply chain concerns among LLM risks, and an assistant suggesting a package you have never heard of deserves a look at the package's age, maintainers and download history before it is installed.
Reviewers should read generated code as skeptically as a first time contributor's. It often looks tidy while hiding an unchecked input or a swallowed error.
How do you limit the damage?
Agentic assistants can run commands and edit many files. Give them a sandbox or a branch, not a shell with production credentials. Block pushes to protected branches, require review before merge, and keep deployment out of their reach. Where an assistant calls tools through MCP, limit which tools are allowed.
A constructed example
A developer asks an assistant for an endpoint that returns a user's invoices. The first draft builds the query by joining the invoice ID from the URL into a SQL string and never checks that the invoice belongs to the logged in user.
The team's rules file says to use the query helper and to call the authorisation check on every object lookup. With the file in place, the second draft does both. A test that requests another user's invoice and expects a denial catches any regression. The scanner would have flagged the first draft, and the review would have caught the missing ownership check.
How to check or apply this
- Write a short security rules file for each repository and keep it in version control.
- Include approved libraries for queries, output encoding, cryptography and secrets.
- Run tests, static analysis, dependency scanning and secret scanning on every pull request, with no exemption for generated code.
- Verify any new package before accepting it.
- Add tests for authorisation and input handling, not just the happy path.
- Run agents on branches with limited credentials and no deploy rights.
- Track defects by origin, human or assisted, to see whether the rules file is working.
Safeguard offers IDE extensions for VS Code, Cursor through Open VSX and JetBrains, and an MCP server at mcp.safeguard.sh, so dependency and code findings can surface while code is being written. They sit alongside the checks above and do not replace review.
Quick check
Does telling the model to write secure code work?
It helps a little but cannot be trusted. Specific rules and automatic checks do the real work.
Should generated code be labelled?
It helps reviewers and metrics. Many teams add a note to the pull request when an assistant wrote a large share of it.
Sources
- NIST SP 800-218, Secure Software Development Framework
- NIST SP 800-218A, SSDF Community Profile for Generative AI
- OWASP Top 10 for LLM Applications
Last reviewed: 18 October 2026.
