The only threat intelligence about your systems, from your attackers.
Every feed you subscribe to describes someone else's breach, months ago, somewhere else. Churchill produces the other kind.
The gate that refuses an unauthorized change is the same mechanism that records it. So the moment an intruder, an insider, or an AI agent reaches for your most critical application, you hold a sealed record of exactly what was attempted, by which process and account, on which host, to the nanosecond. The change never ran. The intelligence is yours anyway.
Same record, two jobs. A threat team reads these records to see who is coming for them. A person who co-signs an annual certification reads exactly the same records as continuous, dated, attributed proof that the approved state held. If you are the second reader, start there instead →
Eight teams ask for this record, for eight different reasons.
Nothing here needs to be confirmed first. The question is no longer whether something happened, only who and why.
See which accounts are reaching for the application you cannot lose, and hand HR and legal a record instead of a story you had to reassemble.
Continuous proof that the approved version stayed in place, plus every attempt to change it. Evidence instead of interviews.
The methods being used on your systems, useful the day they are tried instead of months later in someone’s report.
Every record already says what was attempted and what happened to it. That is exactly the labeling machine learning normally needs people to do by hand. Clean examples, about your own systems, with nothing to sort out first.
Refused attempts are not all hostile. The pattern of who keeps pushing unapproved changes at 2 a.m., and from which pipeline, is a measurement of your process, not a mystery.
Attempts refused, impact zero, evidence sealed, over a stated period. The availability line is in the record itself.
Replay an actual recorded session against your own host, keystroke by keystroke, instead of running an exercise somebody invented.
Everything else in the category records what already happened.
| Detection and insider-risk tooling | Churchill | |
|---|---|---|
| When you find out | The change already ran. The alert comes after. | Before the change takes effect. It is refused first, then recorded. |
| How much it sees | Only what its rules were tuned to notice. What you miss depends on how well it was configured. | Every attempt, because nothing reaches the application without passing the gate first. There is nothing to sample and no threshold to tune. |
| What it names | A likely user or machine, assembled from several sources, with a confidence score attached. | What was attempted, what happened to it, how serious it was, which program tried, and which account it ran as, all in one record. |
| Can it be erased | Logs sit on the host, where an administrator with full control can edit or delete them. | Records are chained and kept in two places at once. Removing one leaves a visible gap, and the removal is itself recorded. |
| What it costs you | An actual incident: containment, cleanup, and sometimes a disclosure obligation. | Nothing. Production never stopped, and there is nothing to clean up. |
| Whose attacks | Reports about attacks on other companies, published later. | Whoever is attacking your systems, this week. |
This compares kinds of evidence, not products. Detection and insider-risk tools answer questions Churchill does not: where data moves, how people behave over time, what the network sees. Keep running them. Churchill answers one question they were never built for, and answers it before the change takes effect.
One refused attempt, fully described.
Refuse the unauthorized change, and the intruder's identity stops mattering. Attribution becomes a forensic question you answer from the record, not a guess you make before acting.
- event
- unapproved change refused
- decision
- deny
- severity
- critical
- when
- nanosecond timestamp, UTC
- host
- pay-gw-04
- executable
- the protected binary
- account
- numeric account, with process and parent
- reason
- did not match the sealed version
- sequence
- position in this host's chain
- event
- approved version executes
- decision
- allow
- severity
- info
- executable
- the protected binary
- reason
- matches the sealed version
- sequence
- next entry in the chain
The refused attempt did not match the version the board sealed, and the next chain entry 97 ms later shows the approved version executing normally. The unapproved operation was refused; the application kept running. Confidence high: the mismatch is on a protected path with no preceding approval receipt, and the account is a service identity with no interactive session in the window.
The gate that blocked the operation is what wrote the record, so the verdict is not a guess. Denied means it was stopped, not that something looked suspicious and needs a second opinion.
Which program ran, which program launched it, and which account it ran as, observed on the host at the moment it happened. Nothing here was pieced together after the fact from separate systems.
The timestamp is precise to a billionth of a second, and every record has a sequence number in the host's evidence log. A missing number means someone removed a record, and that itself is the finding.
Every record explains itself in a sentence: what did not match, and against what. Your analyst does not need to decode field names to know what happened.
Events are analyzed and come back as a written explanation with a stated confidence level. Your team reads what it means, not just what happened.
Covering their tracks makes more evidence, not less. An attacker with root who tries to delete the record of what they just attempted generates another record doing it. The clean-up is itself an event, chained to the one before it and held in a second custody. There is no version of this where they leave less behind by trying.
One record is forensic evidence. A thousand records across your fleet is a map of who is coming for you, and where.
Run Churchill across your protected hosts and the individual refusals become a dataset with structure: by host, by event type, by severity, by account, by hour. Every row is an attack that did not land. The pattern is the intelligence.
| Protected host | Dominant event type | Attempts | Reading |
|---|---|---|---|
| pay-gw-04 | churchill_spatial | 41 | Persistent, methodical, after hours |
| stl-02 | refused change | 17 | Same event types as pay-gw-04 |
| hsm-adj-01 | bundle_stranger_exec | 9 | Low volume, high sophistication |
| led-07 | change_rejected | 63 | One pipeline, change control gap |
| bat-11 | refused change | 28 | One uid, business hours, mistake pattern |
| ai-ops-03 | churchill_privilege | 6 | Agent runtime, doing more than it was approved to |
Refused attempts by protected host, trailing 30 days. Production impact: 0. Illustrative shape of the data, not a customer environment. Churchill supplies the records, each tied to a host and an account; the reading in the last column is your threat team's, made possible because the underlying facts are no longer in question.
Sort attempts by host, type, severity, account, and hour and you can see where the effort is actually being spent against you. You harden and staff where the pressure is, not where a checklist says.
Both produce a refusal. One is a single account in business hours repeating the same clumsy operation; the other is patient, varied, and after hours. Replay the recorded session and you can watch which one it was, keystroke by keystroke, live if they are still working.
When the same kinds of attempts, at the same times, show up on separate hosts, that is not three unrelated events. It is one campaign, and you have the records to show it.
Hash-chained records in dual custody across host and control plane, with both sides retaining the originals, each naming the host, the executable, the account it ran as, the decision, and the nanosecond it happened, and the recorded session linked in by hash. Hand it to counsel, to law enforcement, or to your regulator as a fact rather than a reconstruction.
Attempts climbing in number and seriousness against one host is a warning weeks ahead of any emergency decision. That is the point: the conversation happens early, on your terms.
A host with sixty refused hotfixes does not have an attacker. It has a broken change process, and now you can see it, with accounts and timestamps attached.
The first security control that makes your institution smarter every time it is attacked.
Detection tools produce alerts, and alerts age out. Churchill builds a record set instead: every attempt on your most critical applications, already decided, already tied to an account, already sealed. It is yours, it stays in your hands, and it grows on its own.
Machine learning needs examples marked bad or fine, and that marking is usually the expensive part. Churchill has already done it for every attempt on your systems. Your data team trains on what actually happened to you, not on a public dataset describing someone else’s network.
When attacks are automated, the defenses that keep up are the ones taught on real attempts rather than a list of known threats. This gives you a steady supply of real attempts on your own systems to train with.
As AI agents get real access to production, the record shows every time one tried to go outside what it was approved to do. That is the oversight proof boards and regulators are starting to ask for, produced automatically.
In year one it is an evidence trail. By year three it shows who keeps testing your institution, how their methods change, and which of your own processes keep breaking the rules. No vendor can sell you this, and it never leaves your hands.
When a human touches a protected host, the session itself becomes evidence.
Interactive shell sessions are captured as timestamped terminal recordings, sealed into the same evidence chain, and replayable from the dashboard: live while the actor is still working, or forensically afterward. Your analysts watch the session that never became an incident, keystroke by keystroke, at the speed they choose. Passwords typed at an echo-disabled prompt are masked before they are ever written, so secrets never enter the record.
Before privacy and your works council ask.
Recording covers interactive sessions on hosts you have chosen to protect. It is not endpoint monitoring, not workstation capture, and not a general employee-activity tool.
Input typed while the terminal has echo disabled, which is the ordinary password path, is masked before it is written. Nothing is scrubbed afterward because nothing sensitive is recorded in the first place.
Records name the account identifier and the process, not a person. Churchill builds no per-employee profile and performs no behavioral scoring. Resolving an account to a human is your identity process.
The control plane deploys as a single instance per fleet with no shared global endpoint, so an EU entity's recordings stay in the region agreed at deployment. WestGate receives no application payload at any point.
Session recording on production hosts is a labor-relations question in most jurisdictions and a works-council question wherever one exists. Raise it early. Whether recording is lawful in a given jurisdiction, and what consultation it requires, is a determination for your counsel and your works council rather than for us. What we can do is give them the exact scope in writing during evaluation.
The honest boundary, so your architect does not have to find it.
- A user-behavior analytics platform. Churchill records attempts against the protected application, not a behavioral baseline of everything your people do.
- A DLP or network tool. Data movement, email, and endpoint activity outside the protected workload are someone else’s job.
- An identity system. The record names the account and the program that ran as it. Connecting that account to a specific person is your identity and HR process, not Churchill’s.
- A feed you can resell. This intelligence is about your environment and stays in your custody. WestGate does not aggregate or monetize it.
- A model, or a claim to train one for you. Churchill produces the labeled record and the export; what your data science team builds with it is theirs.
One question, answered completely: did anyone, or anything, change what your most critical application runs, and can you prove it either way.
See a record from your own environment.
Your first refused attempt is usually the demo.