Chapter 06 · Part II — Sector applications
Government and public services
Statutory duties that are architectural rather than procedural, meeting a delivery model that changes faster than accreditation can reassess it.
Public-sector software carries obligations that are unusual in two ways: they are owed to people who did not choose to be your users, and several of them are properties of the architecture rather than of the process that built it. That second point is the one machine authorship makes urgent.
Section 01Typical workloads
- Citizen services
- Eligibility checking, applications, payments, appointment booking, status trackingHigh volume, high scrutiny, and a population that cannot go elsewhere. Failure is a national story rather than a churn metric.
- Case management
- Licensing, immigration, benefits assessment, safeguarding, regulatory caseworkLong-lived records, complex authorisation, statutory retention, and case officers who need exactly the access their role permits and no more.
- Cross-department sharing
- Data shared under specific legal gateways between departments and agenciesThe legal basis is usually narrow and purpose-bound; the technical enforcement is usually a contract and an interface agreement.
- Records and disclosure
- Retention schedules, subject access requests, GDPR erasure, freedom-of-information handlingStatutory obligations over PII that must hold across every derived copy, cache and backup — not just the primary record. Under UK GDPR the obligation is on the controller regardless of how the system was built.
- Legacy modernisation
- Replacing decades-old systems under fixed budgets and political timescalesThe workload most likely to be handed to AI-accelerated delivery, and the one carrying the most accumulated undocumented behaviour.
Section 02The threat picture
- Authorisation error at scale. The characteristic public-sector breach is not an exotic exploit; it is one case worker, one endpoint, or one report seeing records it should not. Generated code chose the insecure implementation about 45 per cent of the time where a secure option existed.[2]
- Purpose-limitation drift. Data shared for one lawful purpose becoming reachable for another, usually through a well-intentioned feature that nobody assessed against the original gateway.
- Erasure that does not reach. A GDPR erasure request satisfied in the primary store while derived tables, search indexes, caches, analytics extracts and backups retain the personal data. The duty is discharged on paper and not in fact.
- Supply chain into the public estate. Departments consume the same open-source graph as everyone else, through suppliers, at a remove that makes the exposure harder to see. Self-replicating package worms and credential-harvesting campaigns do not distinguish sectors.[7]
- Injected authoring agents. Where suppliers use AI coding tools — which is now most of them — the authoring pipeline is a route into the delivery, and prompt injection has no clean fix.[4]
- Residency and sovereignty. Constraints on where data may be processed, enforced today mostly by deployment configuration and supplier attestation rather than by anything the code itself guarantees.
Section 03What is used today, and where it runs out
| Control | What it covers | Where it runs out |
|---|---|---|
| Accreditation and assurance regimes | Forces explicit risk ownership and produces a defensible record | Point-in-time assessment of a system that now changes continuously; the interval between assessments is where risk accumulates |
| Security testing before go-live | Genuine adversarial evidence at a milestone | A sample of a population that is replaced between samples |
| Data protection impact assessment (DPIA) | Forces the purpose and GDPR lawful basis for processing PII to be stated up front | States intent; the code is not bound to it, and drift is invisible until an incident |
| Role-based access control | Expresses who may do what at the application layer | Enforced by code that has to remember to check. Nothing prevents a new endpoint from forgetting |
| Supplier assurance and contractual clauses | Places obligation on the party doing the work | Transfers liability without changing what the delivered code can reach |
| SBOM requirements | Inventory for incident response | Lists components, not their permissions, and cannot see the build |
The common thread: each control produces a statement about the system, and none of them produces a property of it. That distinction was tolerable when change passed through human gates. It is what breaks first under AI-accelerated delivery.
Section 04What changes
Authorisation stops being something code must remember
Where the authority to reach case data is a value scoped at issue — to this officer, this case, this purpose — code holding it cannot name anything outside that scope. A new endpoint added by a supplier's coding agent does not inherit access by being in the same codebase. The failure mode "somebody forgot to check" stops having a way to occur.
The purpose-limitation boundary becomes checkable
When data-sharing authority is issued against a stated basis, the question an auditor asks — what could reach this dataset, and under what basis? — becomes a query with a complete answer rather than an interview with the delivery team.
Erasure reaches derived state
Classification labels travel with the data through every tier the compiler places it in, and one vocabulary drives retention, redaction, residency, audit and journalling. That is the difference between deleting a row and discharging a statutory duty — and it is the direction supervisory guidance is already travelling, having held that erasure must be complied with by design.[19]
Assurance becomes continuous rather than periodic
If the property is established by the build, then every change is assessed by construction, and the accreditation question changes from was this system assessed? to what does this system's toolchain guarantee for every build, including the ones nobody looked at? That is a better question and it is answerable mechanically.
The supplier relationship gains a technical floor
Contractual assurance transfers liability. A checked authority surface constrains what delivered code can do regardless of who wrote it, whether their agent was under someone else's influence, and whether anyone read the diff.
Section 05Questions worth asking any supplier
These are useful immediately, whatever platform you are on.
- What can this component reach, and can you produce that answer mechanically rather than by inspection?
- If your coding agent were following instructions it read in a ticket, what would bound the damage?
- When a deletion request is discharged, what enumerates the derived copies — and is that list generated or maintained?
- What executed during your build, and can a third party reproduce the artifact bit-for-bit?
- Which of your assurances are properties of the system, and which are statements about the process?
Kasuri is at specification stage, ahead of a reference implementation. There is no accredited product to procure today and no public-sector deployment. What this chapter describes is the design intent against a documented threat picture, and Chapter 20 sets out what early engagement involves — which is shaping requirements and reviewing evidence, not adopting an unproven platform into a live service.