New · Runtime Guard, in preview

Your audit found the way in.
Now the same finding
watches the door.

RedLens has spent its whole life proving how your AI breaks and writing that down as evidence an auditor will accept. Runtime Guard is the stage that was missing: the same finding, the same methodology code, and the same vocabulary, now watching the live request. Not a second product. The last step of the one you already have.

See the whole loop Follow one finding through
AUDIT FINDING · F-2041 Indirect prompt injection · confirmed reviewed, never auto-applied RUNTIME RULE · policy v2 Carries F-2041 as its provenance LIVE TRAFFIC allow allow flag block → F-2041
Where this actually stands today
It is a preview
Available to existing RedLens audit customers, not self-serve, and labelled PREVIEW inside the console.
It observes and flags
Shadow mode enforces nothing. Blocking sits behind a gate that has not been passed. The criteria are further down this page.
Nobody is running it live
Every number and screenshot here comes from a synthetic test tenant, visibly named as one. There is no customer result to report yet.
Nothing enters your stack on its own
You install the client, you publish the policy, you choose the mode. RedLens does not deploy anything into your systems for you.
One taxonomy, five stages

The loop was always meant to close

RedLens finds the attack, scores it, and writes it into an evidence record your auditor can read. That has been the product for a long time and none of it changes. What changes is what happens to a finding after the report: it now becomes a rule, and the rule watches the live request. Same finding ID. Same methodology code. Same three status words. Here is the whole thing, end to end.

Stage 1 · Auditshipped · the core product
The scanner proves how it breaks
The Red Team Scanner fires real adversarial attacks from the Master Attack Schema v2.0: 6 categories, 18 methodologies. Not a checklist: an attack that either worked or didn't, scored by CVSS and marked confirmed, unconfirmed, or false positive by a human.
Stage 2 · Auditshipped · the core product
The finding becomes evidence
Every confirmed finding maps to real controls inside an Evidence Package: HIPAA Security Rule, NIST AI RMF, ISO/IEC 42001 Annex A, the FBI CJIS Security Policy. Each control reads evidence, partial, or gap. Never "compliant". That vocabulary is about to matter twice.
Stage 3 · Auditshipped · the core product
The report goes to the people who decide
The Boardroom Risk Translator turns confirmed findings into a briefing directors can read, citing the real findings underneath. Then, historically, the loop stopped. You knew exactly how you could be attacked, you had the paperwork, and the next time somebody actually tried it nothing on the RedLens side was watching.
Stage 4 · Runtimenew · Runtime Guard, preview
The same finding becomes a rule
Each confirmed, non-false-positive finding is translated into a per-tenant runtime signature that carries its finding reference with it. Candidates are built for review, never auto-applied. A finding that is unconfirmed, dismissed, or in a methodology with no runtime form is skipped with the reason on screen, because a rule you cannot justify is a rule you should not be running.
Stage 5 · Runtimenew · Runtime Guard, preview
The verdict comes back in the audit's own words
The rule watches live traffic and every hit names the finding that authored it. Coverage is then reported in the exact three words from Stage 2: evidence when detection is active and enforcing, partial in shadow, gap where a confirmed finding has no runtime form. The audit's vocabulary describing runtime, so the record reads as one continuous story rather than two tools bolted together.
Where the seam still shows. Runtime coverage is reported in the evidence pack's vocabulary and rendered in the Runtime Guard console. It is not yet folded into the generated evidence package itself. That last stitch is not shipped. We would rather point at the seam than let you find it during an audit.
The RedLens Runtime Guard console: blocked and total verdicts over 24 hours, Edge compute p99, circuit-breaker state, a per-project table of published modes, and hot-path latency percentiles
Stage 5, on screen. Published mode per project, twenty-four hours of verdicts, breaker state as reported by the clients themselves, and the Edge's own latency histogram. Captured against the synthetic test tenant. The client column reads Meridian Health AI (synthetic) on purpose.
The same finding, all five stages

Follow F-2041 the whole way

Abstractions are easy to agree with and easy to forget. So here is one finding, a real row from the synthetic test tenant, carried from the attack that proved it through to the verdict it produces at runtime. Nothing in this table is a different system talking about the same thing. It is one record, growing.

