Questions a technical evaluator asks. Answered.

Churchill operates alongside existing kernel security modules. SELinux, AppArmor, and similar mandatory access control layers enforce rule-based policies at kernel decision points. Churchill operates at a different layer, verifying that what is running matches the governance-approved application unit. The two are complementary: existing modules continue to enforce their declared rules; Churchill verifies the artifact itself.

No reconfiguration of your existing kernel security modules is required to deploy Churchill.

Churchill's verification is pre-execution at the kernel boundary. Mean Time to Remediate on a blocked attempt is under 2 milliseconds. Approved executions proceed at native speed. Verification uses a cryptographic lookup against a pre-authorized reference, not a re-computation on every execution.

During the Mythos engagement, Churchill made 406,433 enforcement decisions in 11.3 hours of adversarial activity with no measurable degradation to protected workloads.

Churchill supports containers, virtual machines, and bare metal Linux on x86 and Power. For Kubernetes and short-lived container environments, Churchill verifies the deployed image against the quorum-approved version. Short-lived workloads receive the same governance enforcement as long-running services.

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

Linux kernel 5.7 and higher, validated on IBM LinuxONE. Compatible with Linux on x86 and Power, containers, virtual machines, and bare metal.

Windows Server and Windows CE support is in development.

Churchill is a kernel component on Linux. It deploys through standard enterprise host provisioning, the same way any kernel-level agent rolls out across a system: image baking, configuration management, container base images. Every UI and middle-tier node gets Churchill at boot, and the policy reference loads automatically from the quorum-authorized source.

Everything that defines the CAB-approved version of your application:

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

Together they are the single source of truth for what is allowed to run: cryptographically signed, delivered over an encrypted channel, held in protected memory the host cannot alter. Nothing on disk can be swapped underneath it.

Churchill is designed for fail-secure operation. If the runtime gate cannot make enforcement decisions, protected systems do not continue executing unverified work.

The Watcher confirms Churchill's operational state independently from outside the protected systems. If Churchill goes silent, The Watcher detects the anomaly and triggers a defined imminent-breach response.

Specific failover behavior, recovery times, and operational continuity tooling are configured during the pilot to fit your environment's availability requirements.

Churchill does not modify your build pipeline. Your CI/CD continues to produce artifacts as it does today. At the deployment moment, your established quorum signs off on the new version through the Churchill UI; Churchill re-captures and re-seals the application. Each cycle takes minutes.

Churchill is suited to crown-jewel applications where governance approval already exists at each release. It is not designed for applications where release cadence is faster than governance approval can support. That is an explicit design choice, not a limitation.

Churchill requires a minimum of two quorum members to authorize a change. The client assigns those two, plus as many additional authorized members as they want for redundancy. There is no fixed roster size and no delegation chain.

The system enforces two rules at the kernel: any quorum member authorizing a change must be on the authorized list, and at least two authorized members must approve before the application is sealed. Beyond that, the client decides who signs from the available pool at the time of a release.

Adding more authorized members costs nothing operationally. It removes single points of failure without adding workflow complexity.

Each quorum-approved application is a distinct cryptographically signed package. Rolling back to a prior approved version is a governance action. Your quorum signs the prior package as the active enforcement target, and Churchill restores enforcement to that application.

No re-installation, kernel reboot, or system reconfiguration is required.

The Watcher operates offsite from the systems it monitors, in a high-security data center environment, deliberately separated from any system Churchill is protecting.

The operating principle: an attacker who compromises a protected system cannot reach The Watcher; an attacker who compromises The Watcher cannot reach a protected system; both being compromised simultaneously is not a single-actor threat model.

Architectural details of The Watcher's trust separation (including its independence from any single cloud, identity, or kernel layer) are reviewed in depth during the pilot under appropriate confidentiality.

Each approved application is signed at the moment of quorum approval. Signing keys are not held by WestGate Data Science. They remain in your control, integrated with your existing key management architecture.

Specific key management patterns (HSM, cloud KMS, or on-premises) are reviewed against your existing infrastructure during the pilot.

Churchill operates at the kernel, not on top of it. The Protector (the layer that anchors Churchill in the kernel) is structurally isolated from the protected system's user-space and root surface. A kernel zero-day that exploits the protected application does not defeat Churchill's enforcement, because Churchill's enforcement layer is not reachable from the application's execution context.

This was tested explicitly in both the public CTF (40 autonomous AI sessions with full root from session start) and the Mythos engagement (multiple sessions beginning with full root). Zero kernel breaches in either program.

Not the injection itself. That is an application-layer problem, and your input validation, WAF, and RASP stay in place to handle it on every system, protected or not. Churchill sits one layer beneath them.

On a Churchill-protected application, no injected code gets executed. The injection may land, but the moment it tries to run a payload, escalate, or persist, it does not run, because it is not part of the CAB-approved application. The injection becomes a dead end instead of a foothold, and every attempt is logged.

Forensic recordings remain in your environment by default. Churchill produces forensic packages (recordings, logs, chain-of-custody metadata) that are stored where you direct, accessible to the personnel you designate.

Recordings are cryptographically signed at capture time, ensuring chain-of-custody integrity for legal, regulatory, or law enforcement use. Cross-environment retention, archival, and access controls are configured during the pilot.

Yes. Churchill produces structured event data (enforcement decisions, blocked attempts, forensic recordings) suitable for SIEM ingestion via standard formats. SOAR playbooks can trigger on Churchill events the same as any other security telemetry source.

Churchill does not displace your identity providers. IAM and authentication continue to verify who is requesting access. Churchill verifies what executes, separately. Specific integration patterns for your stack are configured during the pilot.

Churchill provides structural evidence of approved-state enforcement, continuously. This maps directly to controls in the following regulatory regimes:

• DORA: ICT third-party risk and operational resilience requirements
• NERC CIP: Configuration management (CIP-010) and system security management (CIP-007)
• HIPAA Security Rule: Audit controls §164.312(b) and integrity §164.312(c)(1)
• CMMC 2.0: Configuration management family at Level 2
• PCI DSS 4.0: Testing of security systems (Requirement 11)
• NIST 800-53 Rev 5: Controls in the CM (configuration management), SI (system and information integrity), and AU (audit and accountability) families

Specific control mapping for your regulatory regime is reviewed during the pilot.

Yes. The application unit is cryptographically signed at quorum approval. Every enforcement decision and every blocked attempt is logged with chain-of-custody metadata. The evidence record is designed to be reviewed by external auditors, regulators, insurance carriers, or law enforcement without requiring reconstruction of what happened.

This is the operational meaning of "compliance becomes structural proof, not narrative reconstruction."