Security for AI-generated code

A security workflow for verifying and hardening AI-generated code

The safest way to use code generated by large language models (LLMs) is to treat it like a contribution from an unfamiliar developer: potentially useful, but untrusted until it has been reviewed, tested, and checked against security requirements.

No single tool can establish that code is secure. A strong workflow combines static analysis, dependency and secret scanning, sandboxed execution, automated testing, human review, and continuous integration (CI/CD) controls.

1. The end-to-end workflow

1. Isolate generated code

Use a branch, disposable container, restricted permissions, and no production credentials.

2. Scan and sanitize

Lint, analyze vulnerabilities, detect secrets, and inspect dependencies and build scripts.

3. Test in a controlled environment

Run unit, integration, property-based, and adversarial tests with resource limits.

4. Review and verify

Inspect security-sensitive changes, validate requirements, and require independent approval.

5. Gate release and monitor

Enforce CI checks, generate provenance and an SBOM, sign artifacts where appropriate, and monitor production.

The key principle is defense in depth: a clean static scan does not prove correctness, and passing tests do not prove the absence of vulnerabilities.

2. Tools to use at each stage

These are practical options for building a layered security pipeline. Most have free or open-source options; some also offer commercial platforms.

Tool selection is based on the tools' roles and established secure-development guidance, not a claim that any one product guarantees secure code.owasp.github.io+2

1. Static application security testing (SAST)

Finds risky coding patterns without running the program: injection flaws, unsafe deserialization, weak cryptography, and other common vulnerabilities.

• Semgrep — pattern-based scanning and custom organization-specific rules.

• GitHub CodeQL — query-based analysis that can trace data flows through supported languages.

• Bandit — useful for Python security checks.

  Use it on every pull request and block new high-severity findings.

Semgrep · CodeQL ·Bandit

2. Dependency and software supply-chain analysis (SCA)

LLMs can suggest nonexistent, typosquatted, outdated, or vulnerable packages. Verify that each dependency exists, comes from the intended publisher, is maintained, and is needed.

• OSV-Scanner — checks dependencies against the OSV vulnerability database.
• Dependabot — alerts and dependency updates on GitHub.
• pip-audit — audits Python environments and dependency requirements.
• npm audit — checks Node.js dependencies against known advisories.

OSV-Scanner · Dependabot ·pip-audit

3. Secret detection and sensitive-data protection

Detect API keys, cloud credentials, private keys, passwords, and tokens accidentally introduced into source code or Git history.

• Gitleaks — scans repositories and commits for likely secrets.
• TruffleHog — searches for exposed secrets and supports credential verification.
• GitHub secret scanning — detects supported secret types in repositories.

Add pre-commit checks and CI checks. If a real credential has been exposed, revoke or rotate it; deleting the line alone does not invalidate the secret.

Gitleaks · TruffleHog ·GitHub secret scanning

4. Runtime and dynamic testing

Test the application while it runs. This can expose vulnerabilities that source analysis misses, including security-header problems, authentication weaknesses, and exploitable web behavior.

• OWASP ZAP — dynamic web application and API security testing.
• Schemathesis — generates API tests from OpenAPI or GraphQL schemas.
• Atheris — coverage-guided fuzz testing for Python code.

Run against a disposable staging environment with test accounts and synthetic data, never against production without authorization.

OWASP ZAP · Schemathesis ·Atheris

5. Containers, infrastructure, and configuration

AI-generated Dockerfiles, Terraform, Kubernetes manifests, and CI workflows deserve their own security checks.

• Trivy — scans dependencies, container images, and infrastructure configurations.
• Checkov — checks infrastructure-as-code for misconfigurations.
• OpenSSF Scorecard — evaluates security practices in open-source projects.

Watch for privileged containers, public storage, excessive IAM permissions, unpinned third-party CI actions, and unexpected network access.

Trivy · Checkov ·OpenSSF Scorecard

3. What does “sanitize” generated code actually mean?

Sanitization is not simply removing suspicious strings from source code. It means making the program safe at the boundaries where it accepts input, handles data, or performs privileged actions.

These controls should be implemented in the code itself and enforced by tests and security rules. A generic “sanitization” function is not a universal defense. For example, HTML escaping will not make a shell command safe, and input validation does not replace authorization. OWASP's secure-development guidance provides a useful basis for reviewing these risks.owasp.github.io+3

4. Build a CI/CD pipeline that enforces the checks

