The core is not yours. The payment gateways are not yours. The pipelines and service accounts that touch them belong to teams that do not report to you. Every April you and your CEO both sign the Part 500 certification anyway, and it has to rest on data and documentation sufficient to demonstrate material compliance across the entire prior year, retained five years and producible on request.
Certify on evidence you hope holds up in an exam.
File an Acknowledgment of Noncompliance: a signed list of what you missed, handed to the regulator.
Certify on cryptographically hash-chained evidence written as each event happened: every approved version, and every change refused before it reached production, with the logs and session replay in your own Churchill dashboard, retained for the period your regime requires.
The first two are the only options you have today. Churchill creates a third: NYDFS §500.6 asks you to be able to reconstruct the year. This is the cryptographically hash-chained forensic record that generates it as each event happens, available to you from August 31, 2026.
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. Churchill is that infrastructure: the layer the other two hand their trust to. If you own the confidential computing program, this reframes it rather than replaces it, and that conversation is better had early.
Where this sits against the rest of your stack, layer by layer →This is the control the rest of your stack doesn't have. An intruder with root reaches a critical production host and fails: this is the real console, replaying a recorded session in which the exec, the artifact fetch, and the write to /etc/ld.so.preload were each refused while the application kept running.
You replace a legacy system because you cannot prove what it is running. Churchill lets you prove it instead. Your change board approves one version of the application. After that, nothing else can run on it, and you can show that to an examiner for any day of the year. The old system stays, its code untouched, and it takes minutes per host to put in place.
An intruder, an insider, an AI agent, a careless admin. Every one of them has been sold to you as a separate product with a separate console and a separate alert queue, because each was named after a different actor. Every one of them monitors and alerts, promising to detect sooner. Sooner is still after: the action already hit production. They all need the same thing to do damage, which is for the application to do something it was never approved to do. Refuse that, and the actor's identity stops deciding whether you are covered. Today an approved release is the way changes are supposed to happen. After Churchill it is the way they can happen.
Churchill produces the other kind. Because the gate sees every attempt on a protected application, the record it writes is intelligence about your own systems, from your own attackers, on the day it happens.
{{ x.v }}
Hover or tap any of the five for the detail.
{{ n.v }}
Your hosts connect outbound to the control plane and nothing connects inward: we hold no credential into your environment and open no listening path in it. You pin a version by declining to approve a new one.
How Churchill itself gets updated, in full →Not what the product does. What is different about your position after it is running.
{{ y.v }}
Linux kernel 5.0 and higher, at full strength from 5.7. x86_64 and IBM Z / LinuxONE today, across containers, virtual machines, and bare metal.
Both programs are named, scoped, and counted below, including who was invited and what they were allowed to use. Neither result is extrapolated to the other.
As a participant in Anthropic's Cyber Verification Program we obtained access to Mythos and ran it against Churchill under structured conditions: 29 documented sessions from four distinct adversarial operators, 11.3 cumulative hours, 406,433 enforcement decisions. Three sessions granted full administrator access for a cumulative 1.5 hours and produced 22 distinct tamper actions, with no persistent modification to any protected asset.
100% containment and zero data exfiltrated across these 29 sessions. The 30-day CTF is a separate program, reported in its own card.
To be exact about what this is: the Cyber Verification Program is Anthropic's structured adversarial testing of security products, and WestGate is a participant in it. These are measured test results, not an Anthropic endorsement, certification, or recommendation of Churchill. Anthropic ran the adversary; the results are ours to report.
Do not take this result on its own. The mechanism underneath it is checkable against your own expertise: the refusal happens at the kernel boundary using in-tree facilities, and approval requires signed receipts from humans you designated. Neither property gets weaker as the attacker gets faster, and both are verifiable without trusting a number we published.
31 specialist kernel researchers and top offensive CTF competitors, plus 40 autonomous AI attack sessions directed by the participants themselves. Open entry, registered on GitHub, any method allowed including AI tooling, and every participant selected their own techniques freely. 282 distinct techniques, 409 attack instances, 30 days.
Zero breaches at the core: no attacker changed what the protected application runs, and none reached the evidence chain.
The most advanced session gave up on the gate entirely. It moved the protection binaries off the host, ran a degraded copy elsewhere, and tried to impersonate the host to the control plane. The control plane, offsite and out of the attacker's reach, saw the anomaly in the encrypted heartbeat and signalled the host. The host fired the kill switch and the session ended. Detection sits outside the host so it cannot be silenced; the authority to stop sits on the host, so there is no remote command that can stop your estate. The protected system was never touched. Session logs and methodology available under NDA.
An unapproved operation is refused. The application keeps running. Nothing restarts and nothing waits on a person. A refusal is not an outage.
A host enters lockdown and holds until your quorum reviews the evidence and clears it. Never from a refusal, however many. It takes tampering with the protection itself, or a governed change window that closes with the binary still changed or that any one of your approvers vetoes.
A governed change is a maintenance event. The application stops for the hold and restarts on the version your board approved, the same as any other production change to that host. Refusals never interrupt it; approved changes do, briefly, and on your schedule.
The AI Kill Switch Act, H.R. 9917, has the two hottest words in your board deck in its title, and its obligations fall on model developers rather than on financial institutions. We keep it off our mandate map for that reason: it does not bind you, and pretending otherwise would discount the four that do. The four that do bind you, provision by provision →
Evaluating this takes more than one person. Each page below is written for one of them, and every one is forwardable on its own.
30 days free in non-production. Self-serve download from this site beginning August 31, or a regulated-institution path with NDA and evaluation agreement, and an engineer-led lab session on request. Installs in minutes, removes cleanly, both guides included.