NIST SSDF Implementation When AI Agents Are Part of Your Build

NIST Special Publication 800-218 (Secure Software Development Framework / SSDF) is the de facto federal standard for software development security. Since Executive Order 14028 made SSDF self-attestation mandatory for federal software procurement, vendors shipping software to US government agencies sign the CISA Secure Software Development Attestation Form confirming their development process aligns with the SSDF practices.

But SP 800-218 v1.1 was published in February 2022, before autonomous coding agents entered production. The gap between "humans write code, humans review code" (the assumption baked into SSDF) and "agents write code, agents review code, humans may or may not review" (the reality today) is creating compliance confusion.

NIST has begun addressing this gap in two adjacent publications:

• SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: A Community Profile (final, July 2024). The closest real NIST document to "SSDF for AI." It is a profile of SSDF practices applied to generative-AI software, not a fifth practice group.
• NIST AI Agent Standards Initiative — announced 17 February 2026 by NIST's Center for AI Standards and Innovation (CAISI). NIST has stated an "AI Agent Interoperability Profile" is planned for Q4 2026 — it is not yet published.
• NCCoE concept paper — Accelerating the Adoption of Software and AI Agent Identity and Authorization (initial public draft, 5 February 2026; comment period closed 2 April 2026).

There is no document called the "NIST Agentic Profile," despite frequent secondary-source references. Until NIST publishes the planned interoperability profile, the closest applicable NIST text for AI-augmented SSDF is SP 800-218A.

Here is how to interpret SSDF when agents are part of your development pipeline, mapped to the actual practice taxonomy.

SSDF at a Glance: The Four Practice Groups

SP 800-218 v1.1 organises practices into four groups (not five — there is no "RCP" group, and release controls are split between PS, PW, and RV):

Each practice has tasks and notional implementation examples. SSDF v1.1 does not have a maturity-level model — there are no Level 1 / Level 2 / Level 3 ratings. The maturity-level language sometimes attached to SSDF is borrowed (often unintentionally) from SLSA, CMMC, or NIST CSF tiers. If you need a maturity dimension, point at NIST CSF tiers or AI risk maturity in NIST AI 600-1, not at SSDF itself.

Federal procurement does not require a particular SSDF "level." Vendors complete the CISA SSDF Self-Attestation Form affirming that their development process aligns with the SSDF practices applicable to the product.

How AI Agents Change Each Practice

PO.1: Define Security Requirements for Software Development

SSDF text (paraphrased): Define security requirements for the software, the development infrastructure, and any third-party components.

With AI Agents: Add these requirements to the security-requirements register:

• An inventory of every AI tool or coding agent in the development pipeline (Copilot, Cursor, Claude Code, custom agents, model APIs).
• For each agent: what permissions does it have? Can it execute code? Can it call external services? Can it touch production?
• Risk acceptance for AI-generated code: who signs off? Under what conditions can an agent commit to which paths?
• Insurance and liability review — does your E&O policy cover AI-generated code?

Compliance evidence:

• Tool inventory document
• Risk register entry per agent
• Insurance policy review record

PO.2: Implement Roles and Responsibilities

SSDF text (paraphrased): Identify roles and responsibilities for everyone involved in the SDLC; train them.

With AI Agents: Add:

• A defined role and accountability for the human reviewer of AI-generated code — not "whoever happens to be on rotation."
• Training on prompting agents securely (avoiding secret leakage, proprietary patterns, and prompt-injection attack surfaces).
• Training on reviewing AI-generated code (static analysis is not enough; LLMs reliably produce plausible-looking off-by-one and authentication errors).
• Process for tagging AI-generated code in version control so every reviewer knows what they are reviewing.

Compliance evidence:

• Role and responsibility matrix listing AI-reviewer responsibilities
• Course completion records
• Internal policy document on agent use
• Audit log showing developers tagged AI-generated commits

PO.3: Implement Supporting Toolchains

SSDF text (paraphrased): Use automation; harden the toolchain itself.

With AI Agents: The agent platform is now part of the toolchain.

• Treat the agent runtime, the model API, and the agent's tool surface as toolchain components subject to PO.3 hardening.
• Network egress controls on the agent (allowlist of model and tool endpoints).
• Audit logging on every agent invocation.
• Version-pin agent runtimes the same way you version-pin compilers.

Compliance evidence:

• Toolchain component register including the agent platform
• Egress allowlist configuration
• Agent invocation log

PO.5: Implement and Maintain Secure Environments for Software Development

SSDF text (paraphrased): Separate development environments from production; secure them.

With AI Agents: Agents must respect the same boundaries.

• Agent service accounts limited to development and staging.
• No agent credentials with production write access.
• Audit logs proving the boundary held.

Compliance evidence:

• IAM policy showing agent service accounts have zero production write permissions
• Quarterly review of agent permissions
• Audit log review

PS.1: Protect All Forms of Code from Unauthorized Access and Tampering

SSDF text (paraphrased): Restrict who can change source, configurations, and artefacts. Tamper-evident storage.

With AI Agents: Agent commits are still commits.