A good default is to run fast, deterministic checks on every pull request and deeper tests on a schedule or before release. The following is a practical starting configuration, consistent with OWASP DevSecOps recommendations.owasp.github.io+1

Use documented exceptions for false positives and unfixable vulnerabilities, with an owner, rationale, compensating controls, and an expiration or review date.

Example: a local Python and JavaScript security check

Install the appropriate tools in a development environment, then run the relevant checks against your project:

# Python source security
bandit -r src/

# Python dependency audit
pip-audit

# JavaScript dependency audit (if applicable)
npm audit

# Secret detection
gitleaks dir .

# Static analysis (Semgrep)
semgrep scan --config auto .

These commands are illustrative; flags and project paths may need adjustment. Install tools through trusted package sources and pin their versions in CI. A scanner exit code of zero means that particular check did not report a blocking finding, not that the code is secure.

For production use, run these checks in a clean CI runner and upload machine-readable reports to your code-hosting platform. Avoid printing secrets in logs or running untrusted pull-request code with privileged tokens.

5. Add AI-specific security controls

Traditional secure-development tools still apply, but AI introduces extra risks that are worth addressing explicitly. OWASP's guidance on AI-assisted development highlights several.owaspsamm.org+2

Verify every suggested dependency

Confirm the package name, registry, maintainer, version, provenance, and known vulnerabilities before installation. Do not assume a plausible-looking package exists or is trustworthy.

Sandbox coding agents

Use disposable containers or virtual machines, restricted filesystem access, network egress controls, and least-privilege permissions. Do not give an agent production credentials or unrestricted shell access by default.

Review the entire change, not just the generated function

Inspect dependency lockfiles, package lifecycle scripts, Dockerfiles, CI workflows, infrastructure files, and AI instruction files. Unexpected edits to these can create a supply-chain compromise.

Protect against prompt injection

Treat repository issues, comments, documentation, fetched webpages, and tool responses as untrusted data when an AI agent consumes them. A malicious instruction embedded in these sources must not grant the agent new privileges or override security policy.

Keep independent human approval

Require a qualified reviewer for authentication, authorization, cryptography, sensitive data handling, and CI/CD or infrastructure changes. AI-based code review can help prioritize issues, but it should not approve its own work.

6. A practical starter stack

If you want to begin without building a complex security program, I would choose a small, complementary set of tools rather than deploying every scanner at once.

For an individual developer or small team

Git + Gitleaks + Semgrep + the language's native dependency auditor + unit tests. Run everything locally first, then repeat the same checks in CI.

For a team shipping web applications

Add CodeQL or equivalent SAST, OSV-Scanner, Trivy, OWASP ZAP, branch protection, mandatory code-owner review, and scheduled rescans.

For regulated or high-assurance systems

Add threat modeling, formal security requirements, independent penetration testing, SBOM and provenance controls, isolated build infrastructure, audited exceptions, and documented evidence for release decisions.

For a standards-based approach, start with the NIST Secure Software Development Framework (SSDF) and the OWASP Application Security Verification Standard (ASVS). These help turn vague expectations such as “make the code secure” into requirements that can be tested and reviewed.

7. Tailor the workflow to your codebase

The ideal toolchain depends heavily on the language, deployment model, and risk level.

What kind of code are you verifying?

Language or framework

Python

JavaScript / TypeScript

Java / Kotlin

Go, Rust, C, or C++

Multiple languages

Application type

Web application or API

Mobile or desktop application

Infrastructure or DevOps scripts

Autonomous AI coding agent

Library, embedded, or other

Budget and deployment constraints

Open-source and low cost

Enterprise or commercial tools

Sensitive code; self-hosted or on-premises

CI/CD platform

GitHub Actions

GitLab CI

Jenkins or other CI

No CI yet

[Build my security workflow]

The most important takeaway: automate repeatable checks, isolate execution, verify dependencies, and require accountable review before release. That combination is substantially stronger than asking an LLM to inspect or certify its own generated code.

Securing and verifying Large Language Model (LLM)-generated code requires a multi-layered defense strategy . Because models frequently lack context across multi-file architectures or hallucinate insecure dependencies and logic, you cannot rely solely on the AI to review its own output.checkmarx.com+1

A robust framework blends real-time IDE prevention, deterministic security scanning, automated testing, and CI/CD policy gates.checkmarx.com

Phase 1: Real-Time IDE and Local Verification (Shift-Left)

Catching insecure patterns before code is committed drastically reduces remediation costs.ox.security+1

