Coding agents now do much of the work of building software. They plan changes, edit files, add packages, run tests, and open pull requests. Somewhere in that loop, an agent decides which open source components your mission software will depend on, often without a person reviewing each choice.
Sonatype recently argued that teams using agents need to answer three questions: which agent introduced a dependency, why it is there, and who owns it now.
For Department of War (DoW) programs, those questions picked up policy weight on September 8, 2026. That is the effective date of DoW Instruction (DoWI) 8430.01, Accelerated Mission Software. Six weeks earlier, the Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and the Federal Bureau of Investigation (FBI) and 15 international partners published the 2026 Minimum Elements for a Software Bill of Materials (SBOM).
The instruction is binding policy for DoW Components. The CISA document is voluntary guidance that 8430.01 does not cite, but both push in the same direction. Read together, the two documents turn agent dependency decisions from an engineering concern into an accountability question that reaches every role in a program.
8430.01 does not treat AI as a risk to be contained. It calls AI-assisted development a significant force multiplier and says DoW Components should use it to accelerate capability delivery.
The same section sets the terms. AI-generated code is to be considered unverified input. Developers and teams remain fully accountable for anything an AI produces. AI-written code, scripts, and tests go through the same or similar review and security testing as code written by people, including a check of license obligations.
That pairing matters. The instruction wants programs to move faster, and it wants them to automate testing, scanning, and compliance checks as continuous activities rather than final gates. But it does not relax accountability to get there. It expects the evidence to keep pace with the speed.
When an agent adds five dependencies in an afternoon, the program has five more components to inventory and assess. The instruction does not explicitly require teams to log which agent selected each dependency or why, but that information can help teams understand and manage those decisions. It does require approved AI tools to allow auditing and monitoring of their use, which is where that record can start.
Under 8430.01, evidence is not paperwork after the fact. It is the condition for running software on DoW networks and systems. All software operated there must be supported by machine-readable evidence of what it contains, how it was built, and how it was secured.
For a dependency an agent selects, the instruction spells out what that evidence must address. Every third-party component is assessed for six risk factors:
Sustainment: Is the project stable, active, and supported?
Source trustworthiness: Can the distribution source and provenance be trusted?
Dependencies: What security and license obligations come with its subcomponents?
Security posture: Does the developer manage and fix vulnerabilities in a timely way?
Integrity protections: Are releases signed, and are builds reproducible?
Foreign influence: Could an adversary own, fund, contribute to, or control the project?
Non-trivial open source components get a closer look at their governance model, community health, and license risk.
A model relying on training data alone cannot reliably answer current-state questions like whether a project was abandoned last month or who controls it now. And 8430.01 adds one more item to the record: the models, versions, and significant datasets used to generate the software. The model behind the agent itself is now part of the evidence.
A commercial team can connect its coding agent to a cloud service and let it check packages as it works. Much of the DoW cannot.
8430.01 allows only AI tools authorized through DoW cybersecurity processes, and it bars entering non-public DoW information into generative AI services that do not reside on DoW systems. It requires enterprise tooling to work across classification levels, including disconnected and tactical environments. And it treats SBOMs and build scripts with a military or space application as controlled technical information (CTI), so even a program’s dependency list may need protection.
Inside an enclave, the model has to be installed locally. That might be a fine-tuned open-weight model such as Scale AI's Defense Llama, or a disconnected deployment of a commercial model. Either way, an agent may not be able to check package status as it works. Its training data alone will not tell it about vulnerabilities disclosed later.
The gap is not theoretical. In peer-reviewed 2025 testing of 576,000 code samples, open-weight models recommended nonexistent packages 21.7% of the time and commercial models 5.2%. Attackers register those invented names with malware inside, a technique called slopsquatting. Newer models may do better, but none of them knows about a vulnerability disclosed after it was trained.
The 2026 SBOM Minimum Elements raise the bar on what an SBOM must say about every component, including the ones an agent pulled in on its own.
Several changes matter directly for agentic development:
Coverage now includes all components, transitive dependencies included. A complete SBOM lets you conclude that a newly reported vulnerability does not affect you.
SBOM Author Signature lets a recipient confirm the SBOM was not altered after it was created.
Component Hash Value and Component Hash Algorithm tie each entry to the exact artifact that was built.
SBOM Generation Context records whether the data came from before the build, during it, or after it.
Component Producer must name who made a component, or state that its provenance is unknown.
Explicitly Identifying Unknown Information means a gap must be flagged, not quietly left blank.
The guidance also expects a new SBOM for every build or release. When agents change dependencies daily, that recommendation only works if SBOM generation is automated in the pipeline.
8430.01 supplies the hard requirement. Every third-party component, transitive dependencies included, must appear in the system's SBOM, and the instruction's own definition of an SBOM expects gaps to be stated rather than hidden.
An SBOM still records what is in the software, not why it got there. But the 2026 elements make it much harder for an unverified, agent-selected component to pass as a known one.
No single developer can track every dependency decision an agent makes. 8430.01 keeps developers and their teams fully accountable, and its requirements reach the rest of the program:
Component heads and engineering leaders own the boundaries. The instruction treats continuous integration/continuous deployment (CI/CD) pipelines as critical infrastructure, and an agent that edits manifests and triggers builds is operating inside it. Leaders define the risk-based review that decides which agent changes need human approval, starting with anything security- or safety-critical.
Security leaders and authorizing officials own the evidence. Authorizing officials are directed to accept standard machine-readable evidence such as SBOMs, build provenance, and security scans to grant reciprocity. Signed, complete SBOMs and a record of the models used are what make agent speed authorizable.
DevSecOps and platform engineers own the paved road. Development, security, and operations (DevSecOps) teams are asked to make the secure path the easy path, with dependency scanning built into the pipeline and provenance produced by every build.
Program managers and acquisition professionals own the terms. If a contractor's agents choose components for your program, the contract is where the six risk factors, the CISA 2026 elements, and the model record become enforceable.
The common thread is that each role needs the same foundation: current component intelligence, applied as policy, at every point where a dependency can enter.
Reviewing agent output by hand does not scale on its own. 8430.01 keeps people in the loop, with mandatory human approval for security- and safety-critical changes, and it expects automated, continuous evidence to keep pace with delivery.
The practical answer is to move policy closer to the moment of selection. An agent that can see current vulnerability, malware, license, and project health data before it adds a package reduces the risk of poor dependency choices. A repository firewall blocks known-bad components before they enter. Pipeline policy and SBOM generation add checks and evidence to support assessment and authorization decisions. And in disconnected environments, that intelligence has to live inside the enclave, because the agent cannot reach out for it.
As agentic development spreads across DoW programs, every team should be able to answer three questions from evidence alone: Which agent introduced this dependency? Why is it here? And who is responsible for it now?
Learn how Sonatype helps federal teams govern agent dependency decisions with current software supply chain intelligence, in connected and disconnected environments.