AI coding agents do not create a new framework, but they change how you meet an existing one. If you follow NIST's Secure Software Development Framework, update review, tooling, and provenance practices so they cover code and dependencies that an agent produced, and record who approved each change.
What the SSDF is
NIST SP 800-218, the Secure Software Development Framework version 1.1, was published in February 2022. NIST describes it as a core set of high-level secure software development practices that can be integrated into any software development life cycle. Its stated goals are to reduce vulnerabilities in released software, limit the impact of those that go unaddressed, and address root causes. It also gives purchasers and suppliers a common vocabulary.
NIST also lists SP 800-218A as a related part of the publication. The page that lists it does not describe its contents, so read it directly before citing it.
Why agents matter to a practice set
The SSDF is outcome oriented. It does not say who or what writes the code. That is useful: your practices apply to agent output as much as to human output. The question is whether your evidence still tells a true story.
Where to look in your own practices
| Area of your program | Question for agent use | What to update |
|---|---|---|
| Roles and responsibilities | Who is accountable for agent produced changes? | Name the launcher as author of record, a human as reviewer |
| Toolchain definition | Is the agent part of your approved toolchain? | Add it to the tool inventory, with an owner and a review date |
| Secure environments | Where does the agent run, with which credentials? | Document sandbox and credential rules |
| Code review | Does review account for agent specific mistakes? | Add checks for new dependencies, weakened tests, and edits to pipeline files |
| Third party components | How are agent chosen packages vetted? | Gate new dependencies by policy and scan |
| Provenance | Can you tell which changes came from an agent? | Label agent pull requests and keep the action log |
| Vulnerability response | Can you trace a flaw back to its origin? | Preserve links between commit, session, and agent version |
Treat the table as a prompt for your own mapping. The exact practice identifiers belong in your own document, so quote them from the NIST text rather than from memory.
Evidence to keep
Auditors and customers rarely ask about agents specifically. They ask whether your process is followed. Useful evidence includes:
- The approved tool list with dates.
- The policy for agent permissions and approvals.
- A sample of agent pull requests with reviewer records.
- Gate results for dependencies on those pull requests.
- Log extracts showing an action blocked by policy.
Be careful with claims
Aligning your practices with a framework is different from being certified against it, and the SSDF is a set of practices, not a certification. Say "we follow practices drawn from the SSDF" only if you can show them. If you answer a buyer's questionnaire, our post on answering whether you follow a secure development framework covers wording. For customers who ask about federal software attestation, check the current instructions from the requesting agency rather than assuming what applies.
A practical first step
Pick three recent agent pull requests and trace them through your practice list. Where the trace breaks, you have found what to update. Fix those gaps first, then write the policy language.
Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
A worked example: tracing three agent pull requests
A team picks three recent agent pull requests and checks whether their documented practices hold up.
| Pull request | Question | Result | Gap |
|---|---|---|---|
| Library upgrade | Was a human reviewer recorded? | Yes | None |
| Library upgrade | Was the new version checked by policy? | Yes, a dependency check ran | None |
| Test addition | Was the agent identified as a source? | No label | Add automatic labeling |
| Config change | Was the change linked to a ticket? | No | Require ticket in template |
| Config change | Did a second person approve? | Author approved own work | Enforce branch protection |
| Refactor | Is the agent tool on the approved list? | Not listed | Add inventory entry |
The exercise took an hour and produced four concrete fixes. Notice that none required a new framework or tool. They required making existing practices cover agents.
Writing the update
For each gap, write the fix in the language of your own practices. For example, if your practice says "all changes are reviewed by a second person", add: "This includes changes produced with AI assistance. The person who launched the assistant is the author." If your practice says "approved tools are maintained in an inventory", add the agent tools, their owners, and their review dates.
Keeping the claim honest
Your claim should match what you can show. Compare these statements.
| Statement | Fair? |
|---|---|
| "We follow practices drawn from the SSDF and can show evidence for each" | Fair if true and demonstrable |
| "We are SSDF certified" | Not fair, because the SSDF is a set of practices and not a certification |
| "Our AI tools comply with the SSDF" | Vague, avoid |
| "AI assisted changes follow the same review and testing steps as other changes" | Fair if sampled |
Avoid saying that a federal attestation form is required for your customers unless the requesting agency states so in writing. Ask the customer which documents they want and respond to that.
Evidence package
- Your inventory of approved agent tools with owners and dates.
- Your policy on agent permissions and approvals.
- A sample of agent pull requests with labels, reviewers, and check results.
- A log extract showing a blocked action.
- The scorecard or record from your last tool evaluation.
Cadence
Review these items every quarter, and after any change in your toolchain. Keep the sample fresh, because a six month old example looks stale to a reader.
Where to read next
Read the NIST publication directly for practice wording, and ask your auditor or customer which parts they care about. A framework is a shared vocabulary, so use the vocabulary the reader brings.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice how practices map to evidence.
Quick check
Does the SSDF mention AI coding agents?
Version 1.1 of SP 800-218 predates the current wave of agents. NIST lists SP 800-218A as a related part, so read it directly for what it covers.
Is following the SSDF a certification?
No. It is a set of practices. Do not describe alignment as certification.
Do we need a separate policy for AI coding agents?
Often a short addendum is enough, covering ownership, permissions, and logging, while the main practices stay the same.
Sources
Last reviewed: 19 October 2026.
