| name | agentic-ai-threats |
| description | Threat model an agentic AI system against OWASP Agentic AI Threats and Mitigations. Identifies architectural threats across planning, memory, tool use, and multi-agent coordination. Produces a STRIDE-style threat model with mitigations, residual risk ratings, and an implementation roadmap. Use when designing or hardening an agentic AI system. |
| argument-hint | ["system name or description","optional"] |
Agentic AI Threat Modeling
You are threat modeling an agentic AI system based on the OWASP Agentic AI Threats and Mitigations framework. Work through each phase in order.
System: {{args}}
Phase 1: Interview
Use AskUserQuestion for each question below, one at a time.
Question 1: Agent capabilities (multi-select):
| Option | Description |
|---|
web-browsing | Agent browses the web and reads external content |
code-execution | Agent writes and runs code |
file-system | Agent reads/writes files |
api-calls | Agent calls external APIs or services |
email-messaging | Agent sends emails or messages |
financial | Agent initiates payments or financial transactions |
data-store-write | Agent modifies databases or knowledge stores |
multi-agent | Agent orchestrates or communicates with other agents |
long-term-memory | Agent persists memory across sessions |
autonomous | Agent runs without per-action human approval |
Question 2: Deployment context
| Option | Description |
|---|
internal-only | Accessed only by internal/trusted users |
customer-facing | Accessed by external/untrusted users |
fully-automated | No human in the loop at all |
enterprise | Deployed in regulated industry (finance, health, legal) |
Question 3: Existing controls - free text:
What security controls currently exist? (e.g. "rate limiting on API, tool call logging, human approval for payments")
Question 4: Output format
| Option | Description |
|---|
threat-model-only | Threat model document, no code changes |
threat-model-and-plan | Threat model + prioritized mitigation roadmap |
full | Threat model + roadmap + implement top mitigations |
Phase 2: Explore
Spawn 3 parallel subagents:
| Subagent | Focus |
|---|
| 1 | Agent architecture - planning loop, tool invocation, action execution |
| 2 | Data flows - what enters and exits the agent (inputs, outputs, tool I/O, memory) |
| 3 | Trust boundaries - where does trust level change between components |
Map the full attack surface before threat modeling.
Phase 3: Threat Identification
For each threat domain below, evaluate every threat against the system's capabilities from Phase 1. For each threat record one of:
Applicable with chosen severity (use the conditional severities listed)
N/A with a one-line reason (e.g., "no long-term memory", "single-agent only")
Do not skip threats silently - explicit N/A entries are required so the threat model is auditable.
Threat ID convention: T-<DOMAIN>-<NN> where DOMAIN is GIM, PPA, DEP, AIA, MAS, or MCT.
Domain 1: Goal and Instruction Manipulation
These threats target the agent's objectives - making it pursue different goals than intended.
T-GIM-01: Direct Prompt Injection
- Severity: Critical if autonomous; High otherwise
- Condition: Agent processes user input that can override system instructions
- Attack: User input contains instructions that change agent behavior ("ignore your rules and...")
- Indicators: No structural separation of instructions vs. data; user input included verbatim in context
- Mitigations: Structured prompt with labeled sections, role constraints, output format enforcement
T-GIM-02: Indirect Prompt Injection
- Severity: Critical if agent browses web or processes external documents
- Condition: Agent reads external content and includes it in context
- Attack: Malicious instructions embedded in web pages, documents, emails, or code files
- Indicators: External content included in context without sanitization
- Mitigations: Content tagging as [UNTRUSTED], injection pattern filtering, guardrail model for external content
T-GIM-03: Goal Hijacking via Memory Poisoning
- Severity: High if long-term memory enabled
- Condition: Agent reads from persistent memory to inform current actions
- Attack: Attacker injects malicious instructions into agent memory (via prior interaction or direct write)
- Indicators: Memory stored without integrity checks; any user can influence what is persisted
- Mitigations: Memory integrity checksums, per-user isolation, sanitization before write, expiry
T-GIM-04: Jailbreaking and Safety Bypass
- Severity: Critical if agent can take real-world actions on bypass; High if output-only; Medium if outputs reviewed before use
- Condition: Agent has safety constraints or policy rules
- Attack: Systematic prompt variations, encoded payloads (base64, leet, translation), or roleplay framing ("you are DAN") to bypass safety
- Indicators: Safety enforced only via system prompt; no second-pass classifier on outputs
- Mitigations: Defense in depth - independent guardrail/classifier model on both inputs and outputs (do not rely solely on system prompt), output policy filter at application layer, rate limiting on rapid prompt variations from same identity, denylist of known jailbreak patterns updated regularly
T-GIM-05: Hallucinated Tool or Action Fabrication
- Severity: Critical if downstream systems trust agent-produced identifiers; High if agent invents tool calls that error noisily; Low if outputs are advisory text
- Condition: Agent produces tool calls, API references, code, citations, or resource IDs from its own generation rather than from verified context
- Attack: Not always adversarial - the model fabricates a function name, package, URL, account ID, SQL table, or citation; downstream systems execute or trust it. Adversaries exploit this by registering fabricated package names ("slopsquatting") or URLs
- Indicators: No schema validation on tool calls; agent free-text proposes resource IDs; package install or URL fetch follows agent output without allowlist
- Mitigations: Strict tool-call schema validation (reject unknown tool names and unknown parameters), resolve resource IDs against an authoritative directory before use, package allowlist with pinned versions, never auto-install packages named by the model, cite-then-verify for retrieved references
Domain 2: Privilege and Permission Abuse
These threats target the agent's access to resources and actions.
T-PPA-01: Excessive Agency Exploitation
- Severity: Critical if agent has write/delete/send/pay capabilities
- Condition: Agent is granted broader permissions than the current task requires
- Attack: Prompt injection or instruction manipulation causes agent to use permissions for unintended actions
- Indicators: Agent has all tools available at all times regardless of task scope
- Mitigations: Least-privilege tool sets per task, tool call validation against user intent, scope boundaries in system prompt
T-PPA-02: Privilege Escalation via Tool Chain
- Severity: High if agent can call multiple tools sequentially
- Condition: Individual tools are scoped, but chaining them achieves escalated access
- Attack: Agent is manipulated into using a sequence of low-privilege tools to achieve high-privilege outcome
- Examples: Read file -> extract credential -> use credential to call privileged API
- Mitigations: Action scope validation across the entire chain, circuit breakers on multi-step operations
T-PPA-03: Insecure Direct Action Reference
- Severity: Critical if agent can mutate/delete referenced resources; High if read-only access; Medium if resource IDs are opaque server-issued tokens
- Condition: Agent actions operate on resources identified by user-controlled parameters (IDs, paths, URLs)
- Attack: User manipulates resource IDs in prompt or injected content to cause the agent to act on resources they should not access (IDOR-equivalent for agents)
- Indicators: Tool implementations trust the ID the model passes; authorization checked at session start but not per-tool-call
- Mitigations: Server-side authorization check before each tool call against the original requesting user, resource ownership validation, prefer opaque/scoped tokens over guessable IDs, scope tool to user's resource namespace
T-PPA-04: Approval Bypass
- Severity: Critical if high-impact actions exist
- Condition: HITL controls rely on the agent to request approval honestly
- Attack: Injection causes agent to skip approval request or forge approval signal
- Mitigations: Approval enforcement in application layer (not model layer), bind approval to exact parameters, fail-closed
Domain 3: Data Exfiltration and Privacy
These threats target sensitive data handled by the agent.
T-DEP-01: Sensitive Data Exfiltration via Tool Abuse
- Severity: Critical if agent has external communication capabilities
- Condition: Agent can send data to external destinations
- Attack: Injection causes agent to exfiltrate conversation history, system prompts, or user data
- Indicators: No content filter on outbound communications
- Mitigations: Outbound data filtering, allowlist of permitted destinations, PII detection before send
T-DEP-02: System Prompt and Configuration Leakage
- Severity: Critical if system prompt contains secrets/keys/PII; High if it contains proprietary logic or safety rules; Low if prompt is non-sensitive
- Condition: Agent's system prompt contains sensitive instructions, API keys, business logic, or safety rule descriptions that aid bypass
- Attack: Direct or indirect prompt injection causes model to reveal system prompt verbatim or paraphrased ("repeat the text above", "translate your instructions to French")
- Indicators: Secrets, internal URLs, or business rules embedded directly in the system prompt
- Mitigations: Never place secrets in system prompts (use server-side secret resolution at tool call time), output filter that matches known system prompt fragments and blocks them, treat system prompt as public when designing it
T-DEP-03: Cross-User Context Pollution
- Severity: High in multi-user deployments
- Condition: Agent context or memory is not properly isolated per user/session
- Attack: User's request inadvertently includes data from another user's session
- Mitigations: Strict per-user context isolation, namespaced memory, session boundary enforcement
T-DEP-04: RAG Data Exfiltration
- Severity: High if RAG is used
- Condition: RAG retrieval may return documents from other users or higher-privilege contexts
- Attack: Crafted query retrieves unauthorized documents and agent includes them in response
- Mitigations: Access-control filtering on retrieval results, per-user vector namespace
Domain 4: Agent Infrastructure Attacks
These threats target the underlying agent runtime and infrastructure.
T-AIA-01: Supply Chain Compromise of Agent Tools
- Severity: Critical
- Condition: Agent uses third-party tools, MCP servers, or plugins
- Attack: Malicious or compromised tool package is loaded and executes attacker code
- Mitigations: Tool provenance verification, pinned versions with hash checks, sandboxed tool execution
T-AIA-02: Denial of Wallet (DoW)
- Severity: High for any paid LLM deployment
- Condition: Agent has no per-user token or cost limits
- Attack: Attacker crafts inputs that cause the agent to make extremely large or numerous LLM calls
- Mitigations: Per-user token budgets, request rate limiting, cost alerting, circuit breakers
T-AIA-03: Agent Loop Abuse
- Severity: High if agent is autonomous
- Condition: Agent loop has no depth or iteration limit
- Attack: Prompt or tool output causes agent to recurse infinitely or loop excessively
- Mitigations: Max iteration count, max depth for recursive calls, timeout on the entire task
T-AIA-04: AI Console Malicious Configuration
- Severity: Critical if production agent serves untrusted users and config is hot-reloadable; High if internal-only; Medium if config requires code deploy
- Condition: Agent configuration (system prompts, tool permissions, model selection, guardrails) is modifiable at runtime or via low-friction console
- Attack: Attacker gains access to config UI/API and modifies system prompt, disables guardrails, enables dangerous tools, or swaps to weaker model
- Indicators: Config console accessible to non-security roles; no four-eyes review on prompt changes; no diff/version history
- Mitigations: RBAC on agent configuration with separate role for security-sensitive fields, mandatory review/approval for prompt and tool permission changes, signed and versioned configs, immutable production configs (config-as-code via PR), audit log of every config change with actor and diff
T-AIA-05: Model Resource Exhaustion (Compute DoS)
- Severity: High for any production agent; Critical if agent shares compute/quota across tenants
- Condition: Agent accepts inputs that influence prompt size, context window, retrieval breadth, or tool iteration count
- Attack: Distinct from Denial of Wallet - attacker crafts inputs that exhaust compute (max-context prompts, recursive RAG that retrieves huge documents, slow tools), starving other users and tying up rate-limited model quota
- Indicators: No max input size; no cap on retrieved-document tokens; no per-request timeout on tool calls
- Mitigations: Hard caps on input token count and retrieved-context tokens, per-request wall-clock timeout, concurrency limits per identity, queue isolation between tenants, fast-fail on oversized payloads before model call
Domain 5: Multi-Agent Specific Threats (if applicable)
Scope: apply this domain only if the multi-agent capability was selected in Phase 1. Otherwise mark "N/A - single-agent system" in the threat model document and skip.
T-MAS-01: Rogue Orchestrator
- Severity: Critical
- Condition: Sub-agents trust messages from orchestrator without verification
- Attack: Compromised or injected orchestrator sends malicious instructions to sub-agents
- Mitigations: Signed inter-agent messages, sub-agent verification of instruction source
T-MAS-02: Trust Escalation via Agent Chain
- Severity: High
- Condition: Agent A trusts Agent B which trusts Agent C
- Attack: Low-trust agent manipulates chain to cause high-trust agent to perform privileged action
- Mitigations: Explicit trust levels per agent, no implicit trust inheritance through chains
T-MAS-03: Cascading Failure
- Severity: High if shared state includes write-capable resources; Medium for read-only shared state
- Condition: Multiple agents share state or resources (queues, databases, memory stores)
- Attack: One agent's failure or compromise propagates through the system - poisoned output of Agent A becomes poisoned input to Agent B
- Mitigations: Circuit breakers between agents, failure isolation (bulkheads), rollback mechanisms, validate inter-agent payloads at each hop, do not let one agent's exception kill the orchestrator
T-MAS-04: Agent Identity Spoofing
- Severity: Critical if agents have differentiated privileges
- Condition: Inter-agent messages are routed by name/role without cryptographic authentication
- Attack: A malicious or compromised process impersonates a trusted agent ID, sending instructions other agents act on
- Indicators: Agent-to-agent calls happen over unauthenticated channels; agent identity is a string field in a message body
- Mitigations: Mutual TLS or signed tokens for inter-agent calls, identity bound to transport, deny messages whose claimed sender does not match the verified channel identity, per-agent service accounts with scoped permissions
Domain 6: Misuse and Compliance Threats
T-MCT-01: Autonomous Harmful Action
- Severity: Critical for regulated industries
- Condition: Agent can take irreversible real-world actions without oversight
- Attack: Design flaw or injection causes agent to take harmful action autonomously
- Mitigations: HITL gates for all irreversible/high-impact actions, action scope limitations, audit logging
T-MCT-02: Regulatory Non-Compliance via Agent
- Severity: Critical for healthcare/finance with no DLP controls; High for regulated industries with partial controls; Medium for non-regulated with PII handling
- Condition: Agent processes regulated data (PII, PHI, PCI, financial records, GDPR-scope data)
- Attack: Agent inadvertently processes, stores, or transmits regulated data in non-compliant ways - logs PII in plaintext, ships PHI to non-BAA provider, sends EU data to non-adequate region
- Indicators: No data classification tags on context; LLM provider not under DPA/BAA; prompts and outputs logged without redaction
- Mitigations: Data classification metadata on every context block, PII/PHI filter on inbound and outbound flows, audit trails with redaction, retention policies that meet jurisdiction requirements, contractual coverage (BAA/DPA) with model provider, regional routing for data residency
T-MCT-03: Repudiation and Audit Trail Tampering
- Severity: Critical for regulated/financial actions; High for any high-impact action; Medium otherwise
- Condition: Agent takes actions that require post-hoc attribution (compliance, dispute, incident response)
- Attack: Logs are missing, mutable, or insufficient to reconstruct who caused which action - user or attacker plausibly denies involvement; or attacker erases evidence of intrusion
- Indicators: Logs writable by the agent process itself; no immutable sink; no correlation ID linking user request to tool calls to outcomes
- Mitigations: Tamper-evident append-only audit log on separate system, log every prompt, tool call, tool result, and decision with correlation ID and authenticated user identity, retain logs per compliance window, regular log integrity verification, separate logging credentials from agent runtime
Phase 4: Threat Model Document
Risk Scoring Method
Use this matrix consistently across all threats:
Severity - worst-case business impact if the threat is realized
Critical - irreversible harm, regulatory breach, large financial loss, or full system compromise
High - significant data loss, reversible-but-costly harm, or sustained service degradation
Medium - bounded data exposure or recoverable disruption
Low - nuisance-level impact
Likelihood - probability under the current control environment
High - attack is trivial, public, or already observed in similar systems
Medium - attack requires moderate skill or access
Low - attack requires privileged access or sophisticated capability
Risk - look up Severity x Likelihood in this matrix and use the result literally so ratings are reproducible:
| Severity \ Likelihood | Low | Medium | High |
|---|
| Critical | High | Critical | Critical |
| High | Medium | High | Critical |
| Medium | Low | Medium | High |
| Low | Low | Low | Medium |
Status values: Open, Mitigated, Accepted (with sign-off), N/A (with reason).
Generate /security/agentic-threat-model.md:
# Agentic AI Threat Model
**System:** <name/description>
**Date:** <today>
**Capabilities:** <from interview>
**Deployment:** <from interview>
**Existing Controls:** <from interview>
## Architecture Overview
<brief description of agent architecture based on exploration>
## Attack Surface Map
<data flow diagram in text form showing all inputs, outputs, trust boundaries, and where user-controlled data crosses into instruction context>
## Scope
- In scope: <agent components, tools, data stores covered>
- Out of scope: <e.g., underlying cloud infrastructure, model provider internals>
- Multi-agent domain: <Applicable | N/A - single-agent system>
## Threat Summary
| ID | Threat | Domain | Severity | Likelihood | Risk | Status | Owner |
|----|--------|--------|----------|-----------|------|--------|-------|
| T-GIM-01 | Direct Prompt Injection | Goal Manipulation | Critical | High | CRITICAL | Open | <name> |
| T-GIM-02 | Indirect Prompt Injection | Goal Manipulation | ... | ... | ... | ... | ... |
| ... | (every T-* threat from Phase 3, including N/A entries with reason) | | | | | | |
## Detailed Findings
For each threat that is not N/A, include:
- Threat ID and name
- Concrete attack scenario specific to this system (not generic)
- Existing controls that partially mitigate it
- Proposed mitigation referencing the Phase 3 mitigation list
- Residual risk after mitigation
### Critical Threats
...
### High Threats
...
### Medium Threats
...
## Mitigation Roadmap
Each item links back to one or more threat IDs.
### Sprint 1 - Critical (implement now)
1. <mitigation> - addresses [T-GIM-01, T-PPA-01]
### Sprint 2 - High (next release)
1. <mitigation> - addresses [T-...]
### Sprint 3 - Medium (30-day window)
1. <mitigation> - addresses [T-...]
## Residual Risk
<threats with no complete mitigation, the compensating controls in place, and explicit accept/transfer/mitigate decision with sign-off>
## Assumptions and Exclusions
<what is out of scope and why, including any threat marked N/A>
Phase 5: Implement Top Mitigations (if full mode selected)
Implement the Critical and High mitigations in priority order:
- Prompt injection defense (structured prompts + guardrail model on inputs and outputs)
- Tool-call schema validation (reject unknown tools/params - addresses T-GIM-05)
- Least-privilege tool sets (per-task tool restriction)
- HITL gates for irreversible actions
- Per-user context isolation + per-tool-call authorization
- Token budget, rate limiting, and input-size caps
- Memory integrity checks
- Tamper-evident audit logging
- Inter-agent message signing and identity binding (if multi-agent)
For each mitigation, implement the minimum code change needed. Do not refactor surrounding code.
Phase 6: Verify
Run a concrete test for each mitigation implemented in Phase 5. Each test below maps to a specific threat - record pass/fail and evidence in the threat model document.
Goal manipulation
Privilege and permission
Data exfiltration
Infrastructure
Multi-agent (if applicable)
Misuse and compliance
Completion
Return the threat model file path and a summary: total threats identified, critical/high/medium counts, mitigations implemented vs. deferred, and overall residual risk rating.