12. Threat Modeling AI Systems: STRIDE, PASTA, and MITRE ATLAS

---

🚨 Why Threat Modeling AI Systems Needs Ongoing Review

Adding agents, tools, or data sources changes system boundaries and risks. As a result, regular review helps teams update the threat model; implementation checks show whether listed controls operate in the changed system.

This matters especially in a multi-agent system. Agents call one another, tools have multiple callers, and LLM requests can include user-controlled context. Data stores may also feed both people and models. Because each new agent, tool, or data source can change the surfaces that need review, the model needs regular updates. In practice, STRIDE, PASTA, and ATLAS help organize that work, but code, configuration, and test evidence show whether the listed protections operate as intended.

Our review found mismatches in the ATLAS control descriptions and the endpoint scanner’s register path. Accordingly, the following sections show what those gaps mean and how to verify similar claims in your own system.

Back to top · Next: Three Lenses for Threat Modeling AI Systems

---

🧭 Three Lenses for Threat Modeling AI Systems

These methods help answer different questions about the same system. In practice, use them as complementary lenses, then bring their findings together in one register that records the threat, control, evidence, owner, and review status.

STRIDE prompts teams to consider Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege at each component or trust boundary. PASTA (Process for Attack Simulation and Threat Analysis) starts with business objectives, then prioritizes scenarios by their impact and residual risk. MITRE ATLAS provides an AI-focused technique taxonomy to map model and agent risks to controls, probes, and gaps.

Lens	Question it helps answer	Useful output	How to start
STRIDE	What could go wrong at each component or trust boundary?	Threats linked to surfaces, controls, residual risk, and evidence	Draw the data flows and trust boundaries; review each surface against all six categories.
PASTA	Which scenarios could harm the business, customers, or obligations most?	Business-linked scenarios with pre-control and residual risk scores	Write down the objectives and harms first; score the scenarios consistently and define escalation rules.
MITRE ATLAS	Which AI-related techniques apply to these components and workflows?	A technique-to-component map with controls, test evidence, and gaps	Select relevant techniques; map each to an implemented control or a planned probe, and record what remains uncovered.

For teams threat modeling AI systems, start by mapping the architecture and data flows, review each surface with STRIDE, prioritize business-impacting scenarios with PASTA, and check relevant AI techniques with ATLAS. Then revisit any lens when the system changes; keep evidence and open gaps together in one reviewable register.

Back to top · Next: STRIDE

---

🔷 STRIDE: Eight Surfaces, and What It Found

The review grouped the platform into eight trust-boundary surfaces. Start with data flows, then use the synthetic STRIDE register sample to structure your findings.

1. Agent-to-agent (A2A) calls
2. Model Context Protocol (MCP) tools
3. Qdrant vector storage
4. LLM API calls
5. Redpanda topics
6. Postgres writes
7. Airflow DAG execution
8. Agent self-registration

This A2A excerpt pairs each threat with listed controls and remaining risk. For more on the authentication controls, see Securing Agentic AI: Authentication, Authorization, and PII.

A2A STRIDE Findings and Residual Risk

STRIDE	Threat	Control	Residual
Spoofing	A forged per-agent key header impersonates the orchestrator to call a specialist agent directly	The caller-topology guard enforces allowed callers; OpenBao AppRole token introspection	Low
Spoofing	A compromised specialist agent returns fake compliance results to the orchestrator	Retry and circuit-breaker verify HTTP 200 and schema shape; a per-agent audit table	Medium: no cryptographic response signing
Tampering	A request payload is altered in transit, changing a decision-relevant field	The replay guard checks timestamp and Valkey nonce; Docker network isolation	Medium: no signature on the body; mutual TLS is not enforced in development
Repudiation	The orchestrator claims it never dispatched a task	Transactional outbox: the dispatch goes into the audit table and the outbox, then Redpanda	Low
Information Disclosure	Customer personally identifiable information (PII) in the request payload captured by a network observer	Network isolation; the PII-masking guard masks before dispatch; TLS for production	Medium: TLS not enforced in dev
Denial of Service	A flood of requests exhausts a specialist agent’s capacity	Circuit breaker, rate limit of 200 requests per minute per IP, and token budget	Low
Elevation	The orchestrator calls a specialist agent with more permissions than it should grant	OPA deny-by-default check on each agent; attribute-based access checks validated per agent	Low

The Low denial-of-service rating reflects the register’s assessment; verify that the listed controls are enabled and meet the service’s availability needs.

The Pattern Across All Eight

The May 2026 summary rates no surface above Medium. Recorded gaps include incomplete MCP role provisioning, delayed Qdrant detection, unsigned Redpanda messages, and a registration race window. These are dated findings; check the deployed configuration before relying on them.

Back to top · Next: PASTA

---

🍝 PASTA: Risk Scoring Before Controls

PASTA starts with business objectives and ranks threats by their potential impact. The assessment lists six objectives, covering Sharia compliance, privacy, fair and explainable credit, audit retention, availability, and non-discrimination. These mix regulatory references with service targets, so confirm they match current policy and scope. See the synthetic PASTA sample for an example of documenting objectives and scores.

One scope question concerns customer PII: the objective keeps it within the platform, while the technical scope includes masked calls to an external Claude API. Define whether masked prompts meet that boundary, which fields are removed, and what evidence verifies the masking.

