Questions a technical evaluator asks. Answered.

No. Churchill uses in-tree Linux kernel security facilities that ship with the kernel you already run. Nothing is compiled into your kernel, no out-of-tree module is loaded, and no kernel rebuild is required.

The enforcement layer is BPF LSM, a facility of modern Linux kernels. Churchill's gate programs are loaded from user space and statically verified by the kernel's own verifier before the kernel will accept them: the kernel proves each program is memory safe and terminates before it is allowed to run. That verification does the job a driver signature does on other platforms, without asking you to trust a signature.

A process makes a request of the system. The processor switches to privileged mode, the kernel dispatches its handler, and before the operation commits, the gate is consulted. Churchill returns its verdict there.

A refusal returns an ordinary permission error to the caller. The operation never happens. An approval lets the operation proceed at native speed.

The placement is the point. The gate sits inside the kernel's own control flow, so a process cannot reach the operation without passing through it. This is a mandatory passage point in the literal sense, not a monitor watching from the side.

Because they are the same bytes, not the same path.

At execution, Churchill computes a cryptographic hash over the actual contents of the file the kernel has already opened for that execution. It does not re-open the path and hash whatever is there now. The verdict applies to the exact object about to run, and the execution is refused unless it matches what your quorum signed.

This closes the time-of-check to time-of-use race, TOCTOU, the gap most integrity checking leaves open. Tools that verify a path and then let the kernel open it separately can be defeated by substituting the file in between. There is no in between here.

Each of those answers a question at its own layer, and Churchill does not replace any of them. The difference is what each one does at the moment an unapproved change arrives.

EDR, SIEM, RASP. Observe activity, recognize known patterns, and generate an alert for review. The change has already executed when you learn about it.

File integrity monitoring. Detects that a monitored file on disk has been modified, after the modification. Alert-based, and scoped to files rather than to the running application.

Allowlisting and kernel security modules. Check executables or enforce declared rules at specific decision points. Strong at what they declare, silent about whether the application is the version your governance approved.

Churchill. Verifies the protected application against the exact package your board signed, continuously, while it runs, and refuses anything else before it executes. Pre-execution, full application including configuration and secrets, every action, in under 2 ms.

Keep the rest of the stack. Churchill answers the one question none of them was built to answer, and answers it before the change takes effect rather than after.

Churchill runs alongside them, not instead of them.

Those modules enforce declared rules at kernel decision points. Churchill answers a different question at those same points: is this the application your quorum approved. Every registered module is consulted and the most restrictive answer wins, which means a refusal by SELinux, AppArmor, or kernel lockdown is never converted into an approval by Churchill. That is a property of how the kernel stacks security modules, not something we engineered on top of them.

Your existing policies are untouched and need no reconfiguration. One prerequisite worth checking before enrollment: on SELinux hosts, Churchill installs its own policy module alongside yours, which needs the distribution's standard policy tooling, the policycoreutils package, present on the host. Enrollment checks for it and stops cleanly if it is missing, rather than deploying something the host would then deny.

Approved operations run at native speed, and that phrase should mean something specific rather than reassure. It means the approved application executes directly on the processor, with no translation layer, no interpreter, and no emulation between your code and the hardware. Churchill is not in the path of your application's ordinary compute. The checks that do apply are on the specific operation classes named in the threat boundary, not on every instruction the application executes.

An unapproved operation is refused in under 2 ms end to end. That figure bounds the entire path including evidence capture; the check at the kernel boundary itself completes far faster.

If you are asking for a p99 under load at a specific syscall rate rather than a bound, that is the right question and the honest answer is that the number you care about is yours, not ours. Published figures are measured on our reference profile. During evaluation we instrument your own workload at your own call rate and give you the distribution, including the tail, before you decide anything.

Launching a protected binary adds single-digit milliseconds, once, at launch. Ordinary input and output is untouched. Measured steady-state overhead under heavy I/O is under 3% on a four-vCPU host, and continuous monitoring runs within a fixed budget sized for single-vCPU hosts.

Those are our figures on our hosts, which is the weakest kind of performance claim. The trial includes the measurement harness, so you produce the distribution on your own boxes, at your own syscall rates, and hold us to what it says.

Everything that defines the version your quorum approved:

