How do you secure AI-assisted software development?

Secure AI-assisted development by treating generated code as untrusted input, limiting what coding agents can read and run, and keeping the same review, testing and dependency checks you use for human code. NIST SP 800-218A extends the Secure Software Development Framework for generative AI work.

What changes when an assistant writes code?

The volume of code rises and the author is no longer a person who understands every line. Three risks follow. Generated code can contain the same flaws humans write, such as injection or weak input checks. It can reference packages that do not exist or are not what the name suggests. And an agent with tool access can act, not just suggest.

NIST SP 800-218A, a community profile that augments the SSDF for generative AI and dual-use foundation models, frames this as a development practice problem: protect the environment, check the outputs, and respond to what you find.

Which risks come from the assistant itself?

OWASP's Top 10 for LLM Applications names the relevant ones. Prompt injection means text the model reads, such as a README or an issue comment, can steer its actions. Excessive agency means the tool has more permissions than the task needs. Supply chain issues cover models, plugins and datasets you did not build.

A constructed example. A developer asks an agent to fix a failing test. The agent reads a vendored file whose comment says to also upload the environment file to a URL. If the agent can run network commands and read secrets, the comment becomes an attack. If it runs in a workspace without secrets and with no outbound access, the same comment does nothing.

What controls matter most?

Start with permissions, because they cap the damage of every other failure.

1. Run agents in a sandbox with no production credentials and only the repository they need.
2. Give them short-lived tokens that expire, not your personal keys.
3. Require approval for commands that delete, publish, deploy or contact new hosts.
4. Keep secrets out of prompts and out of files the agent can read.

Then treat the output like a pull request from a stranger. It goes through code review, static analysis, secret scanning and tests. Reviewers should know a change was machine-generated so they look for plausible but wrong logic.

Finally, check dependencies. An assistant may add a package because it sounds right. Verify the package exists, is the intended one, has a sane history and has no known vulnerabilities before it lands in a lockfile.

Does AI-written code need different tests?

Mostly the same ones, applied more strictly. Add tests for the failure the code claims to fix, and tests for inputs that should be rejected. Property tests and fuzzing help when you cannot read every branch. Measure whether coverage includes error paths, since generated code tends to be tidy on the happy path.

Where can Safeguard help?

Safeguard scans dependencies and produces an SBOM, runs reachability analysis to show which vulnerable code your app can actually call, and applies policies and gates in pull requests. Its MCP Guardrail is designed to sit between agents and the tools they call. These cover the dependency and gating parts of the list below. They do not replace review.

How to check or apply this

1. Write a one-page policy: which agents are allowed, what they may access, who approves.
2. Remove standing credentials from developer machines and agent workspaces.
3. Add a pull request label for AI-assisted changes and track defect rates against unlabeled changes.
4. Block merges on new critical findings in dependencies and secrets.
5. Log agent tool calls so you can reconstruct what happened.
6. Review the policy every quarter, as tools change fast.

Quick check

Sources

1. NIST SP 800-218A, SSDF Community Profile for Generative AI
2. NIST SP 800-218, Secure Software Development Framework
3. OWASP Top 10 for Large Language Model Applications

Last reviewed: 18 October 2026.