Loading benchmark data…
EyesInAI·Loading live benchmark data
Every prompt you send a provider is data leaving your control.
A prompt is assembled from more than the question — your system prompt, retrieved pages, an uploaded document, the conversation so far. Any of it can carry a credential nobody meant to send. Shieldyard inspects the outbound payload, and the model's reply coming back, for credential-shaped data — in microseconds, watching before it ever acts.
Measured 2026-09-06 on the exact production scan function, release-compiled, over 100,000 iterations on a real four-message turn. Reproduce it yourself: cargo test --release shield::bench -- --ignored --nocapture. Full method and caveats.
Everything below is running in production today — roadmap items are listed separately at the bottom.
The assembled prompt — the visitor’s message, your system prompt, retrieved corpus chunks, an uploaded document — is inspected for credential-shaped data before it is handed to a model provider. Whatever is caught never reaches someone else’s infrastructure.
A model can emit a secret it was never sent — echoing pasted context, surfacing a RAG chunk, or obeying a prompt-injection exfiltration instruction. Streamed responses are reassembled and scanned too, including secrets split across chunk boundaries. OWASP LLM02 is two-sided; guarding one side is not guarding it.
OpenAI, Anthropic, Groq and Google API keys; AWS access keys; GitHub and Slack tokens; bearer tokens; PEM private keys; and shell-style environment assignments. Purpose-built patterns, not a model’s opinion.
Off, Observe, Enforce. Observe detects and audits without changing a single byte of the answer — so you can see exactly what it would have caught, on your real traffic, before it is ever allowed to alter a reply.
Each detector can be switched independently per assistant. A team that legitimately discusses `env` assignments in support tickets can leave that layer off while every key detector stays on.
Measured at ~0.8 µs added per turn in observe mode. A guard implemented as a second LLM call costs 5,600–11,000 ms — four to five orders of magnitude more. That gap is the entire reason this path is compiled pattern-matching and not a model.
A tenant with no compiled policy gets observe: it audits and reports, and never mutates. Enforcement is something you turn on deliberately, per assistant, after you have seen the observe data.
The cost of the layer is measured on the exact production scan function, dated, and reproducible with one command — not asserted in a datasheet. It is on /measured with the method attached.
Where the screening actually sits, and why both directions matter.
A turn is more than the visitor’s question: your system prompt, retrieved pages from your corpus, prior conversation, and any uploaded document are concatenated into one payload. Any of those can carry a credential nobody meant to send — a key pasted into a support ticket three weeks ago, a config snippet in an indexed page.
Ten detectors run against the outbound payload. In observe mode a match is audited and the prompt goes out unchanged; in enforce mode the matched value is redacted first. Either way the decision is made before the provider ever sees the bytes.
The request is forwarded and the model responds — streamed token-by-token, or as one buffered reply.
The streamed output is reassembled and inspected for the same ten patterns, including a secret split across two chunks so that neither chunk contains it whole. This is the side most guards miss, because the bytes are usually piped straight through untouched.
Every detection is audited with the rule that fired. Because observe changes nothing, the audit trail is a truthful record of what enforcement would have done — which is what makes turning enforcement on a decision rather than a gamble.
A security layer that rewrites answers on day one is a layer nobody trusts and everybody switches off after the first false positive. Observe mode exists so the decision to enforce is made from your own traffic, not from a vendor's confidence.
It detects and audits while forwarding every byte unchanged. You read what it caught, layer by layer, and turn on enforcement where the evidence supports it — per assistant, per detector. The audit trail from observe mode is a truthful preview of what enforcement would have done, because the detection is the same code either way.
Listed so the section above can stay strictly what runs today.
Today the streamed-output scan detects and reports while forwarding bytes verbatim. Holding back and rewriting a chunk mid-stream — without stalling the response — is the next slice.
Substituting a placeholder on the way out and restoring the real value in the answer, so a workflow that legitimately needs the secret still works while the provider never sees it.
The current detectors are credential-shaped by design — high precision, near-zero false positives. Broader classes (personal data, customer identifiers) need a different accuracy bar and are being measured before they ship.
Which model answers — measured routing to the least-expensive model that still passes.
What it knows — a hosted assistant built from your own website and live data.
What leaves — outbound and inbound screening for credential-shaped data.
Shieldyard is not a separate product to buy and wire in — it ships inside the gateway and is switchable per assistant. If you already run Switchyard or Groundyard, it is a setting, not an integration.
Observe mode changes nothing about your answers. Turn it on, run your normal traffic, and read the audit — then decide whether enforcement is worth it, with your own evidence.