• Agent commits go through the same branch protection, signed-commits, and approval rules as human commits.
• Agent service accounts have keys (or short-lived tokens) managed and rotated like any other identity.

PS.2: Provide a Mechanism for Verifying Software Release Integrity

SSDF text (paraphrased): Provide a way for consumers to verify the integrity of releases (signing, hashes, attestations).

With AI Agents: This is the practice that owns build provenance and provenance attestation.

• Build provenance must include agent identity and version:
  • Which agent? (GitHub Copilot Coding Agent? Cursor? Claude Code? Custom agent?)
  • Which version? (Models update frequently)
  • Which commit triggered the agent? (Reproducibility)
  • Which model parameters were used? (Temperature, max tokens — where these meaningfully affect output)
• SLSA provenance attestations should be co-signed by a human accountable reviewer where the artefact contains agent-authored code.
• Store attestations in an auditable transparency log (Sigstore Rekor recommended).

Standard SLSA attestation format + AI-metadata extension:

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "api-gateway:v2.14.1",
    "digest": {
      "sha256": "abc123..."
    }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://your-org.com/agent-assisted-build-v1"
    },
    "metadata": {
      "invocation": {
        "parameters": {
          "agents_involved": true,
          "agent_summary": "Copilot Coding Agent generated 3 of 47 commits",
          "agent_commits": [
            "abc123...", "def456...", "ghi789..."
          ],
          "reviewed_by": ["[email protected]", "[email protected]"]
        }
      }
    }
  }
}

Sign with Sigstore (keyless signing). Store in Rekor.

Compliance evidence:

• Signed SLSA provenance attestation per release
• Sigstore Rekor entry per artefact
• AI-attribution metadata visible in the predicate

PS.3: Archive and Protect Each Software Release

SSDF text (paraphrased): Archive each release with everything required to verify the integrity of the release in the future.

With AI Agents: The archive must include the agent metadata too, so a future investigation can answer "which agent generated this commit, and what was the reviewer's record?" without relying on live systems.

PW.1: Design Software to Meet Security Requirements and Mitigate Security Risks

SSDF text (paraphrased): Design with security requirements in mind. Threat modelling.

With AI Agents: Update the threat model.

• Add AI-specific threat sources: prompt injection of code-generating agents; agents leaking secrets back to the model API; agents executing destructive tool calls.
• Identify "human-only zones" — code paths where agents may not author commits (typically: authentication, cryptography, access control, payment processing).
• Threat model must explicitly note the assumption: "agents may introduce vulnerabilities, not prevent them."

Compliance evidence:

• Threat model document with AI-specific threat sources
• Architecture diagram marking "agent-authored zones" and "human-only zones"

PW.4: Reuse Existing, Well-Secured Software

SSDF text (paraphrased): Manage third-party components; track dependencies.

With AI Agents: Two layers.

• Agents themselves are dependencies — track agent versions and update schedules like any other tool.
• Agents may also generate or update your dependencies. Dependency-update tooling (e.g. Dependabot-style bots, agent-driven dependency upgrades) must be flagged in commit metadata so dependency review knows whether a human or an agent proposed the bump.

Compliance evidence:

• Agent inventory with versions
• Dependency update log with author type (human / agent)

PW.7: Review and/or Analyze Human-Readable Code for Security Vulnerabilities

SSDF text (paraphrased): Have qualified people review the code; use automated analysis.

With AI Agents: This is where the complexity sits.

What counts as "review"?

• Human review of agent-generated code: satisfies PW.7. (Same standard as human-on-human review.)
• Agent review of human code: counts as tool-assisted analysis under PW.7, but does not replace human peer review where your policy requires it.
• Agent review of agent code: not addressed by SP 800-218 directly. Crash Override recommendation: require human sign-off where the change touches a security-critical path. NIST has not codified this requirement; it is internal policy.

Best Practice (Crash Override recommendation, not codified in SSDF):

Compliance evidence:

• Code review checklist that distinguishes agent vs. human-authored changes
• Audit log showing every agent-generated PR had human approval before merge
• Metrics: % of merges that were agent-generated; % of those that had human review

PW.8: Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements

SSDF text (paraphrased): Test for security: SAST, DAST, dependency scanning, fuzzing where appropriate.

With AI Agents: Tighten what you test, and instrument the difference.

• Tighten SAST severity thresholds for agent-generated changes (LLMs reliably produce high-confidence-looking but subtly wrong code).
• Dependency scanning must flag when AI agents modified dependencies.
• DAST coverage should include agent-generated endpoints — agents tend to skip edge-case input validation.
• Fuzz agent-generated parsers — LLMs frequently emit off-by-one errors in parsing logic.

Metrics worth tracking separately for agent vs. human code:

• Vulnerabilities per line of code
• Test coverage
• SAST false-positive rate
• Time-to-fix for vulnerabilities

Compliance evidence:

• SCA scan reports with agent-code flagged
• SAST rule set tuned for agent-code review
• Test coverage reports broken down by author type

PW.9: Configure Software to Have Secure Settings by Default

