A break-in is never a breakout.
Even with root, no one changes what your most critical application runs.
In 2016 the attackers who took $81 million out of Bangladesh Bank did exactly that, modifying the bank's own payment messaging application. Then they changed its confirmation printing, so the transfers left and nobody saw them go. Every one of those actions is an unapproved change to a protected application, and every one is refused at the system's core (the kernel) before it commits.
No analyst in the loop. Nothing new in your queue.
Every attempt becomes evidence. Built for banking payment systems
first: the wires, the rails, the keys that approve the money.
Your application is still on the honor system. This takes it off.
Adversarially tested through Anthropic's Cyber Verification Program.
Four things that are true before anything else is.
You own the outcome. You do not own the change control.
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 evidence written as each event happened.
Cryptographically hash-chained: 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 hash-chained forensic record that generates it as each event happens, available to you from August 31, 2026.
You already bought two guarantees. Why would you need a third?
Your keys got a vault. They cannot be extracted, even by an insider with access to the machine.
Your data in use got a sealed room. The host, the hypervisor, the cloud cannot see or alter it.
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 →
Caught in the act. The application keeps running.
This is the control the rest of your stack does not 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 a loader configuration file were each refused while the application kept running.
This lands in the modernization line, not the security line.
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.
The market sells a different tool for each intruder. This is the one gate they all have to pass.
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.
They all need the same thing to do damage.
Every one of those products monitors and alerts, promising to detect sooner. Sooner is still after: the action already hit production.
What they all need 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.
Every feed you subscribe to describes someone else's breach, months ago, somewhere else.
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.
Every record is an attempt that already failed. No queue, no confirmation step, no deciding whether something happened.
One account repeating a clumsy operation in business hours reads differently from patient, varied attempts after hours. Replay the session and watch which it was.
A host with sixty refused hotfixes does not have an intruder. It has a broken change process, and now you can see it with accounts and timestamps attached.
Year one it is an evidence trail. By year three it shows who keeps testing your institution and how their methods change. No vendor can sell you this, and it never leaves your hands.
What a record contains, and what it is worth at fleet scale →
We cannot push anything to your hosts.
Five reasons, each one a property of the design rather than a promise. Open any of them for the detail.
No vendor update path
We build and publish releases. We do not sign what your hosts trust, so nothing we publish reaches a host you have not approved it for.
No approval we can give
A minimum of two of your quorum members must approve a baseline before an updated component runs, and any one of them can deny it.
No keys we hold
Approval keys stay on your approvers' own machines, outside Churchill. We cannot sign a baseline, approve a change, or forge a receipt.
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 →
What changes for you specifically.
Not what the product does. What is different about your position after it is running.
SWIFT CSCF 1.2 and NYDFS §500.7 govern who is granted administrator access. Neither governs what that access can reach once granted. You gain that: operations outside the approved package are denied at the system’s core, including operations attempted with root.
You gain the record NYDFS §500.6 asks you to reconstruct, generated as each event happens: every attempt, allowed or refused, hash-chained with the host, the executable, the account and the reason, in two custodies.
You gain a body of evidence no vendor can sell you: which of your hosts adversaries actually go after, by method and by hour, on your own systems, this week. It compounds every year you run it.
When an account reaches for something it should not, you gain a sealed, timestamped record of the attempt and the session behind it, in a form you can hand to counsel or a regulator without reassembling a story.
You gain the ability to prove an older application is running exactly as approved, which is the question that usually drives a replacement program. Governing it becomes an alternative to replacing it.
Approval already exists on paper. You gain it as the only path: two of your approvers must sign, any one can deny, and every signature is a receipt on the chain. Nothing runs outside that.
Who actually tried to break it, and what were they allowed to use?
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.
Mythos, run against Churchill under structured conditions
As a participant in Anthropic's Cyber Verification Program we obtained access to Mythos and ran it against Churchill: 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 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. The 30-day capture-the-flag is a separate program, reported in its own card.
Zero breaches at the core
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.
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. The protected system was never touched. Session logs and methodology available under NDA.
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. Two separate programs, two separate result sets. Sanitized session excerpts and our acceptance record for the program are available on request. Complete logs and full methodology under NDA.
A refusal is not an outage.
An unapproved operation is refused. The application keeps running. Nothing restarts and nothing waits on a person.
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.
One thing you can check without trusting us: 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. The regimes that do bind you, provision by provision →
Depth, by whoever is asking.
Evaluating this takes more than one person. Each page below is written for one of them, and every one is forwardable on its own.
Where money leaves the mainframe, which workloads carry the bank's authority, and which zone to protect first.
Read → Security architects ArchitectureThe third guarantee, where Churchill sits relative to your stack, and how the control is anchored.
Read → Principal engineers Technical FAQKernel attachment, the TOCTOU race, overhead, cold start, the kill switch, and the threat boundary.
Read → Whoever owns the hosts Platform teamsWhat changes in your release path, the emergency sequence, and where this is a bad fit.
Read → Whoever signs Compliance and oversightProvision-level mapping for SWIFT CSP, DORA, PCI DSS, NYDFS Part 500 and HIPAA, and what each does not cover.
Read → Whoever owns the threat intel budget Threat intelligenceThe other kind of feed: what a record contains, what it is worth at fleet scale, and what it does not claim to be.
Read → Vendor risk About WestGateWho built it, what has been independently tested, and the IBM partnership behind it.
Read → Outside banking Other industriesWhere this applies after payments, and why banking is first.
Read →Prove it on your own workload.
30 days free in non-production. Self-serve download from this site beginning August 31, 2026, 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.