• The application program
• Its configuration
• The libraries it depends on
• The scripts and static data files it reads
• Its secrets
• Churchill's own components

The snapshot is cryptographically signed at approval, delivered over an encrypted session the host itself initiates, and materialized into protected memory that refuses modification from any process regardless of privilege.

It is not written to disk on the protected host. There is nothing on disk to swap, overlay, or replace, and the path the runtime is served through is itself protected against mount shadowing. That is the practical consequence for an attacker who lands on the host with root: the running application cannot be modified in place, cannot be shadowed by a mount, and cannot be substituted on disk, because it is not on disk.

Linux kernel 5.0 and higher, with cgroup v2 and systemd 240 or later. Full-strength enforcement requires 5.7 or higher with the in-tree kernel facility built and active. That is the default on current RHEL 9 family releases, 9.8 and later, including Rocky and Alma; on earlier 9.x releases and on Ubuntu and Debian it is a boot parameter, not a kernel rebuild.

Older kernels are supportable, not unsupportable, and this matters if your critical hosts are on RHEL 8. Below 5.7 the kernel-boundary refusals degrade to detection and response by the sentinels, with latency bounded by monitoring cadence rather than by the syscall itself. The pre-execution gate remains a refusal either way: an unapproved binary still does not run. Churchill installs and protects at documented reduced strength rather than refusing to run, and the trial is the honest way to see what that strength looks like on your host.

Architectures today are x86_64, aarch64, and IBM Z / LinuxONE. x86_64 and LinuxONE are built and validated dual-architecture with every integration test running on both, across virtual machines and bare metal. Applications are protected without source modification.

Through your existing host provisioning: image baking and configuration management. Installation takes minutes per host, and removal is a documented procedure rather than a project. Both guides ship with the trial.

One property is worth stating plainly, because it is usually the first question a platform team asks. Discovery and configuration run on the host, and the host always connects outbound. Churchill never reaches into your infrastructure, holds no inbound credential to your environment, and opens no listening path into it. Configuration and cryptographic hashes travel up; nothing secret travels down.

Enrollment uses a single-use, short-lived provisioning code scoped to a tenant, environment, and source network. The code pairs the host and nothing more. The host generates its own identity keypair locally and the private half never leaves it. A stolen code buys an attacker a registration attempt your operators will see and your quorum will refuse.

Virtual machines and bare metal are supported today. Churchill protects a long-running application that the host's own service manager runs; that is the deployment shape the product is built around, and it is stated here so you can test it against your estate rather than discover it during rollout.

Kubernetes and short-lived container workloads are a different shape, and we will not claim them by analogy. How governance extends to an ephemeral environment is scoped during the pilot against your actual platform.

Your CI/CD continues to produce build artifacts exactly as it does today. Churchill captures the approved application when your quorum signs off, not at every deploy.

Churchill does not modify your build pipeline. Your CI/CD produces artifacts as it does today. At the deployment moment, the quorum you designed signs the new version, and Churchill re-captures and re-seals.

A deploy is a brief governed maintenance event: the protected application stops while the new version goes in, and the host restarts it on the approved baseline once your quorum has signed. Plan the cutover the way you would plan any restart of that service.

Churchill suits crown-jewel applications where governance approval already exists at each release. It is not designed for applications whose release cadence outruns what governance approval can support. That is a design choice, stated so you can test it against your own release calendar rather than discover it later.

Your approver pool can be as large as you want it to be. Approval requires a minimum of two members, and any single member can veto.

Because the pool size is yours to set, adding members costs nothing operationally and removes single points of failure without adding workflow complexity. Your team decides who signs from whoever is available. There is no delegation chain and no bypass, including for us.

Approval keys stay on the approvers' own machines, outside Churchill entirely.

You get a governed path to make that change quickly. You do not get to make it to a running protected application, and that distinction is deliberate.

The sequence: an operator declares the change and opens a hold, which is scoped as narrowly as it can be. Tamper protection is suspended for the one binary being changed, for that one application, on that one host, and the protected application stops for the duration. Everything else on the host stays enforced, the sentinel's self-defense stays armed, control plane liveness stays armed, and the modified binary still cannot execute while the hold is open. A minimum of two members of your quorum pool approve, and any one of them can veto. The operator authorizes the rebaseline, and that is the last human action in the sequence. The host pulls the signed new baseline on its next poll, restarts the application itself, re-injects the sentinel, and protection re-arms against the new baseline.

