Three layers. One gate.
Three architectural layers, each placed out of reach of the systems it governs. The control plane confirms that both Churchill and The Protector are operating, from offsite. Churchill verifies what executes. The Protector anchors Churchill in the kernel, where refusals happen at the kernel boundary rather than in user space.
One host in lockdown while the other hosts keep running. Lockdown is per host, and there is no fleet-wide kill or lockdown broadcast.
The third guarantee, and what each of the three will never do.
Keys
KEY SECURITY INFRASTRUCTUREHSM
Your keys got a vault. They cannot be extracted, even by an insider with access to the machine.
Data
DATA SECURITY INFRASTRUCTUREConfidential computing
Your data in use got a sealed room. The host, the hypervisor, the cloud cannot see or alter it.
Applications
APPLICATION SECURITY INFRASTRUCTUREChurchill
Your application comes off the honor system. Unilateral change is refused: not by an admin, a service, an AI, an insider, or stolen credentials. Not even root.
The first two hand their guarantee to the application and take it on its honor, because until now there was nothing else to hand it to. Change control has lived in written policy and review boards, not because anyone chose paper over proof, but because no infrastructure existed to make it structural. Churchill is that infrastructure: refuse the unauthorized change, and the intruder’s identity stops mattering.
The HSM signs whatever the application asks. Churchill guarantees the asker.
WHAT THE GUARANTEE IS MADE OFA kernel-anchored gate, twin sentinels, an off-host control plane watching from outside, and a client-held cryptographic quorum: arranged so no single actor, human or AI, can change what your application runs or hide the attempt.
Anyone evaluating this for a production workload should understand both. Never WestGate's decision, on either path.
An unapproved operation is refused. The application keeps running.
This is what happens to an attack, a bad deploy, or config drift. The operation stops before it takes effect. Nothing restarts, nothing waits on a human. A refusal is not an outage.
A host that has shown tampering enters lockdown and holds until your quorum reviews the evidence and clears it. No single administrator can clear a lockdown.
Not triggered by refusals, however many: refusing an attack does not lead here. Two things do. Tampering with the protection itself, and a governed change window that closes with the binary still changed or that any one of your approvers vetoes. In the Anthropic program it fired once across the 29 adversarial sessions, after a second tamper attempt on a freshly delivered runtime. Four other sessions recovered automatically with no operator involved.
Confidential computing protects your data in use from the infrastructure. Churchill protects your application in use from root.
You already own guarantees like this: the HSM holding your keys, the enclave sealing your memory. Root inside the workload is inside the enclave's trust boundary, and it can make authorized requests of your HSM. Churchill closes that side. Churchill closes the side the enclave leaves open.
Churchill is infrastructure, not a tool. Like your HSM and your enclaves, it isn't compared against the stack; it's what the stack stands on.
Change clears only through the approver pool you design, as many members as you choose. Approval takes a minimum of two; a single veto denies. Every approval is a cryptographically signed receipt on the evidence chain, so an approver cannot hide or forge their vote.
Worth saying plainly, because it is the first political question this raises: the pool is the change board you already have. Nobody outside it gains a vote, and no one at WestGate has one. The veto exists so an approver cannot be pressured into signing something they do not believe in, which protects the people who hold the keys as much as the system. Whether that is a welcome change to how change happens on your critical hosts is a conversation with whoever owns those hosts, and it is better had early than discovered at the first release.
Three guarantees. You likely own two. The third protects the thing the other two hand their trust to: the running application itself.
Comparing Churchill to EDR, FIM, or allowlisting? Different job. See how Churchill fits your existing stack for the architect's layer-by-layer view, or start with the payment workloads we protect first.
{{ l.name }}
{{ l.body }}
The whitepaper describes the same architecture in trust-domain terms: the integrity sentinel embedded in the application, the privileged sentinel on the host, and the off-host control plane. The layers above are how those domains are realized in the runtime.
Built to fit the model you already run.
Five architectural decisions.
{{ d.h }}
{{ d.b }}
Linux kernel 5.0 and higher. Full-strength kernel enforcement needs 5.7 or higher with the kernel facility active, which is the default across the RHEL 9 family. Architectures today are x86_64 and IBM Z / LinuxONE, across containers, virtual machines, and bare metal.
Read it in trust-domain terms.
The engineering whitepaper covers runtime integrity, the three-domain trust architecture, off-disk runtime, locked baselines, and the independent adversarial evaluation results.