SSDF text (paraphrased): Ship with secure defaults.

With AI Agents: Verify that agent-generated configuration code does not silently flip defaults to permissive. This is a known LLM failure mode (e.g., suggesting Access-Control-Allow-Origin: * because that "fixes the CORS error in the test").

RV.1: Identify and Confirm Vulnerabilities on an Ongoing Basis

SSDF text (paraphrased): Have a vulnerability disclosure process; monitor for new vulns in the released product.

With AI Agents: When a vulnerability is reported, the investigation must be able to determine whether the affected code was AI-generated and who reviewed it. The release archive (PS.3) must contain enough metadata to answer this without forensics.

Compliance evidence:

• Vulnerability triage record linking the affected code to its author type and reviewer

RV.2: Assess, Prioritize, and Remediate Vulnerabilities

SSDF text (paraphrased): Triage, fix, and verify the fix.

With AI Agents: A patch authored by an agent should be flagged and held to the same review standard as the original code (typically: human review for security-critical paths). A patch authored by a human in response to an agent-introduced vulnerability is fine to ship.

RV.3: Analyze Vulnerabilities to Identify Their Root Causes

SSDF text (paraphrased): Look upstream — what process let this in?

With AI Agents: Add an agent-aware root-cause taxonomy. "Agent suggested an insecure pattern that the reviewer did not catch" is a different root cause from "Developer wrote insecure code." The remediation is also different (model prompting changes, reviewer training, scope restriction on the agent).

What's Coming from NIST (Real, Not Invented)

Two adjacent NIST work streams will shape AI-augmented SSDF over 2026–2027. None of them is published as a standard yet:

1. SP 800-218A is published (July 2024) and is the operative AI-related SSDF profile today. It applies SSDF practices to generative-AI software development — governance of training data, model artefacts, and the SSDLC for the model itself. If your team is building or fine-tuning models, this is the actual document to read.

2. NIST AI Agent Standards Initiative (CAISI, announced 17 February 2026) is convening industry to develop measurement and standards for AI agent reliability, security, and interoperability. NIST has stated an AI Agent Interoperability Profile is planned for Q4 2026.

3. NCCoE concept paper — Accelerating the Adoption of Software and AI Agent Identity and Authorization (initial public draft, 5 February 2026; comment period closed 2 April 2026) — addresses agent identity and authorisation, particularly relevant to SSDF practices PO.5 and PS.1.

The themes likely to land in those documents (based on the NCCoE concept paper and CAISI's published direction) include:

• Agent identity and authentication (agents must have identifiable identities, not generic automation accounts)
• Least-privilege tool access
• Delegation chain accountability (Agent A invoking Agent B must be logged at both ends)
• Runtime behavioural governance (constraints on what agents may do)
• Prompt-injection threat modelling
• Cascading-failure isolation across multi-agent systems

These are sensible to design for now. They are not mandatory for SSDF compliance today, and they have not been published by NIST as enumerated requirements. Plan for them; do not cite them as if they were already codified.

Implementation Checklist

To align with SSDF when shipping agent-assisted development:

• Inventory all AI tools in use (including shadow agents)
• Documented policy on which code paths agents may touch (and which are human-only)
• SBOM generation at build time with AI-attribution metadata
• Code review process that explicitly marks and tracks agent-generated commits
• Tighter security testing on agent code (SAST thresholds, coverage, fuzzing parsers)
• Provenance attestations including agent identity, model version, and reviewer approval
• Metrics dashboard tracking agent vs. human code (defect rate, time-to-fix, review coverage)
• Training records demonstrating reviewers understand AI-code review requirements
• Release process requiring explicit approval for agent-generated code in critical paths
• CISA SSDF Self-Attestation Form completed and on file

To prepare for the AI Agent Interoperability Profile (planned Q4 2026):

• Agent authentication framework (agents have identities, not generic automation)
• RBAC for agents (service accounts with scoped permissions)
• Prompt-injection threat-model coverage
• Behaviour monitoring for agents (CPU, memory, API call budgets)
• Kill switches (ability to terminate any agent immediately)
• Read SP 800-218A; comment on the next NCCoE / CAISI drafts as they appear

References

• NIST SP 800-218 v1.1 — Secure Software Development Framework (Feb 2022) — The operative SSDF
• NIST SP 800-218A — SSDF Generative AI / Dual-Use Foundation Model Profile (July 2024) — The closest real NIST AI-augmented SSDF text
• NIST CSRC SSDF project page — Project hub including the Rev 1 / v1.2 initial public draft
• NIST AI Agent Standards Initiative (CAISI, Feb 2026) — The actual February 2026 NIST work on AI agents
• NCCoE concept paper — Accelerating the Adoption of Software and AI Agent Identity and Authorization (initial public draft, 5 Feb 2026) — Agent identity and authorisation
• CISA Secure Software Development Attestation Form — The actual federal procurement self-attestation
• EU AI Act — General-Purpose AI Code of Practice (10 July 2025) — International regulatory context
• Sigstore Documentation — Attestation tooling