Mechanically that adoption takes about fifteen seconds plus a short restart. Real elapsed time is dominated by how fast your quorum members sign, which the system deliberately leaves to your people rather than to a timer. Authorizing also pushes the deadline forward, so adoption is never cut off by a window expiring mid-restart.

The hold has a four-hour maximum. Two things end it unsuccessfully, and both end in lockdown rather than in a quiet return to normal: a veto from any one member of your quorum pool, or the window expiring with the binary still changed.

What this is: a governed maintenance event that produces a signed, evidenced change and a protected application on the other side. What it is not: a way to hot-patch a running settlement broker. If your continuity plan needs the second thing, plan the change as a maintenance window.

This is the worst case, so here is the exact behavior with nothing softened. If the four-hour window closes while the binary is still changed, the host locks down. It stays down until your quorum reviews the evidence and clears it. No single administrator can clear a lockdown, and that is not configurable.

Three things determine whether you ever reach that state, and all three are yours to set.

Your roster size. The pool is as large as you choose. Two signatures clear a hold, any one member can veto, and adding members costs nothing operationally. A roster sized for follow-the-sun coverage does not have a 3am gap.

Your schedule window. A hold can only be opened inside a weekly schedule you pre-set. Exclude your settlement and close windows and no operator can open one during them.

Planning the change instead. A hold is a governed maintenance event, not a hot-patch path. If your continuity plan cannot tolerate a restart, the change belongs in a maintenance window, the same as any other production change to that host.

The honest summary: Churchill will not silently extend a hold to protect your window, because a hold that never expires is not a control. What it will do is refuse to let the changed binary execute for the entire time the hold is open, so the workload you are protecting is never running unverified code while you wait for a signature.

No, and they do not have to be in your quorum pool at all.

Declaring a change is an operator action. Approving it requires signed receipts from a minimum of two members of your quorum pool, out of however many members you have designated, and any one member can veto. The declarer is not required to be one of the approvers, which keeps the separation of duties intact on the emergency path exactly as it is on the planned one.

A change moves through named states that are never collapsed: pending approval, then quorum satisfied once the minimum signatures are in, then published. Quorum satisfied is not published, and published is not yet adopted by a host. A change can also be rejected by a veto or expire unsigned.

Each approved version is a distinct, cryptographically signed snapshot. Rolling back is a change request like any other: a minimum of two members of your quorum pool approve a prior snapshot, any one can veto, and the host adopts it.

Adoption restarts the protected application. That is intrinsic to how adoption works and it applies equally to rolling forward and rolling back. The restart is the host's own action, not an operator starting the service by hand.

No reinstallation, kernel reboot, or system reconfiguration is required.

We build and publish Churchill releases. We do not sign what your hosts trust.

The signatures your hosts verify are applied by your own control plane's keys, and a minimum of two members of your quorum pool must approve the baseline before an updated sentinel can run on your hosts, with any one member able to veto. There is no forced auto-update and no vendor push into your environment. You pin a version by not publishing a new one.

For a crown-jewel host, this is the property that matters most about a vendor's update channel, and it is the reason we do not hold one into your estate.

A hung or unresponsive component is detected rather than ignored, and detection is not the same as stopping your workload.

The two on-host sentinels watch each other as well as the application, and the offsite control plane confirms the host's state independently from outside every system Churchill protects. Silencing, freezing, or killing any one of them is detected by the others and recorded as a tamper event.

There are two kill paths and they behave very differently. Anyone evaluating Churchill for a production workload should understand both.

The in-application path. The sentinel inside the protected process detects compromise of that process and terminates it. The application restarts under its own service policy in roughly half a second. No human involvement, no lockdown, no residue.

The host path. The host sentinel detects tampering, terminates the protected scope, and writes a lockdown marker that survives reboots. The host does not bring the application back until your quorum reviews the evidence and clears it. No single administrator can clear a lockdown. This behavior is not configurable and cannot be turned off.

The reason for the difference: the first case is a process that failed verification and can be replaced with a verified copy. The second is a host that has demonstrated tampering, and bringing the workload straight back on it would be answering evidence of compromise by trusting the compromised thing.

