Churchill's Protocol.What runs is what you approved.
Churchill verifies what is actually running against the version your governance board approved. Every time it runs, continuously while it runs. Anything else is blocked at the kernel boundary before it executes.
Verified continuously against the approved package.
Even with root, nothing executes that the Change Advisory Board did not approve.
Where the jewels live. How threats reach them.
The protected applications that hold the data.
The systems that hold the data and run the regulated business.
- Banking cores
- Settlement engines
- Payment rails
- Electronic health records
- Pharmacy and lab systems
- AI agent runtimes
- Industrial control systems
- ERP and supply chain backbones
- Mainframe partitions running the regulated business
Upstream verification has a known limit.
Build pipelines sign whatever the build infrastructure produces. Identity layers verify whoever has the credential. Both operate upstream, before code runs on the system that holds the data.
Once an attacker is past the upstream layer (through a compromised build, a stolen credential, or an autonomous AI agent with delegated permissions) anything can happen on the system that holds the value.
Churchill verifies what is actually running on the system that holds the data, at the moment it runs. After upstream verification. After the attacker is already inside. Even with root.
Setup follows your governance. Then Churchill enforces continuously.
After Churchill is downloaded, a guided UI walks your team through two governance steps. Once complete, the system runs autonomously until the next release or patch.
Controlled deployment
Churchill installs on your protected systems through a controlled download. No pipeline changes. No modifications to your build infrastructure.
Establish governance
The Churchill UI prompts you to designate a minimum of two quorum members from your Change Advisory Board. We recommend pairing your release decision-maker (Release Manager or VP Engineering) with your executive sponsor (CISO or CTO).
Quorum seals the application
Your quorum selects the application to protect and clicks enter. The approved version is captured as a cryptographically signed snapshot: executables, configurations, libraries, scripts. That snapshot now defines what is allowed to run, verified in real time at full speed. Anything outside it is diverted to the kernel-level mirror envelope before it executes and preserved as forensic evidence.
Two signatures per release. Seconds each.
You already approve every deployment, patch, and rollback, usually through emails and loose decisions. Churchill replaces that with one electronic signature: sign once to take the application down, once to bring it back. Seconds each, 2 a.m. or 5 p.m., on your schedule and no one else's. Nothing else about maintenance, patches, or releases changes.
Two signatures. Seconds each.
Nothing about your release process changes. CI/CD builds, governance approves. At the moment of approval, Churchill prompts the quorum you already designated to sign, in seconds, at 2 a.m. or 5 p.m., on your schedule.
- Sign to take the application down.
- Churchill re-seals the new approved version.
- Sign to bring it back. Enforcement resumes against the new state.
Nothing to manage.
Churchill runs autonomously against the sealed application. The system is protected continuously. The CISO and CAB receive intelligence on attempts, on their own review schedule.
- No ticket queue to triage.
- No daily review burden.
- No additional FTEs required.
- No alert-fatigue cycle.
The security itself does not create the next operational problem. We thought this through.
The byproduct is threat intelligence.
When Churchill blocks an unapproved change, the action does not just stop. It is diverted into a kernel-level mirror envelope. The attacker believes they succeeded. They keep working. They reveal their entire playbook, in real time, against a system that does not exist.
Attempts an unapproved change
Could be a privileged employee. Could be a credential-theft attacker. Could be an autonomous AI agent. Even with root.
Blocks pre-execution at the kernel
The action is verified against the quorum-approved application. It does not match. It does not execute on production.
Captures the full playbook
The action is diverted into a kernel-level mirror. The insider believes it succeeded. They keep working. They reveal everything.
The protected application keeps running. No outage. No remediation queue. No incident response window. No ticket queue.
Pre-execution blocked transaction log. Recording of the methodology. Behavioral telemetry of the mirror execution. Before the insider knows they were identified.
Churchill holds while you assess the insider, before they suspect you're onto them. Even with root, the insider cannot unilaterally change the system.
How Churchill compares to the rest of the stack.
Where Churchill operates relative to every other layer of the security stack.
| Layer | Tooling | Mechanism | Timing & Scope |
|---|---|---|---|
| Application | EDR, SIEM, RASP, WAF | Observes application activity and network traffic. Recognizes known attack patterns from what it sees. | After execution. Generates alerts for review. |
| Identity | IAM, sudo, RBAC | Verifies who is requesting access by checking credentials. | Before access. Identity-based decisions. |
| File integrity | FIM | Detects when monitored files have been modified on disk. | After modification. Alert-based. |
| Binary execution | Whitelisting | Checks each executable's digital fingerprint against an approved list before it runs. | Pre-execution. Each executable checked individually. |
| OS hardening | Linux Security Modules | Enforces predefined rules about what processes are allowed to do on the operating system. | Rule-based. At specific operating system decision points. |
| Runtime clearance | Churchill | Verifies the protected application against the version your Change Advisory Board approved (recommended members: CTO, CISO, Release Manager). Continuously, while it runs. | Pre-execution. Full application. Every action. Requires governance, by design. |
| Firmware | Secure Boot, TPM | Verifies the system's boot sequence has not been modified, using hardware-based trust. | At system startup only. |
The endpoint is the entry. The server is the target.
"Aren't most attacks coming through Windows endpoints, not Linux servers?"
We agree. The endpoint is the landing site. The Linux server is the damage site.
The endpoint is where phishing lands. The file server, the database, the application server, and the AI runtime are where encryption, lockup, exfiltration, and pivot actually happen.
EDR does the real upstream work, and Churchill doesn't displace it. Churchill protects the critical Linux systems downstream where the actual loss occurs, plus Windows CE for embedded and critical control environments.
Endpoint defense and identity tools belong on the Windows endpoint. Churchill belongs on the system the attacker is trying to reach.