Pentagon Introduces 3 Checks for Every Piece of AI-Generated Code

An AI agent updated a library, fixed the build, and opened a merge request in a minute. The patch looks tidy, and the tests appear green at first glance. But who is accountable if the agent quietly weakened an access-rights check? And can anyone determine six months later which model made the change and who authorized its release?

The new U.S. Department of War Instruction 8430.01 answers bluntly: code created or modified by AI is considered unverified until the team confirms its quality. Developers remain responsible for the security, functionality, and integrity of the result. Critical functions require human approval.

The rule applies to the department's organizations and to acquisition programs that include software. But the approach is useful to any company that already lets agents into its repositories: the speed of code generation is no substitute for evidence that a change is safe.

What Exactly Must Be Proven

The instruction boils AI work down to three practical requirements.

First, traceability. The team must understand where AI took part, which model and version were used, and what actions the agent performed. A "made with AI" label alone is not enough. The history must link the change to a specific process and the person who launched it.

Second, verification. Agent code goes through the same tests, dependency analysis, vulnerability scanning, and approval rules as human code. For functions on which system safety or human lives depend, the final decision is made by a designated specialist.

Third, data boundaries. Prompts, source code, and non-public information must not be sent to an external model without review. An organization must define in advance the permitted models, where they run, and the data retention rules.

What This Looks Like on an Ordinary Patch

Suppose an agent proposes updating an authorization library. A sound process looks like this: the agent creates a separate branch and a merge request; the log records its service account and the developer who assigned the task; the pipeline runs tests, dependency analysis, and security scanning. Because the change touches a protected area, the system requires approval from a responsible engineer. The agent can fix a flagged error, but it cannot lift the block itself and push code to the main branch.

Such a process doesn't prohibit autonomy. It sets its limits. An agent can be tasked with finding updates, preparing a patch, and rerunning checks. The right to merge or release depends on risk: a documentation fix can go through automatically, while an authorization change goes only through a human.

GitLab presents its own platform as a way to implement these requirements: audit logs, protected branches, approval rules, dependency scanning, and a self-hosted model gateway. It is a useful example, but the source remains commercial material. The instruction describes requirements and does not oblige anyone to use GitLab; the same principles can be built in GitHub, Azure DevOps, or an in-house system.

What to Change in Your Development Process

Start not by choosing yet another AI tool, but with a map of authority. Record which repositories and data the agent can access, which actions it performs on its own, and where it must stop. Identify protected branches, critical files, and release operations. Assign owners and mandatory checks to them.

Then add the provenance of changes to the audit log: the model, its version, the agent's service account, and the human initiator. Don't rely solely on a comment in the merge request — it is easily lost and poorly suited to an investigation.

The main takeaway is simple: AI speeds up writing a patch, but it does not shift responsibility from the team to the model. If a company can't show who launched the agent, what exactly was checked, and who authorized the release, it doesn't yet have managed AI development, but a fast generator of technical debt.