Every step of either sequence lands on the evidence chain for an accountable human to review.

Rarely, and we can put numbers on it rather than adjectives.

Across the 29 adversarial sessions in the Anthropic program, 20 ended with the adversary finding no exploitable surface at all. Four had an action stopped at the enforcement boundary. Four had the protected runtime tampered with and recovered automatically: the tampered runtime was evicted, a fresh signed payload delivered, and enforcement restored with no operator involvement. One session reached the persistent-compromise threshold, after a second tamper attempt on a freshly delivered runtime, and the host was cleanly terminated.

So one lockdown in 29 sessions of deliberate, unrestricted attack, and it took repeated tampering with the protection itself to get there. In the public capture-the-flag it fired against the session that extracted the protection binaries and tried to impersonate the host to the control plane.

Three of the 29 sessions granted the adversary full administrator access for a cumulative 1.5 hours and produced 22 distinct tamper actions. None of those three reached lockdown, and none produced a persistent modification to a protected asset.

These are figures from our own engagements rather than from a customer estate, and the ratio on your hosts depends on what happens on them. What the numbers do establish is the trigger: repeated tampering with the control, not ordinary refusals and not a single failed attempt.

What exists is a governed hold, and you set the schedule for it. Pre-set a weekly UTC window during which a hold may be opened, and exclude your close windows and settlement periods so no operator can open one inside them.

There is no off switch and no open-ended maintenance mode, and the hold is narrower than a maintenance window in three ways worth understanding before you plan around it. Inside that schedule, an operator opens a fixed four-hour hold that is audited, scoped to one application on one host, and suspends tamper protection for one binary only. The change must then be approved by a minimum of two members of your quorum pool, or the host locks down.

What you cannot do is schedule a window that opens itself. A person opens every hold, and every hold is on the record.

Per-host. Every termination and lockdown decision is made and carried out on the affected host, and works whether or not the control plane is reachable.

The control plane can direct enforcement at a specific host over that host's own signed session. There is no fleet-wide termination broadcast. The only all-hosts signal in the system is a drain instruction that prevents wipes during planned server restarts.

If you are evaluating blast radius, that is the answer: there is no single command, from us or from an attacker who reached our control plane, that stops your estate.

Enforcement continues. Every allow-or-refuse decision is made on the host against the baseline already sealed there, so a network partition does not weaken protection and does not create an opening.

Evidence continues too. Records are written to the host's append-only chain during the partition and synchronize to the second custody when the link returns, so the chain has a gap in delivery rather than a gap in content.

A partition on its own is not treated as tampering. What it removes is your ability to approve a change, because approval requires your quorum and the quorum reaches the host through the control plane. A host in a steady state keeps running exactly as approved, and no new version can be adopted until the link is back.

One case is not steady state, and it is the one to plan for. A hold cannot be opened while the control plane is unreachable, so a partition never starts a change window. But a hold that was already open when the partition began still follows the expiry rule above: if two approvers cannot sign inside the four hours, the window closes with the binary changed and the host locks down. Partitions during an open hold are therefore the one path from a network fault to an unavailable host, which is the argument for opening holds inside a scheduled window rather than under pressure.

Outside that case the failure direction is unavailable to change, not unavailable to serve.

This is a different question from the partition case above, and the answer is different. A running host keeps enforcing through a partition because its baseline is already sealed in memory. A rebooting host has no such baseline: on reboot Churchill rebuilds its protection runtime in memory from a fresh, signed control-plane bundle rather than from disk.

That design choice is deliberate and it is the same one that closes file substitution: there is no on-disk copy of the protection runtime for an attacker to modify, shadow, or replace while the host is down. The cost of that property is that reaching the control plane is part of coming back up.

Plan for it accordingly. A host that reboots while the control plane is unreachable cannot rebuild protection until the link returns, so control-plane reachability belongs in your recovery runbook alongside your other boot-time dependencies.

Churchill does not protect your kernel. Nothing in this product claims to, and any vendor telling you otherwise is selling you something.

What Churchill does is protect your application against everything short of that, up to and including an attacker holding root, and fail loudly rather than quietly when something deeper is in doubt.

The application cannot be changed from user space, root included. It runs from protected memory rather than from disk, so there is no file to substitute, no path to shadow, and no in-place modification available at any privilege the host can grant a process.

