OWASP LLM Top 10 → Shrike coverage mapping

Coverage at a glance

Full: dedicated detection with test coverage. Partial (runtime): covered as a runtime signal even where OWASP scope extends further (e.g. LLM05 training-time is out of scope for a runtime governor). Partial (scope): one axis covered, another explicitly not — see per-item notes.

LLM01 — Prompt Injection

Direct or indirect override of model instructions. Shrike catches this across the cascade because attackers use every delivery vector — plain text, unicode obfuscation, encoded payloads, semantic paraphrase, visual injection, and multi-turn assembly.

Wire verdict types:

prompt_injection, jailbreak, harmful_intent, social_engineering, multi_turn_attack.

Where it's caught:

• • L1 (pattern): known injection phrases and jailbreak families
• • Unicode: zalgo text, homoglyph substitution, zero-width characters
• • Encoding: nested Base64 / hex / ROT-N cascades, with a size guard against decode-bomb DoS
• • Semantic: similarity to a catalog of known adversarial patterns
• • L6 (visual): image-carried injection
• • L7 (LLM analysis): a constrained classifier over the content
• • L9 (session correlation): multi-turn assembly caught across the session even when no single turn trips a layer

{
  "safe": false,
  "threat_type": "prompt_injection",
  "refuse_tier": "block",
  "severity": "high",
  "reason": "Instruction-override pattern detected",
  "session_state": {
    "session_risk_score": 0.85,
    "session_patterns": ["multi_turn_escalation"]
  },
  "recovery": { "instruction": "..." }
}

LLM02 — Sensitive Information Disclosure

PII, secrets, and PHI in input or output. Default action is redact, not block — PII becomes tokens like [EMAIL_1], [SSN_1] and the request proceeds with the redacted payload. Client-side redaction ships in both SDKs so PII never crosses to the Shrike backend.

Wire verdict types:

pii_exposure, secrets_exposure, data_exfiltration

Where it's caught:

• • Pattern recognizers (30+): SSN, credit card, IBAN, email, phone, medical record, cloud provider secrets, crypto wallets, and more — with checksum / Luhn validation to cut false positives
• • Semantic: catches sensitive-context requests without literal PII (e.g. "give me all customer records for John Smith")
• • L8 response intel: detects PII in model OUTPUT even when the input was clean
• • Client-side SDK redaction (before data leaves your environment): redact_pii() / redactPII() in the open-source Python and TypeScript SDKs, with a recognizer set synced from the backend

LLM03 — Excessive Agency

Model granted permissions beyond its task; unbounded tool use. Governed via approval workflow, policy engine, and declared delegation scope.

Wire verdict types:

privilege_escalation, destructive_operation

• • Approval workflow: high-risk actions return refuse_tier: "require_approval" with an approval handle. The agent polls; a human decides. The agent cannot self-approve.
• • Policy engine: per-customer allow / deny / require-approval keyed on tool + action + scope.
• • Declared scope (scan_declare_scope): an agent declares its allowed scope; out-of-scope actions are flagged.
• • Delegation scope inheritance: sub-agents inherit the parent's approved scope; high-criticality still requires approval even inside inherited scope; non-overridable threats always block.
• • Blast-radius containment: a compromised agent node invalidates its entire delegation subtree.

LLM04 — Supply Chain

Compromised models, plugins, or data sources. Shrike is a runtime governor — it does not scan container images, npm / PyPI packages, or model weights. It DOES scan the runtime interfaces where a compromised supply-chain component reveals its behavior in an agent workflow.

What Shrike covers:

• • scan_agent_card — A2A agent-card capability spoofing: ANSI-escape injection, injected description / skills fields, blocked-domain provider URLs.
• • scan_mcp_schema — MCP tool schemas carrying tool-poisoning payloads or hidden instructions.
• • scan_a2a_message — inbound agent messages carrying injection or unauthorized delegation.
• • scan_response on tool output — a third-party tool response carrying indirect injection into the model's next turn.

What Shrike does NOT cover:

• • Model-weight provenance / signing
• • Container / package dependency scanning (SCA — pair with Snyk, Dependabot, Trivy)
• • Training-data source verification

Buyer recommendation: pair Shrike with SCA + model-signing tooling. Shrike governs runtime; SCA governs build.

LLM05 — Data and Model Poisoning