Stage 1
The attack lands
A directive hidden in an uploaded document is followed by the assistant as if the operator had written it. Methodology IPI, Indirect Prompt Injection, under ATA · Agent and Tool Abuse. Recorded as F-2041, confirmed by a human.
Stage 2
It becomes controls
F-2041 maps to HIPAA §164.312(b) Audit Controls, HIPAA §164.312(e)(2)(i) Encryption in Transit, NIST AI RMF MS-2.6 AI Monitoring, and OWASP LLM01. Read that NIST control again. The audit's own answer to this finding is monitoring. For years RedLens could name that control and not help you satisfy it.
Stage 3
It reaches the board
F-2041 appears in the briefing as a plain-language risk statement citing itself as the source: not a generic warning about prompt injection, but the specific thing that worked against your specific system.
Stage 4
It becomes a rule
Because F-2041 is confirmed and IPI has a runtime signature form, it becomes a candidate rule tagged with its own finding ID, reviewed before publication and never auto-applied. Sibling findings that were dismissed or unconfirmed are skipped, and the reason is printed next to them.
Stage 5
It fires, and says why
The rule catches the payload again in live traffic, including an obfuscated recurrence the normalization pre-pass unwrapped, and the verdict reads from finding: F-2041. Runtime coverage for indirect_prompt_injection then reads evidence when enforcing, partial while in shadow.
The gap
And the one that doesn't
Its neighbour TCH, tool-chain hijack, has confirmed findings and no runtime signature form. It does not quietly drop out of the story. It reads gap: "confirmed findings in this methodology, but no runtime coverage yet." The loop is honest about where it is still open.
Stages 1 and 5, on one screen

The join nobody else can make

Plenty of products run adversarial tests. Plenty of products filter traffic. Some vendors even do both, and their two halves still have nothing to say to each other, because a test suite and a traffic filter were built by different teams against different taxonomies. RedLens's halves were not. The methodology code that scored your finding is the methodology code the guard reports coverage against; the finding ID that broke you in the audit is the finding ID stamped on the verdict. This screen is the whole argument, and it is one screen because it is one system.

Rule Provenance panel listing findings F-2041 and F-2044 with what each blocked or flagged, beside a Runtime Coverage panel reading two evidence, zero partial and one gap across the IPI, PI and TCH methodologies
Left: Stage 1 doing work at Stage 5. Each row is one confirmed audit finding whose generated rule has fired; F-2041, the finding traced above, is among them. Right: Stage 2's vocabulary describing Stage 5: evidence, partial, gap, the same three words the evidence package uses. The TCH row is the honest one: confirmed findings exist for that methodology and no runtime signature form does, so it reads as a gap and stays visible as one. Synthetic test tenant.
A guard our own scanner could defeat is not a guard
RedLens's scanner already generates base64-wrapped, homoglyph-substituted, zero-width-padded and HTML-comment-buried variants of these payloads, because that is what real indirect injection looks like. A plain pattern match would miss every one of them.
  • The Edge normalizes before it matches (decode, fold, strip, expose), so an obfuscated recurrence of your own finding is still recognised as that finding.
  • The Go signature layer is held to a golden parity gate against the shipped Python detector, category for category, on a shared corpus. It is not trusted beyond observing until that gate is green.
  • Detections are streamed off the hot path. There is no database call and no model call between your request and its verdict.
What gets stored, and what deliberately doesn't
The guard sees your production traffic. That is a serious thing to hand a vendor, so the retention posture is narrow by construction rather than by policy.
  • Only verdicts with detections are stored. Clean traffic is counted, not kept.
  • Stored detections carry a bounded excerpt, not the request.
  • SIEM events use the same normalized envelope the shipped exporter already emits, and carry no transcript. It is the same exclusion discipline, applied to a new event type.
Reliability posture

If RedLens goes down, your traffic doesn't

This is the part of an inline product that most vendors leave to the fine print, so it goes near the top here instead. RedLens rewrote its own SLA page once already to withdraw uptime guarantees it could not measure. Putting a RedLens dependency in front of your users' requests would have re-created that dishonesty at much higher stakes. Fail-open inverts it: a RedLens outage costs you coverage, never availability.

  • Every check runs against a 75ms client-side deadline. A check that would miss it fails open, is counted as a degraded window, and is never queued.
  • A circuit breaker opens after repeated failures. Traffic then flows unchecked until the Edge recovers, never queued and never blocked.
  • Fail-closed exists as a deliberate per-check opt-in, not a default anyone can trip into.
  • Breaker state is reported by your own clients. When they go silent the console shows stale, never healthy.
p50
0.13ms
p90
0.45ms
p99
0.66ms
max
1.12ms
Edge hot-path compute across 13,100 checks: p99 uses 1.0% of the 75ms end-to-end budget. Measured in the synthetic test environment, not on a customer workload, and it excludes network and client time. Treat it as a design headroom figure, not a service level.
Console banner reading Circuit breaker OPEN, explaining that the SDK is failing open and traffic flows unchecked until the Edge recovers, above stat cards showing one open breaker
What a bad day looks like on screen. The breaker is open, traffic is flowing unchecked, and the console says so in those words, including that coverage is degraded and is being counted. A product that hides this state is a product that will eventually surprise you with it.
Before anything blocks

Three things have to be true, and one of them isn't built yet

Enforcement is not a toggle somebody can find in a settings page. It is gated in code, the gate is visible in the console, and one criterion is honestly marked as missing rather than quietly assumed.