• IDE-Integrated SAST (Static Application Security Testing): Use tools like SonarQube or Snyk Code embedded directly in your IDE (VS Code, JetBrains) to highlight insecure patterns, hardcoded secrets, or logic flaws as the LLM streams the code.ox.security+1
• Secrets and Credential Scanners: LLMs frequently invent realistic-looking dummy API keys, private keys, or connection strings that might accidentally be valid or match internal formats. Run local hooks via TruffleHog or Gitleaks before any staging commit.
• AI-Generated Code and License Validation: Specialized tools like JFrog AI-Generated Code Validation analyze snippet origins and semantic matching to track unvetted blocks, preventing viral open-source license violations (like unintended GPL injection) or toxic snippets.jfrog.com

Phase 2: Automated CI/CD Pipeline Gates

Never allow raw LLM output or unverified pull requests to merge straight into primary branches without deterministic checks.checkmarx.com

• Hybrid SAST Analysis: Deterministic engines (such as Veracode or Checkmarx ) trace data flows across multi-function and multi-file architectures—something LLMs often fail to compute contextually. These tools don't guess; they verify data paths from entry points to sinks.veracode.com
• Software Composition Analysis (SCA): LLMs love to hallucinate non-existent package names or recommend deprecated/vulnerable library versions. Run SCA tools (like OWASP Dependency-Check or Socket.dev ) to verify that imported modules exist, are safely maintained, and carry no CVEs.
• Pull Request Security Gates: Configure automated blocking mechanisms in GitHub/GitLab. If a PR contains un-scanned AI blocks, high-severity CVEs, or failing lint rules, the merge button remains programmatically locked.checkmarx.com+1

Phase 3: Automated Functional & Sandbox Testing

Logic errors and subtle regressions are best exposed via rigorous testing frameworks.

• Isolated Sandbox Testing / Multi-Agent Verification: For complex algorithmic implementations or bug fixes, spin up isolated container environments (using Docker or ephemeral environments) where a secondary automated testing script or isolated agent replays unit/integration scenarios against the changes.
• Property-Based and Fuzz Testing: Run fuzzers (like AFL++ or language-specific property testing frameworks) on LLM-generated parsing logic or data-handling functions to catch edge-case crashes, buffer overflows, or unhandled exceptions that standard unit tests miss.reddit.com

Recommended Integrated Workflow

1. Prompt & Generate: Developer prompts the LLM inside a secure IDE extension.
2. Local Lint & Scan: Real-time SAST/Secret scanning flags structural issues instantly in the workspace.
3. Containerized Unit Tests: Local test suites execute immediately upon saving.
4. PR Gate Enforcement: Code is pushed to a feature branch; CI/CD runs deep hybrid SAST, SCA dependency resolution, and license compliance audits.
5. Human Code Review: Peer review focuses strictly on business logic and architecture, knowing baseline security and dependency risks are already cleared by automation.ox.security+2

If you'd like to tailor this further, tell me:

• What programming languages or frameworks your team uses primarily?
• Are you looking for open-source tools or enterprise commercial platforms?

Yes. The safest approach is to treat AI-generated code as untrusted third-party code until it passes the same—and preferably stronger—controls as human-written code. OWASP’s current guidance specifically recommends human ownership, automated security testing, dependency verification, sandboxing, and careful review of agent-generated changes.cheatsheetseries.owasp.org+1

A practical workflow

1. Generate in isolation

• Have the AI work on a branch or disposable worktree.
• For agentic tools that can execute commands, use a dev container/VM with restricted filesystem and network access.
• Don't expose .env files, SSH keys, cloud credentials, or production secrets to the agent.cheatsheetseries.owasp.org

2. Review the diff before running it Look at every changed file, not just the code the AI was asked to write. Pay particular attention to:

• package.json / build scripts
• CI workflows
• Dockerfiles
• dependency/lock files
• authentication and authorization code
• database queries
• cryptography
• tests that were deleted or weakened

OWASP specifically calls out out-of-scope edits and test manipulation as recurring risks with coding agents.cheatsheetseries.owasp.org

3. Verify dependencies before installing Don't blindly accept an AI-suggested package. Check that it actually exists, has a credible maintainer history, and isn't a suspicious newly registered/low-download package. Then run your normal SCA/dependency scanner. OWASP recommends tools such as npm audit, pip-audit, govulncheck, and cargo audit, as applicable.cheatsheetseries.owasp.org

4. Run multiple automated security layers