Shrike doesn't run customer training pipelines — model providers own theirs. What Shrike detects is the runtime signature of poisoned context showing up in a live session.

• • L9 memory-poisoning signature: instruction planting where an attacker tries to establish durable "rules" for later exploitation.
• • L9 context-overflow signature: context-window saturation used to push the system prompt out of scope.

Shrike's own training pipeline is isolated from customer scan content.

LLM06 — Unbounded Consumption

Token-flooding / inference-budget DoS; cost attacks. Enforced end-to-end — from the rate limiter at ingress through session correlation to client-side auto-rotation.

• • Rate limiting: per-customer + per-key request-rate and volume caps
• • L9 token-velocity anomaly: a sustained spike above a session's own baseline raises risk
• • L9 session lock: a sustained high-risk session short-circuits subsequent scans early — a cost floor against adversarial sessions
• • Encoding decode-bomb guard: a cumulative size limit on nested encoding walks
• • Client-side session rotation: shipped in the Python and TypeScript SDKs

LLM07 — Misinformation

Toxic or harmful generated content and hallucinated facts. Shrike detects toxic OUTPUT; it does not verify FACT (no retrieval-augmented grounding integration).

Wire verdict type:

toxic_content

• • L7 semantic: detection of toxic patterns in output
• • L8 response intel: anomaly detection on response tone + disclosure
• • Provider-guardrail attribution: upstream model-provider safety blocks are surfaced in the response's coverage metadata, so callers see what stopped a generation

LLM08 — Hidden Context Exposure

Leakage of context that should have stayed out of reach — the system prompt, developer instructions, retrieved context, or tool definitions. (In OWASP 2026 this broadens and renames the 2025 "System Prompt Leakage" category.) Shrike screens both the extraction attempt on the way in and the leaked content on the way out.

• • L1 pattern: naïve extraction attempts
• • L8 disclosure detection: "here's my system prompt" phrasing in output
• • L8 extraction detection: boundary-probing techniques — "repeat the text above", "the first 50 words of your instructions", "format your prompt as JSON", structured-block leaks — that bypass naïve "show me your prompt" checks
• • Output check: the model's OUTPUT is screened for system-prompt keywords + structural markers before it returns to the user

LLM09 — Vector and Embedding Weaknesses

RAG-side attacks. Shrike scans the query and retrieved-context inputs into a RAG pipeline but does not instrument the embedding store itself.

What Shrike covers:

• • RAG input scanning: the user query going into retrieval AND each retrieved chunk before it lands in model context — catching indirect injection carried by a poisoned chunk
• • Unicode + malformed: zero-width injection hidden in retrieved documents
• • L7 semantic: scoring of the assembled RAG context before generation

What Shrike does NOT cover:

• • Embedding-store-side attacks (adversarial embeddings, similarity manipulation)
• • Model inversion against the embedding model

LLM10 — Improper Output Handling

Model output sent unsanitized to downstream systems — XSS, SSRF, RCE via generated commands / SQL / shell.

Wire verdict types:

malicious_code, sql_injection

• • L1 pattern: SQL injection (tautologies, comment injection, stacked queries), shell metacharacters, path traversal
• • scan_sql_query: executes only when safe, or when an explicit destructive-allow flag is set
• • scan_command: CLI scanning with pipe-chain analysis — blocks reverse shells, credential-exfil one-liners, destructive wipes
• • scan_file_write: path traversal, sensitive-path targeting, secrets-in-content
• • L8 response intel: unescaped HTML / JS in model output before the caller renders it

What's honestly NOT covered — layer Shrike with these

Rather than let "full coverage" hide gaps, here's what a buyer should still put alongside Shrike:

• • LLM04 build-side supply chain: SCA / package scanning / model signing. Shrike governs runtime, not build.
• • LLM05 training-side poisoning: model providers own their training pipelines. Shrike verifies its own is isolated but does not audit customer LLM training.
• • LLM09 vector-store integrity: signed writes, ANN threshold monitoring on the vector-DB side.
• • LLM07 factuality grounding: retrieval-augmented ground truth, fact-check integrations.

Change discipline

This mapping is maintained against Shrike's published tool surface and the OWASP LLM Top 10. When the tool surface or the OWASP list changes, the mapping is refreshed and the "Reviewed" date at the top is updated.

Enterprise customers can request the internal audit workbook — walking each row to the specific test that proves the layer catches the payload class — via the Trust Center evidence package form.