The secure foundation for AI-native software.

A growing share of the world's new code is written by machines. The evidence says those machines produce exploitable software at a rate that has not improved as they have become more capable — and that the open-source substrate they assemble it from is under automated attack aimed specifically at the development toolchain.

For most organisations that is a productivity question. For a government department, a defence supplier, a bank, or an operator of critical infrastructure, it is an accountability question: the software has to be defensible to somebody, and "the model produced it and the scanner passed it" is not a defence.

This briefing sets out the threat, evaluates the controls in common use today and where they run out, works through the typical workloads in five sectors, prices the decision, compares Kasuri directly against the stacks you run, and describes an approach in which the guarantee is a property of the language rather than an outcome of inspection.

1. Part I — The case
2. 01 Executive overview The argument, the evidence, and what it means for organisations that must defend their software to someone.
3. 02 The threat landscape Seven documented attack classes against machine-authored software, with the incident record behind each.
4. 03 Why current controls fall short What today's control set does well, and the structural limit each one hits under machine authorship.
5. 04 The approach in brief The central mechanism stated once, and the properties that fall out of it without further work.
6. Part II — Sector applications
7. 05 Agencies, retail and commercial operations Client platforms, marketplace and channel operations, retail and internal tooling — threats, current controls, and what changes.
8. 06 Government and public services Citizen services, case management and cross-department data sharing — threats, current controls, and where they run out.
9. 07 Defence and national security Mission support, coalition data handling and sovereign toolchains — threats, current controls, and what changes.
10. 08 Financial services Payments, ledgers, regulated reporting and customer platforms — threats, current controls, and what changes.
11. 09 Critical infrastructure and regulated industry Energy, water, transport, health and industrial workloads — threats, current controls, and the longevity problem nobody has solved.
12. 10 The cost case A cost model with the drivers compared across stacks — and an explicit statement of which figures are measured and which are targets.
13. Part III — The platform
14. 11 How Kasuri compares Kasuri against TypeScript, Python, Java/C#, Go and Rust on the properties that matter for assurance — including where the incumbents win.
15. 12 Authority as a checked property How explicit authority works, the properties it establishes, and the budget that constrains it.
16. 13 One program, one boundary set Why deriving the tier boundary is a security property before it is a productivity one.
17. 14 The compiler as reviewer Diagnostics as a versioned protocol, and the measured size of the repair lever.
18. 15 The supply chain as a language problem What a toolchain must be structurally unable to do, and why each refusal cannot be a setting.
19. 16 Assurance, evidence and audit The trusted computing base, differential checking, reproducible builds, provenance and exportability.
20. Part IV — The programme
21. 17 How the work is held to account The governance model — and why it is a working demonstration of the thesis rather than a description of it.
22. 18 The depth of the work The artifact base — what has been built, measured and written down, and how to inspect it.
23. 19 Stages and gates The staged plan, the gate on each stage, and the criteria capable of ending the programme.
24. 20 Engaging with the programme What is available today, what is being asked for, and what would waste your time.
25. 21 Notes and sources The full source apparatus for the figures used throughout.