Kasuri

Chapter 07 · Part II — Sector applications

Defence and national security

Where the adversary is resourced, patient, and specifically interested in your toolchain — and where "we scanned the output" has never been an adequate answer.

Audience
Defence digital leadership, security accreditors, capability programme owners
Chapter
7 of 21

Defence has spent decades building assurance for systems whose adversary is a state. What is new is not the threat actor's capability but the arrival of a delivery model in which the software is written by a component that can be given instructions by anyone whose text it reads.

Section 01Typical workloads

Mission support and back office
Personnel, tasking, readiness reporting, maintenance scheduling, medical and welfare systemsUnglamorous, numerous, frequently the softest route into an estate, and the first place AI-accelerated delivery gets applied because the requirements are well understood.
Logistics and sustainment
Supply chain visibility, spares, movement planning, contractor interfacesAggregating logistics data is itself intelligence. The classification of the whole frequently exceeds the classification of any part.
Command support tooling
Planning aids, common operating picture feeds, decision-support and reporting layersIncreasingly assembled quickly against changing operational requirements, which is exactly the pressure that produces shortcuts.
Coalition and partner sharing
Releasability, caveats, national eyes-only handling, partner-nation interfacesEnforced today by process, marking discipline and cross-domain solutions at the boundary — rarely by anything inside the application.
Edge and rapid capability
Tools built in weeks against an operational need, deployed to constrained environmentsThe workload with the least assurance headroom and the highest incentive to use whatever writes code fastest.

Section 02The threat picture

  • The toolchain as the target. A supply-chain compromise is inherited by everything built afterwards, which makes it the highest-leverage target available to a resourced adversary. The public record already shows worms that self-replicate without any command channel and campaigns that turn installed coding assistants into credential harvesters.[6][7] Those were criminal operations. The techniques are not reserved.
  • Model supply chain. Roughly 250 malicious documents can backdoor a model regardless of its size, and a code backdoor conditioned on a trigger survives fine-tuning, reinforcement learning and adversarial training — with robustness increasing with scale.[11] For a state adversary that is a viable, deniable, and extremely patient implantation route. No procurement control reaches it; only verification of the output does.
  • Injection into classified authoring environments. Prompt injection has no clean fix, and the injected content does not need to come from the internet — a ticket, a requirement document, a captured artifact under analysis, or a partner-supplied interface specification will do.[4]
  • Aggregation and releasability failure. Code that can reach two datasets can combine them. Where releasability is enforced by process rather than by construction, the failure surfaces as a report that should never have existed.
  • Insider, assisted. The classic insider problem acquires a new tool: an authoring agent with broad ambient authority is an insider that does not need to be recruited, and whose actions look like ordinary development activity.
  • Sovereignty of the build. Where the toolchain, its dependencies and its build infrastructure sit outside national control, the assurance argument has an unowned link in it.

Section 03What is used today, and where it runs out

Current control set against defence software delivery
ControlWhat it coversWhere it runs out
Accreditation and security casesRigorous, owned, documented risk position for a defined systemAssumes a rate of change a human gate can absorb; continuous machine-authored change breaks the assumption rather than the process
Air-gapped or enclave developmentRemoves the network as an exfiltration path during developmentDoes not address what the delivered code can reach, and injected content arrives inside the enclave in ordinary work products
Cross-domain solutionsStrong enforcement at a domain boundaryEnforces at the boundary; inside a domain, an application that can reach two datasets can still combine them
Secure coding standardsCodifies known-good practice and gives review something to check againstAdvisory. Generated code chose the insecure option ~45% of the time where a secure one existed[2]
Formal methodsThe strongest assurance available, and genuinely decisive where appliedEconomically confined to small, stable, critical kernels. It does not reach the volume of ordinary mission-support software
Independent verification and validationAdversarial human scrutiny by a party with no delivery incentiveCapacity. Machine-authored change outpaces it, and automated substitutes hit a measured false-positive ceiling[10]

Section 04What changes

The blast radius of a compromised author is bounded by construction

This is the property that matters most here. Assume the authoring agent is under adversary influence on any given run — which is the only assumption that stays valid as models improve. If every authority must be explicitly granted, an influenced author cannot reach a dataset it was not given, cannot read a credential that is not a string anywhere, and cannot install a component that does not resolve. It can write hostile code; it cannot obtain the authority to make that code do anything.

Releasability becomes a type-level property

Where handling constraints are carried by the data and enforced by the compiler, a build that would combine two datasets across a caveat boundary does not produce a warning. It does not build. That moves caveat enforcement from marking discipline — which depends on people being careful — to a property of the artifact.

The verifier is the backstop against a compromised model

You cannot procure your way out of a backdoored model. What you can do is ensure that a triggered vulnerability still has to pass a sound checker and an exploit probe to reach a build. That is the only control that operates downstream of the model supply chain, and it argues for a verifier that is sound rather than advisory — and small enough to be audited.

The trusted base is nameable

The programme's constraint set fixes the trusted computing base at five enumerable items and sizes them, with a second independent checker running differentially — built by a different model family, in a different implementation language, prompted only from the specification — and bit-reproducible releases so that a third party can rebuild and compare. For an accreditor, that converts "trust the vendor's verifier" into a reviewable artifact and an independent reproduction.

Sovereignty has somewhere to attach

A build that executes nothing a dependency supplied, resolves names against a verified log, and is reproducible from source is a build whose provenance can be established nationally without trusting the infrastructure it happened to run on.

Section 05Questions worth asking any capability supplier

  • If the coding agent used to build this were following an adversary's instructions, what specifically would stop it — and is that a property or a procedure?
  • Can you enumerate, mechanically, every dataset this component is capable of reaching?
  • What executed during your build with what authority, and can we reproduce your artifact independently?
  • What enforces caveat and releasability inside the application, as opposed to at the domain boundary?
  • If your model supplier were compromised, which of your controls would still be standing?
  • How much of your assurance survives a delivery rate ten times higher than today's?
Programme stage and honest scope

Kasuri holds no security certification, accreditation, clearance or approval of any kind, in any jurisdiction, and has no defence deployment or engagement. It is at specification stage ahead of a reference implementation.

This chapter describes design intent evaluated against a documented threat picture. It is included because the properties above are decided now, at specification stage, and are far cheaper to get right before an implementation exists than after. Chapter 20 describes what engaging at this stage does and does not mean.