How to Threat Model an AI Agent With Tool Access

Classical threat-modelling frameworks were built for systems with assumptions that no longer hold for agentic AI. STRIDE assumes the system is reactive — a request comes in, processing happens, a response goes out. PASTA assumes the attacker can model the system’s behaviour deterministically given its inputs. The DREAD scoring assumes the asset boundary is stable enough that the impact of a compromise is calculable. All three frameworks remain useful for the services agents call. None of them, applied directly to the agent itself, captures the threats that actually matter. After working through this evaluation across many threat modelling exercises for agentic systems in 2025 and 2026, a consistent gap appears: teams that apply STRIDE to an agent produce a threat model that looks complete and is materially incomplete. The threats that produce real incidents are not in the STRIDE categories. This article presents an adapted threat-modelling pattern designed for the way agents actually fail, with a worked example and an operational handoff to detection and response.

The framework presented here does not replace STRIDE or PASTA. It extends them. The classical frameworks still apply to the tools the agent calls and the services it interacts with. The extension covers the agent itself — the reasoning loop, the memory state, the tool composition, and the data trust model — surfaces that classical threat models do not see.

Why classical frameworks miss the threats that matter

The first thing to acknowledge: STRIDE applied to an agent does produce findings. Spoofing the agent’s credentials is a real risk; tampering with the agent’s prompts is a real risk; information disclosure via the agent’s output is a real risk. None of those is wrong. The issue is that STRIDE-driven threat models for agents are dominated by the threats that look familiar, and the threats that are agent-specific get added as ad-hoc supplements at the end of the exercise — or get missed entirely.

Three categories of threat are systematically under-covered by classical frameworks:

Indirect prompt injection via data sources. The agent reads data from sources the operator does not fully control. Content in those sources may contain instructions intended to redirect the agent’s behaviour. This is not spoofing (no credential is forged), not tampering (no protected data is modified), not information disclosure as the primary effect (data leaks are a consequence, not the cause), and not denial of service. It does not map cleanly to any STRIDE category. Yet it is the most common attack class against agentic systems in production.

Capability composition. The agent has access to multiple tools. Each tool’s authorisation is sound. The composition of the tools — the sequences of calls the agent can make — produces effects the operator did not authorise. The classical frameworks assess each interface independently; the composition problem is not visible at the individual interface level. The threat model needs to look at the graph of tool capabilities the agent can invoke and assess what action sequences are reachable.

Memory state evolution. The agent’s effective behaviour depends not just on its credentials and its current input but also on its persistent memory state. The memory state evolves across sessions in ways the threat model snapshot does not capture. A threat that requires three sessions to set up — plant content in session one, wait for the memory to consolidate it, exploit it in session three — is invisible to a static threat model.

The adapted framework below handles these explicitly.

The agent threat surface — five dimensions

For any agent, the threat surface decomposes into five dimensions. Each dimension has its own attack patterns and its own controls. The threat model walks through each dimension explicitly and documents the threats and mitigations for each.

Dimension 1: Identity context. Whose authorisation is the agent acting under for the current action? Is it the operator’s, the requesting user’s, a system identity, or a delegated identity? What authentication and authorisation controls bind the agent’s actions to that identity? Threats in this dimension include credential exfiltration, identity confusion, and privilege escalation via context substitution.

Dimension 2: Data sources. What data does the agent read as part of its working context? For each data source, who controls the content? What is the integrity model? What is the freshness assumption? Threats in this dimension include indirect prompt injection, content tampering at the source, and stale data leading to wrong-state actions.

Dimension 3: Tool capabilities. What tools can the agent invoke? For each tool, what is its authorisation scope, what is its blast radius if misused, and what is the policy that decides when the agent may invoke it? Threats in this dimension include single-tool authorisation bypass, tool argument manipulation, and tool-result tampering.

Dimension 4: Tool composition. What sequences of tool calls are possible within an agent session, and what effects do those sequences produce? Threats in this dimension are the composition attacks — read-then-exfiltrate, lookup-then-leak, modify-then-revert — that are invisible at the single-tool level.

Dimension 5: Memory and observability. What memory state does the agent maintain across sessions? How is the memory inspected, audited, and reset? What runtime visibility does the operator have into the agent’s reasoning and actions? Threats in this dimension include memory poisoning, observability gaps, and post-incident reconstruction failures.

For each dimension, the threat model produces a table: threat description, attack vector, current control, residual risk, and mitigation priority. The product is operational, not theoretical — the rows feed directly into detection rules, audit checks, and code review items.

STRIDE-AT — STRIDE adapted for agent threats

For teams that prefer to extend an existing framework rather than introduce a new one, STRIDE can be adapted by adding two categories: Adversarial input via data and Tool composition abuse. The eight-category framework — STRIDE-AT — covers the standard six classical categories plus the two agent-specific ones.

A team familiar with STRIDE adopts STRIDE-AT with minimal training overhead. The two new categories are simply additional rows to evaluate during the threat-modelling exercise.

Specific threats per tool type

Different tool capabilities expose different threats. The threat model should evaluate each tool the agent has access to against the patterns the tool type historically produces.

Filesystem read. Threats: reading sensitive files the operator did not expect (configuration with credentials, customer data files, SSH keys). Composition risk: reading sensitive files and writing the contents to outbound HTTP. Common control gaps: filesystem access scoped too broadly, no allow-list of readable paths, no detection on outbound transfer of file contents.

