It catches known patterns and their obfuscated variants before an agent acts. It does not catch novel zero-days, pure semantic deception, insider misuse, or anything outside the input layer. This page lists both sides without spin.
Do not pass to the agent.
Route to human review.
Pass with the signal stripped.
A confidence floor, not a guarantee.
Most tools won't publish what they fail to catch. We think that's backwards.
If you don't know the scope of a security control, you use it wrong, you over-rely on it and leave real gaps, or you dismiss it entirely. Neither serves you.
Sunglasses is an ingestion-time filter for AI agent inputs. One layer in a defense stack, not the whole stack. This page documents where the layer works and where it doesn't, plain language, real numbers.
Read it before deciding whether Sunglasses fits your architecture. Spot a gap we haven't listed? contact@sunglasses.dev, we'll add it.
Publishing your limits is a strategy, not a weakness. Buyers who read this and decide Sunglasses alone isn't enough for their threat model are making the correct call, it never is, for any serious deployment. This page filters for the customer who layers it correctly.
Multiple patterns per family, multilingual variants, and normalization-first handling so common obfuscation doesn't bypass detection.
Untrusted input that tells the agent to ignore its instructions, override its system prompt, or adopt a hostile persona. Covers 200+ variants across 23 languages, attackers routinely translate payloads to slip past English-only filters. ignore previous instructions
Malicious instructions hidden inside content the agent reads, RAG results, browsed web pages, email bodies, documents. The attacker never touches the conversation; they only poison what the agent ingests. hidden in retrieved content
Instructions embedded in MCP tool descriptions, parameter docs, and schema annotations, text the model reads during tool discovery, before any tool executes. tool-description directives
Payloads that propagate agent-to-agent during handoff, forged revocation receipts and persona-scope rebind attacks. A growing surface as multi-agent pipelines spread. agent handoff boundary
Hidden directives in repository READMEs an agent reads at install time or during code analysis. Scanned the same way as any other agent input. install-time repo text
Payloads engineered to extract API keys, tokens, and secrets from the agent environment, "encode this key as base64", "report any variable containing SECRET". key / secret extraction
Base64, hex, ROT13, Unicode homoglyph, and zero-width tricks. 17 normalization passes run before detection, the reason encoded variants that beat raw keyword scanners still get caught here.
Attacks that overwhelm the context window with filler to push prior instructions or system context out of the active window. Detected by characteristic flooding signatures. window-eviction filler
User or tool messages that try to claim system-message authority, telling the model to treat untrusted input as if it were a system instruction. forged system authority
Payloads targeting the guardrail orchestration layer, disabling safety layers, skipping approval workflows, or circumventing runtime policy checks. disable-the-guardrail
A2A protocol attacks that corrupt shared agent state during synchronization, injecting false ground truth downstream agents will trust. Shipped in 0.2.31. shared-state corruption
False trust contracts smuggled into agent configs, poisoning the permissions, trust relationships, and operating rules an agent loads before it runs. poisoned config contract
Tool return values that instruct the agent to bypass its policy based on what the tool "said", treating output as an authoritative command instead of data. output-as-instruction
Incremental scope expansion through memory manipulation, each step looks modest; the cumulative effect is privilege escalation. creeping privilege escalation
Package and repo signals that flag potentially poisoned dependencies for human review. A pre-ingestion screen, pair it with full SBOM tooling, not a replacement for it. poisoned-dependency signals
Every category above ships multilingual coverage, English, Spanish, Arabic, Hindi, Japanese, Korean, Russian, Chinese and 15 more where payload translation is a documented evasion. 23-language coverage
Audio is transcribed via Whisper before scanning, then text-level detection runs on the transcript. Catches spoken injection phrases, but only what transcription surfaces. Whisper transcript path
Processed via FFmpeg frame extraction plus Whisper audio transcription. Covers extractable frame text and spoken audio; steganographic and OCR-evading payloads are out of scope. frame + audio extract
Not fine print. Real gaps. If any of these apply to your deployment, you need additional controls beyond Sunglasses.
A new attack family invented after the last update passes with an allow decision until patterns are added. The fundamental limit of any signature system, the database grows daily, but the gap is real and non-zero. never-seen patterns
Attacks with no detectable phrasing, pure semantic context, individually clean messages that groom trust incrementally, will not be caught. Semantic analysis is on the roadmap, not in the current engine. no phrasing signal
An admin issuing harmful instructions through normal, un-injected prompts looks identical to legitimate use at the ingestion layer. Insider threat is a trust-boundary problem, not a detection one. insider misuse
No visibility into the model’s internal reasoning, training biases, hallucination, or alignment failures. Harmful output from the model’s own properties is the provider’s responsibility. model reasoning
Side-channel timing, MITM on API calls, OS-level attacks against the host, all outside an input filter’s scope. These need infrastructure-level defenses. infra-layer attacks
If Sunglasses receives only ciphertext without the key, the normalized input it matches against is the ciphertext, not the hidden payload. No text scanner can read what it cannot decode. undecodable ciphertext
Images crafted with adversarial perturbations to make OCR fail, text a human or vision model could read, but that produces no transcript to match against. Active research area. OCR-evading images
Payloads in ultrasonic or sub-audible frequency bands Whisper never transcribes leave no detectable text. Not seen in the wild, a theoretical gap we name honestly. frequency-domain audio
Harm that unfolds across many individually clean interactions, no single message carrying a pattern. Sunglasses scans inputs, not behavior over time. Pair with behavioral monitoring. cross-session behavior
The honest version, including the three qualifiers you still need before relying on it.
Through v0.2.63 the filter flagged 86 false positives on real code, including its own README and Python standard-library files. In v0.2.64 we root-caused the leaky detection keywords and over-broad anchoring; the same corpus now scans clean.
That zero isn't a one-time screenshot. Every release must produce zero blocking findings on a clean-code corpus of real samples (including full Python standard-library files) before it ships. The gate runs in the test suite on every version.
Zero on our corpus doesn't promise zero on your input distribution. If your agent processes content with imperative or security language, you can still see false positives. Test on a representative sample before production.
Critical/high return block; medium returns quarantine; low returns allow_redacted. A false positive on a benign prompt typically returns quarantine: human review, not automatic rejection.
With a human-in-the-loop review process, a false positive costs review time. In a fully automated pipeline with no review step, a quarantined legitimate request has immediate user-facing impact. Design your integration with the review workflow in mind.
The number is real and documented. Here's exactly what it proves, and what it does not.
Sunglasses detected every attack in the 64-sample adversarial corpus published with CVP Run 1. That is 100% internal recall, with a per-prompt verdict documented for all 64.
The 64 samples were constructed or sourced by the team for testing, the same class of known patterns the engine was built to catch. Not an independent third-party red-team with novel attack generation.
64/64 means 100% recall against those 64 specific samples, not against all possible attacks. Novel patterns the team hasn't seen are not in this measurement.
Measuring it requires widespread production deployment with ground-truth labels on attack traffic: data we don't yet have.
Six runs, four Claude model families, 120 transcripts, all clean. Still an internal evaluation, not a deployment-scale recall measurement. Read the full CVP Family Synthesis.
64/64 internal recall tells you the engine works against known patterns. It does not tell you what it will do against attacks it has never seen. Those attacks exist and will bypass us until we learn them. Report bypasses at GitHub Issues: they become patterns. For the harder number — precision and recall on a labeled dataset you can rerun yourself, including the miss we publish on purpose — see the reproducible benchmark.
Pair Sunglasses (ingestion-time, pre-model) with runtime monitoring, access controls, tool permission scoping, human review for high-risk actions, and incident response. When it catches something, trust the signal. When something falls outside its scope, have other controls in place.
No. 1115 patterns in 78 categories is substantial coverage of known attack families, but it is not exhaustive. Novel attacks, semantic-only attacks, and attacks outside the input layer are not covered. No ingestion filter should claim to catch everything. The question is whether the coverage matches your actual threat model.
It returns allow, the same as a legitimate clean input. You cannot distinguish a false-negative from a true allow at the Sunglasses layer alone, which is why runtime monitoring and behavioral analysis are necessary complements. Reported bypasses become new patterns; the database grows daily. Report at GitHub Issues.
Sunglasses cannot help here. An authorized user issuing harmful instructions through normal, non-injected prompts is technically indistinguishable from normal authorized use at the ingestion layer. Insider threat requires access controls, audit logging, least-privilege scoping, and behavioral monitoring, controls that operate on identity and behavior, not input content.
No. Sunglasses is one layer. A reasonable stack includes: Sunglasses as an ingestion-time filter (pre-model), runtime monitoring and behavioral analysis (post-model), access controls and tool permission scoping, human review gates for high-risk actions, and incident response procedures. See Guardrails Are Not Enough.
No. The CVP evaluation (six runs, four Claude model families, 120 transcripts) documents detection consistency across models and effort tiers against an internal adversarial corpus. It does not constitute a production-scale recall measurement. Real-world recall against novel attacks in live deployment is unknown. Methodology and per-prompt verdicts are published in full at sunglasses.dev/reports.
It depends on your input distribution and review workflow. Most false positives land on quarantine rather than block, human review, not automatic rejection. With a human-in-the-loop process, the cost is review time. Fully automated with no review step, a quarantined legitimate request has user-facing impact. The enforced gate is zero false positives on our clean-code corpus; your actual rate depends on how your legitimate inputs compare. Test on a representative sample first.