Check	What it catches	Examples
SAST	Vulnerable code patterns	Semgrep, CodeQL
SCA	Vulnerable/transitive dependencies	Snyk, Dependabot, OSV tools
Secret scanning	API keys, tokens, credentials	GitHub Secret Scanning, Gitleaks
IaC scanning	Unsafe cloud/container configuration	Checkov, Trivy
DAST	Runtime vulnerabilities	OWASP ZAP, Burp Suite
Tests	Functional regressions	Your normal unit/integration tests
Fuzz/adversarial tests	Edge cases AI may miss	AFL++, Jazzer, property-based tests

OWASP recommends running SAST, SCA, and secret scanning on every PR; its AI-specific guidance additionally recommends IaC/DAST/IAST where appropriate.cheatsheetseries.owasp.org+1

Tools I'd consider

Semgrep is a particularly good fit for an AI-code gate because it can run in the IDE, pre-commit, and CI, and supports static analysis and security rules.github.com

Semgrep

Snyk is useful when you want SAST + dependency/SCA analysis + secrets and IDE/PR integration in one security workflow. Its current tooling explicitly supports scanning AI-generated code as it is written.cheatsheetseries.owasp.org+2

Snyk

If you're already on GitHub, GitHub Code Security/CodeQL + Dependabot + secret scanning gives you a strong baseline. GitHub's Copilot cloud agent also performs security validation and a second code-review pass, but that should complement—not replace—your independent security controls.docs.github.com

GitHub Code Security

The key architectural pattern

I'd implement the pipeline roughly like this:

AI generates code
       ↓
isolated branch / container
       ↓
human reviews raw diff
       ↓
dependency verification
       ↓
SAST ──┐
SCA ───┤
Secrets┤
IaC ───┤──→ CI security gate
Tests ─┤
DAST ──┘
       ↓
human security/code review
       ↓
merge
       ↓
normal production monitoring

The important distinction is “AI review” versus “independent validation.” If the same model generates the code, writes the tests, and then says the code is secure, you've created a correlated failure mode. OWASP explicitly recommends adversarial/negative tests and human review rather than treating a passing AI-generated test suite as proof of security.cheatsheetseries.owasp.org

One extra control that's easy to overlook

For agentic coding, the agent itself is part of your attack surface. Repository issues, PR comments, README files, dependency documentation, and web pages can contain indirect prompt injections that influence an agent. Keep agent permissions narrow, restrict network egress, and don't give a coding agent production credentials.cheatsheetseries.owasp.org

If I were setting this up for a typical GitHub project, my minimum viable stack would be isolated coding environment + protected PR + Semgrep/CodeQL + dependency scanning + Gitleaks/secret scanning + tests + mandatory human review, with stricter two-person review for authentication, authorization, CI/CD, and deployment changes.cheatsheetseries.owasp.org+1

Integrating AI-generated code safely requires treating Large Language Model (LLM) outputs like code from an untrusted junior developer: functional, fast, but frequently optimized for completion over secure defaults or architectural cohesion.arnica.io

A robust workflow combines pre-generation guardrails, automated pipeline validation , and human-in-the-loop review.

Step-by-Step Secure Integration Workflow

1. Pre-Generation / IDE Guardrails
   • Feed context-aware prompts by scoping your AI assistant (e.g., using .cursorrules or custom instructions in GitHub Copilot or Cursor ) with explicit coding standards, framework constraints, and forbidden patterns (like hardcoded secrets or raw SQL queries).
   • Utilize frameworks that enforce secure-by-default rules during generation.reddit.com
2. Automated CI/CD Quality and Security Gates
   • Never let AI code bypass standard static analysis. Every commit containing AI contributions must pass automated checks before human review.
   • Run SAST (Static Application Security Testing) to catch injection flaws, memory leaks, and insecure cryptography.
   • Run SCA (Software Composition Analysis) specifically to check for AI "slopsquatting" or hallucinated package dependencies (where an AI invents a non-existent package name that an attacker could register maliciously).developer.harness.io
3. Targeted Human Code Review
   • Reviewers must pay special attention to authorization, boundary conditions, and tenant isolation—areas where LLMs lack the wider architectural context of your system.
   • Enforce a strict "you own what you merge" policy so developers don't rubber-stamp AI-generated pull requests.kodemsecurity.com+1

Essential Security Tools for Validation & Cleaning