The assessment records red-team, drift, and fairness findings. It reports an approximately 15% role-play probe bypass rate, flags Arabic-script inputs, and records an approval-rate comparison below 0.80. These are dated assessment results, not current operating measurements; revalidate them before use. Probe methods are discussed in Red-Teaming AI: OWASP LLM Top 10 and the Probes You Actually Need.

Five Scenarios, Scored Twice

The record scores five scenarios using likelihood (1–5) × impact (1–5), before and after controls. A pre-control score of 20 triggers CISO review. Scores estimate risk; they do not measure control effectiveness. Define the scale and escalation threshold before using it.

Scenario	Pre-Control	Post-Control	CISO Escalation
S1: Approval rate manipulation	15	6	No
S2: Insider model swap	10	4	No
S3: Credit score poisoning	10	6	No
S4: PII extraction via injection	20	4	Yes
S5: A2A token theft	15	2	No

The PII scenario remains escalated because its pre-control score is 20, despite a post-control score of 4. Keep both scores and link controls to test evidence; the stated zero-extraction requirement still needs evidence that it is met.

Back to top · Next: MITRE ATLAS

---

🛰️ Threat Modeling AI Systems with MITRE ATLAS

MITRE ATLAS organizes AI-specific attack techniques, including prompt manipulation, data poisoning, and unsafe agent behavior. Map relevant techniques to system components, controls, tests, and gaps. Use the synthetic ATLAS coverage sample as a starting format.

The May 2026 matrix lists 21 techniques: 11 rated Low, nine Medium, and one with different production and development ratings. It also identifies six relevant techniques without probe coverage, and several control descriptions conflict with the code. Treat these ratings as review records, then verify each control and gap against current evidence.

For each technique, record the component, control or probe, expected result, and gap owner. Then check the claimed enforcement in code and tests. In this review, conflict handling differed from the matrix description, while aggregate-statistic detection relied on a response-text heuristic.

Where the Matrix Overstates Itself

The matrix and code review disagree about three detectors: two have different implementations, and no boundary-probing equivalent appeared in the reviewed paths. Link each coverage claim to its code path, test result, and review date; label partial controls clearly.

Six relevant techniques from the Spring 2025 ATLAS additions lack probe coverage: four concern retrieval or corpus integrity, one platform-specific prompt crafting, and one impersonation. Four are marked High priority. Confirm applicability before adding probes or changing coverage claims.

Back to top · Next: Keeping the Threat Model Alive

---

🔄 Keeping Threat Modeling AI Systems Current

A threat model needs review when system boundaries change. The project keeps endpoint records in YAML and compares them with routes found in the code or running services. This can reveal missing records; it does not show whether a listed control works.

Each record includes the service, method, path, STRIDE surface, risk rating, controls, and registration details. A synthetic endpoint-register sample shows the format. When a route changes, update its record and matching STRIDE entry in the same pull request.

The scanner offers three checks: --static parses source code, live mode reads each running service’s OpenAPI description, and --validate-yaml checks the register’s structure. For adoption, run static and YAML checks in CI, and schedule live checks with an owner who can investigate discrepancies or unreachable services. Test the gate with both an unlisted route and a listed one.

A coverage view describes what has been recorded, not whether its controls work. Before sharing one, review the details it exposes and include dates, supporting evidence, and open gaps.

Back to top · Next: Using Threat Models During Development

---

🛠️ Using Threat Models During Development

A threat register is useful when each finding points to an implementation, a test, and an owner. Use it when a change affects a system boundary.

When a change adds an agent, tool, data source, or model connection, update the data-flow view first. Then use STRIDE for the changed boundary, PASTA to rank by business impact, the risk register for an owner, and ATLAS for AI-specific techniques.

From Threat Row to Code, Tests, and Evidence

1. Define and enforce the expected behavior. State what the system should reject, record, or escalate, and enforce it at the relevant boundary.
2. Test both allowed and denied behavior. For AI-specific probes, record the input and expected result.
3. Link the evidence. Connect the register row to the code change and test result; a passing test supports only the behavior it covers.
4. Assign follow-up. Name an owner for residual risk and set a trigger for the next review.

Threat Modeling AI Systems in Pull Requests

Use a pull-request checklist to require an updated threat record and relevant passing tests when a protected boundary changes. A scanner can flag missing entries; people still need to assess the threat and decide how to handle residual risk.

Back to top · Next: Key Lessons Learnt

---

🎯 Key Lessons Learnt

These lessons come from one multi-agent banking project. Adapt the recommendations to your architecture, risk process, and review responsibilities.

Lesson	Recommendation
Surface reviews help expose omissions, but coverage needs evidence.	Map components and trust boundaries; link relevant threat records to code and tests.
Scores alone do not document risk acceptance.	Keep pre-control and residual scores, escalation criteria, evidence, and an accountable owner together.
A coverage matrix describes recorded controls, not their effectiveness.	Include dates, test or scan evidence, and open gaps before sharing it.
Scanner results depend on correct inputs and workflow wiring.	Verify the register path, test registered and unregistered routes, and run the checks in CI.
Threat assessments can become stale as systems change.	Set review dates and triggers, and identify overdue findings.

---