And if the kernel itself is corrupted, the application does not keep running in an unverified state. A verified compromise reaching that depth resolves to the host lockdown described in section 03, not to a workload that continues serving while someone else decides what it does.

The honest scope statement is narrow and worth stating exactly: we do not defend the kernel, we defend the application that runs on it. Organizations requiring measured boot and kernel-level attestation should layer Secure Boot, kernel lockdown, and TPM-based attestation alongside Churchill. We consume hardware identity where it exists; we do not measure the boot chain ourselves.

It is the case we have the most public evidence for, because it is the case we deliberately went looking for.

An AI attacker is not a different kind of threat at the gate. It is the same unauthorized operations arriving faster, in more combinations, and without the fatigue or caution that limits a human operator. That distinction matters enormously against tooling that depends on an analyst noticing something. It matters much less against a refusal that happens before the operation commits, because there is no reaction window to outpace and no queue to overwhelm.

Refuse the unauthorized change, and the intruder's identity stops mattering.

Two separate programs, two separate result sets.

In a 30-day public capture-the-flag, 31 registered specialist kernel researchers and top offensive CTF competitors, plus 40 autonomous Claude sessions, attacked a live target holding a real flag. Any method was allowed, including AI tooling, and participation was tracked publicly on GitHub. 282 distinct techniques across 409 attack instances. Zero breaches at the core. The $10,000 bounty went unclaimed.

Separately, under Anthropic's Cyber Verification Program, the Mythos engagement ran 29 documented sessions over 11.3 cumulative hours and produced 406,433 enforcement decisions, including sessions that began with full root. 100% containment, zero data exfiltrated.

Neither program's results are extrapolated to the other.

What you can see without signing anything: the shape of the program, who set the success criteria, what containment was measured against, what the model was permitted to do, and sanitized session excerpts, along with our acceptance record for the program. Ask and we send them. The complete session logs and full methodology are available under NDA.

There is also a governance answer, and for AI it is the one that matters more. An autonomous system operating inside your environment cannot approve its own change. Approval requires signed receipts from humans you designated, holding keys on their own machines outside Churchill, and any one of them can veto. That property does not weaken as the attacker gets faster or more capable, because it is not a detection question.

It was tried, and it is the most instructive result of the public capture-the-flag.

One session did not attempt to defeat the enforcement path. It extracted the protection binaries out of the protected host into memory it controlled and ran a degraded copy elsewhere, then attempted to present that copy to the control plane as if it were the real host.

The control plane maintains an encrypted heartbeat with each protected host and evaluates it independently of the host's own runtime, which is the point of siting it off-host. The impersonation attempt registered as a protocol anomaly, the kill switch fired, and the attacker's session ended. The protected system was never modified, no flag was captured, and recovery required your quorum rather than an attacker or an operator acting alone.

The general principle: an adversary who cannot get through a mandatory passage point will try to move the target out from behind it. An architecture has to answer for that class of attempt rather than only for direct attacks on the gate.

The refusal happens inside the operating system kernel, in programs that examine an operation and return a permission error before it completes. User space cannot reach them, and neither can root.

This is why Churchill's answer to a root-level attacker is not "we noticed." It is that the operation did not happen.

It is offsite from every client host, deployed as a dedicated single-tenant instance in the region agreed at deployment. In-region, dedicated, single-tenant: exact siting is disclosed under NDA at technical qualification and withheld publicly for security reasons. It is the off-host root of coordination: it confirms Churchill and The Protector are operating, holds the remote half of the evidence chain, and carries your operators' decisions to a host over that host's own signed session.

The operating principle: an attacker who compromises a protected system cannot reach the control plane. An attacker who compromises the control plane cannot push code into a protected host, cannot forge your quorum's approvals, and has no fleet-wide stop to reach for; the most it can direct is enforcement at an individual host over that host's own signed session, on the record. And both at once is not a single-actor threat model.

It is not shared or multi-tenant. Each fleet gets a self-contained instance with no shared global endpoint. For an EU client a dedicated instance is provisioned in region so the evidence record stays there.

Its internal trust separation is covered during technical qualification under the same confidentiality.

