Use coding assistants and generative development tools inside a normal secure-development lifecycle with approved-tool boundaries, repository review, testing, secrets protection, dependency and provenance checks, evaluation, and accountable human ownership.
This revision removes obsolete M-24-10 and vendor-specific assumptions. It uses NIST SSDF 1.1 as the current final baseline, SP 800-218A for AI-specific development considerations, and treats SSDF 1.2 as draft work until NIST finalizes it.
NIST SP 800-218, Secure Software Development Framework Version 1.1, remains the current final SSDF baseline. NIST has also finalized SP 800-218A, an SSDF Community Profile that adds practices and considerations for generative AI and dual-use foundation models. NIST's proposed SSDF Version 1.2 was published as an initial public draft in December 2025; teams can track it, but should distinguish draft guidance from the current final framework.
The practical control objective does not depend on whether a developer typed the code, copied a snippet, generated it with an assistant, or accepted an automated patch. Code entering a maintained product should meet the same security, correctness, testing, review, provenance, licensing, and operational standards required for the repository.
AI changes the failure distribution. Developers can produce more code quickly, hallucinate nonexistent libraries or APIs, introduce insecure patterns with high confidence, accept changes they do not fully understand, expose sensitive context to a provider, or allow agents to take actions across a repository and development environment. Governance should target those changed risks without creating a second development lifecycle.
Product names change quickly. The durable control is an approved capability and data boundary.
Do not rely on a generic “AI tools approved” policy. A chat interface that receives manually pasted code has a different risk profile from an agent with repository, terminal, package, and deployment permissions. Approval should follow the actual capability set.
Generated code should enter the same change-management path as human-authored code. Developers remain accountable for understanding material behavior before approval. Reviewers should not assume generated code is safer because it looks conventional or because the assistant provides an explanation.
Increase scrutiny for authentication, authorization, cryptography, secrets handling, deserialization, file access, data validation, command execution, network boundaries, concurrency, infrastructure-as-code, deployment, security controls, and other changes where subtle errors can become high-impact vulnerabilities.
Check whether generated code introduces unnecessary dependencies, abandoned packages, incorrect versions, unexpected licenses, typosquatted names, or APIs that do not exist. Dependency scanners can help, but reviewers should still understand why a new component is required and whether the source is appropriate.
Use existing repository protections: pull requests, required reviews, CODEOWNERS, branch protection, test requirements, static analysis, secret scanning, dependency review, artifact signing or provenance controls where used, and deployment approval. AI should not receive a bypass merely because it accelerates development.
Developer prompts can contain source code, configuration, customer identifiers, credentials, security findings, logs, internal architecture, incident details, proprietary algorithms, unreleased product plans, or regulated information. Safe use requires clarity about what context the assistant receives automatically and what the provider does with that data.
Define prohibited and approved categories and reinforce them technically where possible. Repository-level exclusion, data-loss controls, tenant settings, secrets scanning, permission restrictions, and approved-workspace configuration reduce reliance on memory.
Never use AI as a workaround for existing data controls. If a developer is not authorized to move a dataset into an external SaaS product manually, pasting or automatically attaching it to an AI assistant does not change the authorization.
For sensitive suppliers, use the Vendor Security Questionnaire to capture data handling, access, security, incident, and dependency evidence. Keep supplier evidence linked to the actual tool and enterprise configuration being approved.
The pipeline is where generated code becomes ordinary software and must satisfy ordinary release evidence.
Keep the assistant inside approved repository, data, and permission boundaries.
Developer understands the change; diff and dependency changes are reviewable.
Unit, integration, regression, security, policy, and other relevant checks execute.
Required human or specialist approval applies based on repository risk and ownership.
Normal deployment, provenance, rollback, monitoring, and incident controls remain intact.
Do not create an AI-generated-code label as a substitute for review. Provenance metadata can be useful for learning and measurement, but the final acceptance question is whether the software meets requirements and controls.
An agent that can edit multiple files, execute commands, install packages, open pull requests, call external services, or interact with cloud environments can create operational impact well beyond a code suggestion. Apply least privilege, scoped credentials, isolated execution where practical, explicit confirmation for sensitive actions, and logs sufficient to reconstruct what occurred.
Test failure handling. What happens if a command partially succeeds, a test environment is unavailable, a package installation fails, credentials expire, or the agent receives malicious instructions from repository content or an issue? The agent should not blindly retry destructive actions or broaden its own access to complete the task.
Use sandboxing and disposable environments for higher-risk autonomous work where feasible. Protect production credentials and sensitive administrative paths from agent access unless a use case specifically requires them and the control model has been reviewed.
Useful measures can include review rework, escaped defects, security findings, test coverage for material changes, dependency issues, rollback frequency, incident contribution, cycle time, developer-reported usefulness, and the percentage of generated changes that require substantial correction. Avoid performance targets that reward developers for accepting more AI suggestions.
Run periodic controlled evaluations for the approved assistant or agent against representative repository tasks. Include secure coding, dependency selection, ambiguous requirements, large-context changes, tests, refactoring, documentation, and failed-tool scenarios. Preserve the model/service version and configuration so changes can be compared.
When the provider materially changes model behavior, permissions, data terms, integrations, or enterprise controls, trigger proportionate re-evaluation. The AI Model Evaluation Operations Guide provides a reusable framework for that test evidence.
Last substantive review: September 2, 2026. Adapt controls to the repository, data classification, development environment, supplier, regulatory context, and actual permissions of the AI tool.
Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.