Most monitors watch for attacks. Fewer watch for the search for their own blind spot.
AI Runtime Guard runs four independent detection engines side by side — including one built specifically to catch automated, AI/ML-driven adversaries probing for a system's exact detection threshold — inside a monitoring agent hardened against being blinded, killed, or quietly rewritten.
Attackers don't only target the workload anymore.
Runtime monitors are built to recognize known-bad behavior — a suspicious process, an unexpected connection, a sensitive file touched at the wrong time. That's still necessary. It's no longer sufficient.
An emerging class of automated, AI/ML-driven adversaries doesn't stop at the workload. It systematically probes the monitor itself — trying variations, watching what gets flagged, hunting for the exact edge of a detection threshold. Most tools have no way to notice that kind of search at all, because they only ever look at one event at a time, never the pattern across their own verdicts.
The threat is moving faster than most teams are ready for.
None of this is speculative. Global cybersecurity leaders are already naming AI as the dominant driver of change in the field — and saying openly that most organizations aren't ready for what that means.
of surveyed cybersecurity leaders name AI as the most significant driver of change in the year ahead.
flag AI-related vulnerabilities as the fastest-growing cyber risk they're currently tracking.
organizations still have no process to validate an AI system's security before it's deployed.
point to a lack of in-house knowledge or skill as their biggest barrier to defending against it.
Source: World Economic Forum, Global Cybersecurity Outlook 2026 — survey of global cybersecurity leaders.
One product, two jobs.
A monitoring layer only matters if it can't be talked around, and can't be turned off. AI Runtime Guard is built as two halves that depend on each other.
Four independent engines, cross-checked
Each engine can catch what the others structurally cannot. Alerts are the union of their verdicts, tagged by which engine caught it.
- engine 1 Rule & statistical baseline. Streaming behavioral deviation plus MITRE ATT&CK-style heuristics — deterministic, auditable, no training step.
- engine 2 Unsupervised ML. An isolation-forest model over event context, plus a rate/burst detector for volume no single event reveals.
- engine 3 Process-lineage sequence model. Catches multi-hop, living-off-the-land chains where every individual hop looks quiet.
- engine 4 Probe / search detection. Watches the other three engines' own verdict stream over time for the signature of automated boundary-hunting.
Hardened against being the first thing attacked
The agent watching for intrusion is itself treated as a target — and defended like one.
- signed log A hash-chained, cryptographically signed audit log. Editing one past entry breaks every fingerprint after it.
- attestation Startup and on-timer code-integrity checks against a manifest requiring two independent release signatures.
- watchdog An independent supervisor restarts a killed or hung agent — and signs the restart itself.
- dashboard A live view that re-verifies the signed chain itself, rather than trusting the agent's own report of its health.
When the attacker is patient, automated, and reading your thresholds.
Every detector has to draw a line somewhere — a threshold past which something counts as suspicious enough to act on. A patient, automated attacker can try many slightly different attempts and use the pattern of what gets flagged to find that line, without ever needing to know it in advance.
Engine 4 doesn't look at raw events. It watches the verdict stream the other three engines already produce, for three statistical signatures of exactly that kind of search.
- 01 Near-threshold clustering — many recent verdicts landing suspiciously close to the line
- 02 Systematic sweep — a monotonic run of scores, the signature of a parameter being walked toward the cutoff
- 03 High-velocity repetition — many structurally similar attempts, arriving far faster than organic traffic
A working system, not a deck.
Every claim above runs, end to end, against a scripted threat scenario — not a mockup.
The signed log can be re-verified offline by anyone holding only the public keys — the same way a human investigator would, with no other context.
Known limitations — including where the ML engine's precision is currently modest — are documented in the architecture, not glossed over.
Multi-minute sustained-load runs check for false positives on pure normal traffic, not just a short scripted demo.
Synthetic telemetry today, with an adapter pattern designed so real container-runtime events swap in without touching detection logic.
AI Runtime Guard is an early-stage, single-team product with a complete working proof of concept. We're currently in conversation with a small number of design partners — if that's you, we'd like to hear what you're seeing.
Let's talk about what's watching your systems.
A short walkthrough of the live dashboard and the seven-act threat scenario is the fastest way to see how the four engines behave against a real attack — including the one built to catch the search for its own boundary.