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.
Passed with the findings attached. Nothing is 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? [email protected], 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 variants in 13 languages with dedicated patterns, since attackers can 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. 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.22. 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
Multilingual coverage sits in the prompt injection, exfiltration, unicode evasion and code switching rules, where payload translation is a documented evasion. 13 languages have two dedicated patterns each. Additional languages appear in shared keyword and regex rules. 13 languages with dedicated patterns
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: that is the fundamental limit of any signature system. Patterns are added in releases; see the CHANGELOG for release notes. 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
Harmful, un injected admin prompts look like legitimate use at the ingestion layer. The Claude Code hook can still refuse a tool call that breaks a path or host policy you set, or that sends a known credential format out, whoever asked. Neither check is misuse detection. 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. Encodings such as base64 are decoded and scanned; ciphertext is not. 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
A key in a known format (AWS, GitHub, OpenAI, Anthropic, a private key) inside an MCP tool result is caught when that server runs behind the Sunglasses proxy (Beta, once approved). The Claude Code hook checks a tool call before it runs, so it never sees what a tool returns. secrets in tool results
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
eight -API siblings scan secrets on the api_response channel, which the MCP proxy (Beta, once approved) uses for tool results. sunglasses scan --channel tool_output does not run them; use --channel api_response for a tool result.
Rule GLS-SD-010, on canonical message, file and code channels (including applicable aliases) only: a secret with no known format matches as one of nine exact names at line start. DB_PASSWORD=, export PASSWORD=, an indented line or a JSON value is missed by this rule.
When the value is in a known credential format the secret-detection rules still catch it in files and messages, so what is uncovered is an assignment whose value has no recognisable shape — a password, a connection string, an internal token — once it is embedded.
GLS-SD-001 in files, messages and log memory, GLS-SD-001-API on the api_response channel
needs a different anchor, which is a new rule rather than a channel added to this one.
A review can test the routes of one agreed workflow. Sunglasses Assess is a paid review of one named workflow, up to three agreed routes. With your written permission, it runs agreed benign and hostile synthetic controls on the named routes. It also marks each route MEDIATED, DIRECT or UNVERIFIABLE, so you see which tool results pass through a check at all. The scope sheet defines exclusions. Assess is not a penetration test or a certification and makes no claim about all agent inputs. Pricing
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 scanned clean in that release.
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 reproducible. Here's exactly what it proves and what it does not.
Sunglasses caught 37 of the 38 attacks in the benchmark that ships in the repo and missed one, which we publish on purpose. Precision on the same run is 86.1%. Anyone can rerun it with python3 tests/benchmark/precision_recall.py.
The 38 attacks and the 77 famous open source READMEs ship in the repo and were labeled by the team. Not an independent third party red team with novel attack generation.
37/38 means 97.4% recall against those 38 specific attacks, not against all possible attacks. Attacks 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.
37/38 benchmark recall tells you the engine works against the attacks in that dataset. 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. Rerun the numbers 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. 1584 patterns in 117 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. Novel attacks that use no known pattern can return allow until a pattern is added. To report a bypass, open an issue at github.com/sunglasses-dev/sunglasses/issues.
Sunglasses does not judge intent; the pre-call hook can still refuse recognized path, host and credential violations whoever runs the agent. 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. If you want agreed routes in your own workflow reviewed, Assess is a paid review of up to three of them, with receipts and a verifier command you can run yourself.
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.