Approval keys are held by your quorum members, on their own machines, outside Churchill. WestGate Data Science does not hold them and cannot forge an approval. Members are admitted by passkey only: an invited member creates their own ed25519 passkey from the emailed link, and that passkey doubles as their dashboard sign-in. There is no public key to paste and no key material to hand over. Renaming a member changes a dashboard label; the signing key itself is untouched.

Bundle verification checks both the signature and the signer identity against pinned public keys, so a valid signature from the wrong signer is refused, including a valid signature intended for a different deployment.

Key rotation is a release or change-control event by design. There is no runtime configuration path an attacker with file access could use to substitute trust anchors.

Churchill defends a workload against adversaries with access to the host, up to and including root, after deployment. Debugger attachment, code injection and hooking, unauthorized execution, binary and artifact substitution, memory tampering, filesystem shadowing, privilege escalation and container escape, living-off-the-land exfiltration, and tampering with the protection itself all fall inside that boundary.

Outside it: physical access, and hardware or firmware implants. Perimeter network security and data loss prevention remain yours; Churchill's egress control is a workload-scoped allowed-destination list, not a network intrusion detection system.

We state the boundary because it is load-bearing. A product that claims to stop everything can be trusted about nothing.

No. Nothing leaving a protected host contains application payload.

What leaves is content hashes, process context, the decisions Churchill made, and short reasons for them. Never file contents. Never memory. Never your application's data. Not even command-line arguments.

This is worth stating precisely because it usually shortens a data protection review considerably: there is no processing agreement to negotiate over data we do not receive.

In two places at once, by design. That is what makes it worth anything to an auditor.

Every decision Churchill makes is recorded with full process context, expected versus actual hashes, and a cryptographic hash of the preceding record. The chain is held append-only on the host and synchronized to separate custody in the control plane. Both sides retain the original records rather than a summary or a copy of a copy, so neither can silently rewrite history: altering either one breaks the chain at the exact record where it happened, and the other custody still holds the original to prove it.

One point of precision: we say tamper-evident rather than tamper-proof, and we mean it. Churchill does not claim magically unmodifiable storage. It claims, and delivers, that modification is cryptographically detectable at single-record granularity, in two independent custodies. That is the property an auditor can actually verify, which is the only kind worth claiming.

Yes. The control plane deploys as a single self-contained instance per fleet, with no shared global endpoint. For an EU client, a dedicated instance is provisioned in region and the evidence record stays there.

The location is fixed at deployment and agreed at onboarding.

No. Interactive sessions on a protected host are captured as timestamped terminal recordings, sealed and hashed under a separate privilege domain from the session being recorded and linked into the same evidence chain.

Input typed while the terminal has echo disabled, which is the normal password path, is masked before it is ever written. Secrets do not enter the record in the first place rather than being scrubbed afterward.

Recordings replay from the dashboard, live while an actor is still active and forensically afterward.

Worth raising early rather than in week five: sessions on a protected host are recorded, and the record is tied to the numeric account the kernel reports, not to a person. Churchill holds no directory and has no path to your identity provider, so it cannot resolve that number to a human being. If the host's own identity tooling already resolves an account to a readable name, the dashboard can display that name, but the resolution is your IAM's and nothing in the sealed record depends on it.

Churchill does not displace your identity providers. They verify who is requesting access. Churchill verifies what executes. The two answer different questions and neither substitutes for the other.

Churchill provides continuous structural evidence that a protected application is running in the state your governance approved. That supports specific technical provisions within several regimes, most directly SWIFT CSP, DORA, NYDFS Part 500, PCI DSS 4.0.1, and the HIPAA Security Rule.

Where it applies, it strengthens your evidence for change governance, unauthorized-code prevention, system integrity, and audit trail. It does not cover incident reporting, third-party registers, testing programs, encryption at rest, authentication, or network controls, and we say so on the mandate detail rather than leaving the gap for you to find.

Churchill supports specific technical provisions. It does not itself confer compliance with any mandate. Provision mappings are WestGate Data Science analysis.

The evidence record is built to be read by someone who was not there. Every decision and every refused attempt is logged with chain-of-custody metadata, the approved version is cryptographically signed at approval, and the record is held in two independent custodies.

What that changes for an audit is the starting point. Instead of reconstructing what happened from narrative and inference, an auditor verifies a chain. Whether a given regulator or carrier accepts that in place of a specific procedure is their determination, not ours, and we do not claim otherwise.