Shell execute. Threats: running arbitrary commands at the agent’s privilege level. Composition risk: combining shell execute with outbound network access produces full data exfiltration capability. Common control gaps: shell access granted with no command allow-list, no logging of executed commands, no detection on suspicious command patterns.

HTTP request (outbound). Threats: data exfiltration to attacker-controlled endpoints, SSRF against internal services. Composition risk: any combination with read access becomes exfiltration. Common control gaps: outbound HTTP allowed to arbitrary domains, no DNS filtering, no detection on rate or volume of outbound calls.

Database query. Threats: unauthorised read of data the requesting user is not entitled to. Composition risk: query data and write it to HTTP or filesystem. Common control gaps: query layer does not enforce per-user authorisation, parameterised queries used inconsistently, no audit of query patterns.

Email send. Threats: phishing emails sent from a trusted internal sender, account-takeover via password reset abuse. Composition risk: lookup account details, then send to an attacker-supplied address. Common control gaps: send-from address can be set by the agent, recipient address not validated against the account holder.

Code commit. Threats: malicious code introduced into production, secrets committed to public repositories, dependency manipulation. Composition risk: read sensitive code, then push to a public fork. Common control gaps: no human review required for code commits, no separation between agent-generated changes and human-generated changes in the review tooling.

The threat model walks each enabled tool and selects the relevant rows. The result is a tool-specific risk profile, not a generic agent risk profile. For each high-risk tool, a targeted penetration test of the call boundary validates that the policy controls hold under adversarial input.

Worked example — customer support agent with database read

To make the framework concrete, consider a representative agent: a customer support agent with read access to a customer database, the ability to send password reset emails, and the ability to update support ticket status. It runs against a per-user authentication context where the user submitting the support request is identified to the agent at session start. The agent reads support tickets (user-submitted content) and account-status records (internal data) as part of its working context.

Identity context. The agent acts under a service identity but proxies a specific user’s authorisation. Threat: identity confusion where the agent applies one user’s request against another user’s data. Control: every database query and email send must include the requesting user’s identifier; the database query layer must verify that the identifier matches the row being accessed; the email send must verify that the destination matches the account-holder’s verified email.

Data sources. Support ticket bodies are user-submitted content. Threat: indirect prompt injection via ticket text. Control: ticket text is wrapped in a content-only marker the agent’s policy treats as non-authoritative; the agent’s tool-call decisions cannot be justified by ticket text alone; runtime detection alerts on tool-call sequences whose reasoning traces back to user-submitted content.

Tool capabilities. Three tools: database read, password reset send, ticket status update. Each tool’s authorisation is sound (per-user policy enforced at the tool layer). Threat: password reset send to an attacker-supplied address. Control: password reset destination is hardcoded to the account-holder’s verified email; the tool ignores any destination argument the agent supplies.

Tool composition. Reachable compositions: read account → send password reset. Threat: read-then-leak chain where the password reset email contains account data. Control: password reset emails contain a fixed template with no agent-supplied content; the template is rendered at the email layer, not by the agent.

Memory and observability. The agent maintains no persistent memory across sessions. Threat: memory injection via attacker-planted ticket content. Control: not applicable for this agent because memory persistence is disabled. Audit: every tool call logged with session ID, user identifier, tool name, arguments, and result, retained for at least 90 days.

The threat-model output is a ten-row table — five dimensions, two or three threats per dimension, each with its current control and residual risk. The residual risk for this agent is low because each dimension has explicit controls. The threat model surfaced one finding: the support ticket body should not be passed to the LLM as content authoritative enough to influence tool selection. That finding maps to a specific code change, a specific audit query, and a specific detection rule.

Operational handoff to detection and response

The threat model’s outputs are not a document. They are inputs to detection, audit, and incident response. The handoff:

To detection engineering. Each threat with residual risk above the team’s threshold becomes a detection rule. Indirect prompt injection becomes a rule that fires when the agent’s tool-call arguments contain text that originated in a user-submitted source. Tool composition risks become rules that fire when specific action sequences appear in the audit log. Identity confusion becomes a rule that fires when the agent’s user context changes mid-session.

To audit. Each control in the threat model becomes an audit check. Quarterly verification that the controls are in place produces evidence for compliance reviews and for the team’s own confidence. Audit failures map back to threat-model rows for remediation prioritisation.

To incident response. The threat model documents the attack surface. When an incident fires, the responder uses the threat model to scope the blast radius. “Which tools could have been invoked? Which data could have been read? Which downstream systems are affected?” — the threat model has those answers ready.

The framework presented here is not exotic. It is the same operational threat-modelling discipline that has been working for web applications for a decade, adapted to the shape of an agent’s failure modes. The team that already does threat modelling well does not need to start over for agentic systems. They need to extend the framework to cover the dimensions classical frameworks miss. The extension is documented above, and it has been tested against agents in production. The handoff to runtime controls fits cleanly into an existing DevSecOps program — the threat-model rows become detection rules in the same pipeline that already runs for code and infrastructure.

The forcing function will eventually arrive in the form of an audit, an incident, or a compliance requirement. The teams that have already adapted their threat-modelling discipline are the teams whose response to the forcing function is “we have done this already”. The teams that have not adapted will discover the gap at the point of greatest expense — when the threat materialises and the documentation is not ready.