OWASP Top 10 for Agentic Applications (2026) → Shrike coverage

Where Shrike sits

Shrike is the action-governance decision layer. Before an agent sends a prompt, returns a response, runs a command, issues a query, writes a file, or messages another agent, the enforcement point calls Shrike and receives one decision — allow / warn / require_approval / block — evaluated by a 9-layer cascade (L1–L9) that includes multi-turn session correlation.

It is designed to sit alongside your identity provider, your sandbox/network isolation, and your observability stack — not to replace them. Governance decides; observability reports; identity authenticates. Shrike is the part that says allow / block before the action happens.

Coverage at a glance

Primary control: Shrike is the enforcement point — it decides and blocks before the action executes. Detection + enforcement: Shrike detects the runtime signature and can block or gate, on one axis of a broader risk. Complementary: Shrike adds an action-layer control alongside a dedicated tool (identity, build-time). Direct enforcement on 6 of 10; a control at all 10.

ASI01 — Agent Goal Hijack

An attacker rewrites the agent's objective through injected instructions in a prompt, a fetched page, or a tool result. scan_prompt runs the L1–L7 cascade (pattern, unicode, encoding, semantic, and LLM analysis) on every inbound turn, and L9 correlates across the whole session — so a goal escalated gradually over several turns is caught even when no single message looks malicious.

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

ASI02 — Tool Misuse & Exploitation

The agent is coaxed into using a legitimate tool for harm. This is Shrike's core: each action type has a dedicated scanner and the decision is returned before execution, at the tool-call boundary where the developer's code enforces it.

• • scan_command — shell commands (reverse shells, credential harvesting, container escapes)
• • scan_sql_query — SQL injection and destructive queries
• • scan_file_write — path traversal and unsafe writes
• • scan_web_search — exfiltration disguised as a search

ASI03 — Agent Identity & Privilege Abuse

An agent acts beyond its intended authority. scan_declare_scope lets an agent declare its allowed scope up front; subsequent out-of-scope actions are flagged at the action layer.

Shrike does not replace an identity provider or a non-human-identity system — it enforces the behavioral boundary that sits on top of who the agent is. Pair Shrike with your IdP / NHI layer.

ASI04 — Agentic Supply Chain Compromise

Poisoned tools, skills, or agent cards carry hidden instructions the model will follow. scan_mcp_schema inspects MCP tool schemas for tool-poisoning and concealed directives; scan_agent_card validates A2A agent cards for capability spoofing and injected fields.

A live threat: public agent-skill registries have already seen coordinated typosquat-malware campaigns that smuggled reverse shells and credential exfiltration through poisoned skill metadata.

ASI05 — Unexpected Code Execution

The agent executes code or shell it should not. scan_command screens shell commands against reverse-shell, credential-harvesting, and container-escape patterns; scan_file_write catches path traversal and unsafe writes — each returned as an enforceable decision before the command runs.

ASI06 — Memory & Context Poisoning

Malicious content is planted so it resurfaces and steers a later decision. Shrike's L9 layer correlates within a session to detect slow-burn context poisoning — trust-building followed by exploitation — and reset_session clears correlation state at a task boundary; session_status reports live session risk read-only.

Cross-session persistent-memory integrity is governed by policy scope, not by within-session correlation alone.

ASI07 — Insecure Inter-Agent Communication

Agents delegate and exchange messages without validating each other. scan_a2a_message governs agent-to-agent traffic for injection and unauthorized delegation, and scan_agent_card validates the identity/capability cards agents present — before a delegated action is trusted.

ASI08 — Cascading Agent Failures

One failure propagates across a chain of delegating agents. Shrike's L9 layer tracks escalating session risk and blocks per-turn (and quarantines) once risk crosses threshold, halting the chain at the action layer.

Full delegation-graph blast-radius mapping is on the roadmap; today Shrike stops the actions that would carry a cascade forward, and propagates risk from a parent session to its children.

ASI09 — Human-Agent Trust Exploitation

The agent manipulates a human into approving or trusting something harmful. Shrike routes flagged actions to a human via the require_approval decision and check_approval (the agent cannot self-approve), and scan_response screens agent output for manipulative or data-leaking content before it reaches the user.

ASI10 — Rogue Agents

An authorized, trusted agent drifts from its intended behavior — the "insider" of agentic systems. This is Shrike's signature case: L9 session correlation plus drift detection (the agent rationalizing past failures) plus scope enforcement, backed by a hard block and session quarantine when risk is high.

What Shrike does NOT own — layer these alongside

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

• • Agent identity / non-human identity (ASI03): your IdP, NHI, and secrets management authenticate who the agent is. Shrike governs what it may do.
• • Build-time supply chain (ASI04): SCA, package scanning, and skill/model signing govern the build. Shrike scans the runtime interfaces (MCP schemas, agent cards) where compromise manifests.
• • Delegation-graph blast radius (ASI08): full multi-agent topology mapping is on the roadmap; Shrike halts the propagating actions today.
• • Sandbox / network isolation: tools like OpenShell decide whether the packet leaves. Shrike decides whether the action should have been taken.

Put it in the decision path

Every mapping above resolves to one call at the point the agent acts. Start free with the MCP server or the Python / TypeScript SDK, or read how the verdict contract works.