- Home
- CMMC & Cyber
- ASE for the DIB
Machines are writing the code.
The governance hasn't caught up.
ASE — Agentic Solution Engineering — governs how AI generates the software inside your systems, and produces the provenance to prove it. Built for the defense contractors whose products contain the code they ship.
The same governed loop drafts the program documents that describe those systems — PPP and SCG — with your designated markings applied deterministically.
Illustrative trace — control IDs shown for orientation, not a live attestation artifact.
A new seam, exactly where the code is written
NIST 800-171 control 3.13.2 asks you to employ software development techniques that promote effective information security. For decades that meant secure coding standards, architecture review, and a human you could point to.
Now a growing share of the code inside CUI-handling systems is written by AI agents — and the generation step itself is ungoverned and unattestable. Your secure-development evidence still stops at the human. The code doesn't anymore.
This isn't a finding. It's a seam your current evidence doesn't cover — and whoever notices it first asks the question you can't yet answer: if an agent wrote it, can you show how?
The requirements are moving toward governed generation
Secure development technique
The control is medium-agnostic. It doesn't care whether a person or a model wrote the code — only that the technique promotes effective information security. Governed generation is how you satisfy it where the code is actually being written.
The federal attestation
Selling software to federal agencies can require a secure-software-development self-attestation (EO 14028 / CISA Common Form). The 2025 rollback trimmed the expansion, not the baseline — and a false attestation is a False Claims Act problem, enforced after the fact. Provenance from the generation step is what makes it defensible for AI-written code.
Guidance is still settling
Formal secure-development guidance for AI-generated code is still settling — but the direction is unmistakable. Being ready before it lands beats scrambling after it does.
Get ahead of where the standard is going — not patch a finding after it arrives.
Govern the generation. Attest the result.
The technique, applied to the machine
ASE points the agent at the authoritative source, enforces the secure-engineering technique through the generation loop, and gates the result against the controls that apply. The governance isn't a log that an agent ran — it's the secure-development technique itself, applied to the thing now doing the writing.
Provenance as the only proof that exists
Every generated artifact carries its lineage: the source it came from, the technique that produced it, the control it maps to, and a signed attestation. When the developer was a person, a review log was your proof. When the developer is a model, provenance is the proof.
The code isn’t the only deliverable an agent can produce for a program. ASE runs the same governed loop over Program Protection Plans and Security Classification Guides — drafted against the authoritative source, gated for human review, and emitted with your program’s designated markings applied deterministically to every page. The markings are mechanical; what is controlled is your program’s call, not ASE’s. The draft arrives with the same lineage and the same signed attestation as the code.
Provenance is not a rubber stamp. An attestation is only as strong as the governance behind it — which is the point. The technique has to actually enforce secure engineering, not merely record that code was generated. ASE is built so the attestation means something.
Watch the technique make the right call
In the Box2D-NG repair, a governed agent faced two paths: an obvious damping fix, and a harder foundational one in the solver. Pointed at the authoritative source and held to the governed loop, it chose the foundational path — and the damping bug resolved as a byproduct.
That is 3.13.2 as an outcome, not a policy PDF: a secure-development technique making an engineering judgment you can trace, review, and attest. The whole arc is on the record, step by step.
Built for the software-writing edge of the DIB
If your CUI-handling systems contain code your team writes — integrators, product shops, embedded and platform developers — this is your seam, and 3.13.2 is where it lives. If you don't ship code, your 3.13.2 story is about architecture, not generation, and the seam above isn't yours. We'll tell you that plainly — though if your program still produces PPPs and SCGs by hand, the document surface stands on its own.
A secure-development technique for AI-generated code, and the provenance behind it. It makes your strongest control provable at the layer your current evidence can't reach.
A compliance determination. ASE doesn't assess you or decide whether you've met a control — you own your attestation. What ASE does is make it defensible.
Bring one system where AI is writing your code.
We'll walk the seam with you on a real system inside your boundary — and show you the provenance that closes it. No platform to buy first.