Assume the breach. Now decide what the machine is still allowed to do.
Every security framework of the last decade agrees you will be compromised. Almost none of them answers the question that follows: while one of your inputs is already corrupted, what should the system still be permitted to do automatically?
The usual answers are to trust everything until detection fires, or to stop entirely. Neither is operable. Fail-open is how an attacker wins; fail-everything is how an attacker wins cheaply, because denial is easier than deception.
SENTINEL is built for the middle: keep operating, on a smaller set of sources, with the reduction recorded and the dangerous actions withheld.
Four properties that make this a security control
Corruption of one input is contained. Sources are judged against each other, not individually. A single compromised input that disagrees with the rest is refused and counted — it does not get averaged into the answer, which is what most fusion and most scoring pipelines do by default.
Coordinated corruption is a first-class case. Compromising one sensor is hard; compromising three that share a supplier, a library, a data feed or a model family is often easier than compromising one in isolation. Holding out a single source cannot see a group moving together, so SENTINEL evaluates subsets and looks for the signature of two coherent camps rather than scattered noise — and lets a deployment declare which sources share a dependency and hold them to a stricter test.
The evidence cannot be rewritten after the fact. Decision records are sealed and chained. An attacker who gains access later cannot quietly edit what the system decided; the chain breaks, and the break is visible.
The irreversible action is gated on the record. The release is physically conditioned on the record for that interval being committed and verifying first. An attacker who wants the machine to act must defeat the record, not merely the sensor — which is a materially harder target, and one that can be pushed into hardware.
The part that is new: consensus across AI agents
Organisations are now putting several AI systems on the same question — models scoring the same transaction, agents reviewing the same code, classifiers judging the same alert.
They disagree constantly, and the usual responses are to take a majority vote or to trust the one that has behaved best lately. Both fail the same way: a majority is exactly what a prompt-injection or a poisoned shared dependency produces, because the agents sharing a base model or a retrieval corpus fail together and agree with each other while doing it.
Our fourth patent application was written for this case as much as for ships:
- Verdicts as first-class inputs. An opinion over a fixed set of outcomes — allow, hold, block — with a confidence, judged with a declared measure of how far apart two verdicts are, rather than reduced to a number and averaged.
- Judged against everyone else. Each agent is measured against a consensus formed without it, so an agent cannot vote itself into credibility.
- Sudden reversals refused. An agent whose verdict swings further in one step than it plausibly could is refused, and the refusal is recorded against it.
- Shared dependencies declared. Agents on the same base model or corpus are held to a stricter test of genuine disagreement, because their agreement carries less information.
- Nothing irreversible without the sealed record. The agent may recommend; the release is conditioned on the record.
Who this is for
Security architects building assume-compromise designs where automated response is in scope. Fraud and risk teams running several models on one decision, with a regulator to answer to. AI platform and agent-infrastructure teams putting multiple models behind a consequential action. OT and ICS security teams where the compromised input is a sensor and the action is physical. Auditors, insurers and forensic investigators who need to establish what a system knew.
What it is not
- Not detection. It does not find the intrusion, hunt threats, or replace a SIEM or EDR. It changes what the system is willing to do while one input may already be lying.
- Not a guarantee. It bounds how fast a compromised source can move the outcome; it does not stop a patient adversary who moves slowly enough, and our own disclosures state the arithmetic of what that gate does and does not catch. We would rather publish the limit than let a customer discover it.
- Not a product. A working reference implementation, simulation results, no deployment.
- Not a granted patent. Four US provisional applications filed; none examined.
The honest dependency
This only helps if something in the set is genuinely independent of the compromised thing. Agents on one base model, sensors on one supplier, feeds from one vendor — these are correlated by construction, and consensus across them is worth less than it appears. Mapping that is usually the most valuable first week of any engagement, whatever anyone eventually deploys.
What we want from you
A decision your systems got wrong because several inputs agreed and were all wrong together. That case is the one we are built for, and it is the one we want to be tested against.
info@rvappliedsystems.com · RV Applied Systems, Inc., Las Vegas, Nevada
Four US provisional patent applications filed. Patent pending; none examined or granted.