• Static Analysis (SAST)
  • Traditional/Deterministic: Tools like Snyk Code or Checkmarx scan code patterns instantly for hardcoded credentials, known vulnerabilities, and bad syntax.
  • AI-Aware/Reasoning Security: Platforms like Kodem Security or OX Security analyze runtime behavior and semantic logic to catch deeper authorization issues (like Insecure Direct Object References) that simple rule-based linters miss.kodemsecurity.com
• Dependency & Supply Chain Scanners (SCA)
  • Use tools like Socket.dev or Snyk Open Source to verify that any third-party libraries or modules recommended by the AI actually exist, are actively maintained, and are free from malware.
• Secret Detection
  • Integrate tools like GitGuardian or TruffleHog into your pre-commit hooks and CI pipeline. LLMs have a bad habit of generating realistic-looking dummy API keys or tokens that accidentally match real production secrets.

If you'd like, let me know:

• What languages and frameworks your codebase uses
• Which AI tools your team currently relies on (e.g., Copilot, ChatGPT, Claude)

I can help tailor a specific CI/CD pipeline configuration or linting rule set for your stack.

A security workflow for code written by LLMs

If you're using large language models to generate code, the safest approach is to treat every generated change as untrusted code until it passes independent verification. Don't rely on the model to certify its own output, explain why it is secure, or write tests that are sufficient to prove its correctness.

I'd build a layered pipeline that combines static analysis, automated testing, dependency and secret scanning, sandboxed execution, and human review for high-risk changes.

The key principle is defense in depth: no single scanner, test suite, or AI reviewer can guarantee that generated code is safe.

1. Implement this verification pipeline

1. Capture generated changes

Diff review, scope limits, file and permission restrictions

2. Run deterministic security checks

Formatting, linting, SAST, secrets, dependencies, IaC and configuration scans

3. Test in isolation

Unit, integration, property-based, fuzz and regression tests in a sandbox

4. Review and approve

Human review, risk-based approval, independent security review

5. Release with safeguards

Reproducible builds, artifact provenance, least privilege, monitoring and rollback

This fits the general secure-development approach in NIST's Secure Software Development Framework, which integrates security practices across the software lifecycle rather than treating security as a final scan.csrc.nist.gov+1

2. Which tools to implement

Recommended starting stack; choose equivalents that fit your language, repository host and deployment platform.

Static analysis (SAST)

Find injection flaws, unsafe APIs, missing authorization checks and insecure patterns before execution.

• Tools: Semgrep; CodeQL; language-specific linters.
• Run on every pull request and fail on new high-severity findings.
• Add custom rules for your application's security requirements.

Reference: Semgrep documentation.semgrep.dev+1

Dependency and supply-chain checks

Catch vulnerable packages, hallucinated package names, typosquatting and risky transitive dependencies.

• Tools: npm audit, pip-audit, govulncheck, cargo audit, OSV-Scanner.
• Verify package names and registries; lock and pin dependencies.
• Review new packages and licenses; use an SBOM and dependency policy for production.

Reference: OWASP Secure Coding with AI.cheatsheetseries.owasp.org

Secret and sensitive-data scanning

Detect API keys, tokens, private keys, passwords and accidental credential exposure.

• Tools: Gitleaks; GitHub Secret Scanning; TruffleHog.
• Scan diffs, repositories and commit history, plus build logs where feasible.
• Block commits containing secrets. If a real secret leaks, revoke or rotate it immediately.

Reference: GitHub secret scanning.docs.github.com+1

Runtime and application security testing

Find problems static scanners may miss, including broken access control and exploitable request flows.

• Tools: OWASP ZAP for web applications; language-native test frameworks; coverage-guided fuzzers.
• Test authentication, authorization, malformed inputs, boundary conditions and failure paths.
• Use synthetic data and isolated test services, never production systems by default.

Reference: OWASP ZAP.

Also add infrastructure-as-code and container scanners if the model generates Terraform, Kubernetes manifests, Dockerfiles or CI workflows. Examples include Checkov, Trivy and Hadolint.

3. Sanitize output at the correct boundary

A common mistake is to assume that generated code can be made safe by removing suspicious strings. Sanitization must depend on how the output will be used. Prefer validation and safe APIs over ad hoc string replacement.

For example, prefer this Python pattern:

# Safer: values are bound separately from SQL syntax
cursor.execute(
    "SELECT * FROM users WHERE email = %s",
    (email,)
)

The placeholder syntax varies by database driver. The important part is that email is bound as a value, not interpolated into the SQL string.

For AI-generated code, have tests explicitly exercise malicious inputs, unexpected types, empty values, oversized payloads, path traversal attempts and authorization failures.

