On this page
Untrusted files processed in year one, each bounded to a disposable VM.
Payments issued outside sanctioned paths, enforced in-kernel.
Audit coverage of decisions, replayable.
Blast radius of a malicious attachment: one disposable micro-VM.
Challenge
Untrusted input at one end. Money at the other. In between, software making decisions. Every experienced security reviewer recognises that profile on sight, and a mid-size P&C carrier processing 250,000 claims a year runs about a million inbound attachments through it annually.
- Nobody in the carrier vetted any of the files. Photos taken on a claimant's phone, PDFs from a body shop, third-party vendor reports, medical documents from a provider portal.
- A meaningful share are adversarial by design. US insurance fraud was put at $308.6 billion a year across all lines, with property and casualty accounting for roughly $90 billion of it (Coalition Against Insurance Fraud, 2022). A claims system parses hostile documents on purpose, at volume, as its core function.
- The last evaluation died in procurement, not in the pilot. The vendor's answer to where documents get processed was a shared cloud tenancy, and its answer to what stops wrongful payment was application-layer controls and a promise. Both were normal for the market. Neither survived a security team that understood what a malicious PDF is for.
- Application-layer controls cannot answer the question. They are enforced by the same software an attacker is trying to compromise.
- A genuine deadlock. The business case was strong and getting stronger. The security profile made it undeployable.
Untrusted input at one end, money at the other
- 01
An attachment arrives
Reads Photographs, PDFs and reports from anyone who files a claim
Held Extracted content, from inside a disposable guest kernel
- 02
The claim is assessed
Reads Policy terms, coverage and the carrier's own rules
Emits A recommendation, with the reasoning logged as it forms
- 03
Settlement is prepared
Reads The assessed claim, within the carrier's own authority limits
Held A payment instruction on kernel-allowlisted paths only
- 04
Anything outside the limits
Reads Complex, disputed or above-threshold claims
Emits A named adjuster. The authority never moves.
Solution
CreateOS resolved the deadlock by moving the controls below the application, into the kernel and the hypervisor, where the agent cannot reach them even if the agent itself is compromised.
- Every untrusted file is processed in a disposable VM. A weaponised PDF is contained to that micro-VM, not the host, not the claims environment, not another claim. When extraction finishes, the VM is destroyed.
- Containment is a property of the machine, not the application. In a shared-tenancy tool it depends on the application being correct. Here the file-handling agent is assumed hostile-adjacent by design, and the blast radius is a VM that was going to be thrown away anyway.
- Settlement physically cannot pay the wrong place. Egress is allowlisted in the kernel, so an agent that is wrong, manipulated, or compromised still cannot move money outside policy. It is not that the software declines to make the call. The call cannot be made.
- Human sign-off above authority thresholds. The kernel control is the floor, not the whole of it.
- Claimant data never leaves the boundary. Control plane and storage run inside the carrier's own infrastructure and region. Claims data in several lines is health-adjacent, so that burden was never transferred to a third party at all.
- Certifications already done. CreateOS is SOC 2 Type II and ISO 27001 certified. The previous evaluation had run aground on a vendor offering self-hosting as a substitute for certification.
The honest version of why we can make these promises when most cannot: most agent builders own the prompts and rent the runtime. When your agent parses hostile documents and issues payments, renting the runtime means renting the exact controls your risk committee is asking about. We own both layers, which is the only reason we can put a containment guarantee and a no-unauthorized-payment guarantee in a contract rather than in a slide.
Outcome Derived
The outcome that matters here appears on no efficiency dashboard: the project was deployable. Information-security review passed on the first pass, and an automation programme that had been dead for two years shipped.
| Metric | Before | After |
|---|---|---|
| Untrusted document processing | Shared tenancy, application sandbox | Firecracker micro-VM, own guest kernel, destroyed after use |
| Blast radius of a malicious attachment | The processing environment | One disposable VM |
| Payment path control | Application-layer logic | Kernel-level eBPF egress allowlist |
| Unauthorized payment | Mitigated by correct software | Structurally impossible, path does not exist |
| Claimant data residency | Vendor cloud | Inside the carrier's own boundary |
| Certification | Varies | SOC 2 Type II and ISO 27001 |
| Audit coverage of decisions | Partial | 100% replayable |
- ~1M untrusted files in year one. Each bounded to a disposable VM, with zero payments issued outside sanctioned paths, enforced in the kernel rather than trusted to the application.
- Security review became a confirmation, not a fight. It is the longest and least predictable phase of any insurance technology purchase, and where claims automation projects go to die.
- Cycle time got it on the roadmap, the controls got it into production. The efficiency benefits are available from many vendors. Clearing a security team that correctly reads untrusted input plus payment authority as a serious risk profile is not.
Highlights
- Roughly a million untrusted files processed in year one, each blast-radius bounded to a disposable VM.
- Zero payments issued outside sanctioned paths, enforced in the kernel.
- 100% audit coverage of decisions, replayable.
- Unauthorized payment structurally impossible, network path does not exist (eBPF egress allowlist).
- Security review passed on the first pass; the automation programme that had been dead for two years shipped.