CRITERION 1
At least 30 days in shadow, on real traffic
Not a lab corpus and not a replay. The rules have to have watched the actual shape of your production traffic for long enough that the quiet edge cases have had a chance to show up.
CRITERION 2
At least 100 observed verdicts
Thirty days of near-silence proves nothing. There has to be enough signal to say something about the rules' behaviour with a straight face.
NOT BUILT
A false-positive labeling loop, which does not exist yet
Measuring a false-positive rate requires somewhere for a human to say "that one was wrong" and for that judgement to reach the rules. Until that exists, no amount of shadow data licenses blocking, and the gate cannot pass. This is stated here for the same reason it is stated in the console: it is the honest reason the answer to "can I turn on blocking" is still no.
For MSSP partners
Partners get one rollup across the whole book: published mode, twenty-four hours of verdicts, breaker health, and each client's progress through the gate above, per client. Alerts carry the partner's own branding rather than leaking RedLens as the vendor behind them. The gate applies identically: blocking cannot be enabled from a partner console either. More on the partner program →
Scope, stated plainly

What RedLens does not do

RedLens is a lifecycle, not an all-in-one platform, and the difference matters when you are the one signing for it. Here is the list a competitor would hand you, written by us first so you do not have to find out from them.

Not in the product, not on the roadmap
Each of these is a different technical domain and a different buyer. Building them would dilute the one thing RedLens can actually prove.
Data loss prevention breadth
There is one narrow, healthcare-specific data check: the PHI Egress Scan, which triages a sample for PHI-shaped content heading to a vendor with no BAA on file, and which is a signal for compliance review rather than a determination. That is the extent of it. There is no general PII, secrets or sensitive-data coverage across your estate, and RedLens is not a DLP product.
Employee shadow-AI governance
RedLens can passively spot unmapped models and agentic calls inside outbound traffic telemetry you point at it. It is not an org-wide discovery and governance product for which AI tools your staff are signing up to, and it will not tell you who in the building is pasting things into a chatbot.
Model-file scanning
RedLens does not inspect serialized model artifacts for malicious code. That is a real problem with real specialists in it; they are not us.
Content moderation
Runtime Guard looks for attacks on your AI. It is not a toxicity, brand-safety or policy filter on what your AI says to your users.
True of Runtime Guard, today
Limits of this specific capability at this specific moment. Every one of them is visible in the console too, not just here.
It is not classifier-grade detection
This is a signature layer with a normalization pre-pass, driven by your own findings. It is not a trained detector, and not parity with a dedicated detection vendor. It is deliberately narrow, and narrow is what makes the provenance claim true.
Not every methodology has a runtime form
Tool-chain hijack is the clear example: confirmed findings exist for it, and no runtime signature does. Coverage reads that as a gap and keeps showing it as a gap. A finding you cannot enforce is reported, never quietly dropped.
It is not enforcing anything yet
Preview, shadow mode, gate unmet. If you need something blocking traffic this quarter, this is not that product this quarter, and we would rather say so on the website than in the third call.
It is not customer-proven
No live customer, no case study, no attacks-stopped number, and nothing on this page should be read as one. The claim we are making is narrower and, we think, more interesting: the audit and the runtime guard now share one taxonomy, and you can watch a finding become a rule and a rule become a verdict end to end.
Common questions

What your security team will ask first

Is Runtime Guard a separate product I have to buy into?
It is a stage of the platform you already have, not a parallel one. It runs on your existing findings, your existing methodology codes, and the evidence pack's existing status vocabulary, so there is no second taxonomy to learn and no re-onboarding. It is in preview with existing audit customers today, and how it is packaged is a conversation for the demo rather than something this page will pretend is settled. If you never turn it on, nothing about the audit half changes.
Is Runtime Guard blocking attacks today?
No. It runs in shadow mode: it observes and flags, and enforces nothing. Blocking is held behind a gate: at least 30 days of shadow observation on real traffic, at least 100 observed verdicts, and a false-positive labeling loop that does not exist yet. Until all three are true, blocking cannot be enabled from any console, including a partner's.
What happens to my traffic if RedLens goes down?
It keeps flowing. Every check runs against a 75ms client-side deadline, and a check that misses it fails open. That counts as degraded coverage, never queued and never blocked. A circuit breaker opens after repeated failures and traffic runs unchecked until the Edge recovers. RedLens being unavailable degrades your coverage, not your availability.
Where do the runtime rules come from?
From your own confirmed findings. Each confirmed, non-false-positive finding becomes a candidate rule carrying that finding's reference. Candidates are built for review and are never auto-applied. Findings that are unconfirmed, marked false positive, or in a methodology with no runtime signature form are skipped with the reason stated on screen.
Does this mean my AI is protected?
No, and the product will not use that word. Runtime coverage reads in the same vocabulary as the evidence pack: evidence, partial, or gap. Evidence means detection is active and enforcing, partial means shadow observation only, and gap means no runtime coverage. None of those statuses asserts protection or compliance.
Get started

Five stages. One finding.
One vocabulary.

The audit half has been proving how your AI breaks for a long time, and it keeps doing exactly that. Runtime Guard is the stage that finally does something with the answer. A demo walks one finding through all five stages on a synthetic tenant (attack, controls, briefing, rule, verdict), including the stages that still read as gaps.

Book a demo Start with the free assessment