4. Secure the LLM agent itself

Scanning generated code is only half the problem. If your model can execute shell commands, install dependencies, read secrets or modify CI configuration, the generation workflow itself becomes an attack surface.

OWASP's current Secure Coding with AI Cheat Sheet specifically addresses agent permissions, indirect prompt injection, dependency risks and fabricated tests.cheatsheetseries.owasp.org

Implement these controls:

• Sandbox execution: use ephemeral containers or VMs, with no production credentials, restricted filesystem access, CPU/memory limits and network egress controls.
• Least privilege: give the agent write access only to the task's working tree. Require approval for deployments, publishing packages, changing permissions or accessing sensitive services.
• Protect secrets: exclude .env, private keys, cloud credentials and sensitive directories from model context. Use short-lived, scoped credentials where access is necessary.
• Defend against prompt injection: treat issue descriptions, READMEs, webpages, logs and tool responses as untrusted data, not trusted instructions.
• Restrict tools: allowlist shell commands and approved MCP servers; validate tool arguments and require approval for dangerous operations.
• Protect security configuration: require explicit review of changes to CI workflows, dependency lockfiles, agent instruction files, test suites and build scripts.

A particularly important rule: don't let the same agent both write security-critical code and independently certify it as secure. Use deterministic checks and independent review.cheatsheetseries.owasp.org

5. Make CI enforce the security gates

A pull request should not merge just because the build succeeds. Define mandatory checks and enforce them in your repository's branch protection or rulesets.

Here's a language-agnostic policy you can adapt:

Example CI pipeline

This is an illustrative GitHub Actions-style workflow. Pin third-party actions to reviewed commit SHAs, use least-privilege job permissions, and adapt the commands to your stack.

name: generated-code-security

on:
  pull_request:

permissions:
  contents: read

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<REVIEWED_COMMIT_SHA>
        with:
          persist-credentials: false

      - name: Install locked dependencies
        run: npm ci

      - name: Static analysis
        run: npx semgrep scan --config auto --error .

      - name: Dependency audit
        run: npm audit --audit-level=high

      - name: Tests
        run: npm test

      # Add secret scanning, build/config scanning,
      # security regression tests, and artifact checks.

Replace the placeholder SHA before using this workflow. In a hardened setup, execute untrusted tests and agent-generated build steps in a separate, isolated job with no write tokens or deployment secrets. Avoid allowing generated code to control its own security gates.

6. Add an independent security-review layer

An LLM can be useful as a secondary reviewer, particularly when asked to inspect a diff for specific vulnerability classes. It should not be the only reviewer.

Give the reviewer a structured checklist:

• Can user-controlled data reach SQL, shell commands, HTML rendering or file operations?
• Are authentication and authorization checks enforced on the server?
• Are secrets, sensitive logs or personal data exposed?
• Can inputs cause resource exhaustion, race conditions or unsafe deserialization?
• Were existing tests weakened, skipped or deleted?
• Were unexpected files, dependencies, permissions or network access added?
• Do the tests establish expected behavior independently of the implementation?

For higher-risk code, supplement this with manual threat modeling, targeted penetration testing and independent review by a security engineer. Consider using a different model for secondary review, but remember that model diversity reduces some shared blind spots; it doesn't establish correctness.

7. Prioritize controls by risk

Not every generated change needs the same level of scrutiny.

8. A practical implementation plan

If you're starting from scratch, I'd implement these in order:

1. First: establish hard merge gates. Add secret scanning, SAST, dependency auditing and tests to every pull request. Make the checks required.
2. Second: isolate generation and execution. Use disposable workspaces, restrict filesystem and network access, and remove production credentials from the agent's environment.
3. Third: harden code review. Flag out-of-scope edits, changes to tests, dependency changes and modifications to build or CI configuration. Require a human to approve sensitive changes.
4. Fourth: add adversarial verification. Maintain security regression tests, fuzz important parsers and endpoints, and test authentication, authorization and input-handling boundaries.
5. Fifth: measure effectiveness. Track vulnerabilities escaping into production, time to remediate, false-positive rates, security-gate bypasses and the proportion of changes reviewed.

For a broader organizational framework, use NIST's Secure Software Development Framework and its generative-AI-specific SSDF profile.csrc.nist.gov+1

My recommendation: start with a required CI pipeline, sandboxed agent execution and strict secret/permission controls. These provide more dependable protection than adding another AI reviewer alone.

To tailor this into a concrete implementation, what language and environment are you using most?