Threat Modeling with STRIDE for Agentic AI Systems

Module 18 of 20 · Agentic AI Security Curriculum · May 2026

How to use this module

Use it as self-paced study or as instructor-led training. YAML, commands, and policy excerpts are illustrative; map them to your cloud, mesh, identity provider, and agent runtime—substitute your own names, namespaces, and tools while preserving the control intent.

Estimated time: ~35 minutes reading; add time for linked standards and team discussion.

Learning objectives

By the end of this module, you should be able to:

Apply STRIDE categories to agent identity, tools, memory, and orchestration.
Operate a living threat model tied to architecture changes.
Gate high-risk changes with documented threat–control mapping.

Prerequisites

Prior module: Production Deployment: One-Command Secure Full Stack

Suggested discussion / lab: Pick one diagram in your environment (build, deploy, runtime) and mark where this module’s controls apply; note gaps versus the checklist in the body.

Threat modeling is not a one-time exercise. In agentic MCP platforms, where systems are dynamic and agents can chain tools unpredictably, STRIDE must be a living process that evolves with the platform. This module explains how to apply STRIDE specifically to agentic AI systems.

STRIDE for Agentic Systems

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is adapted to address the unique risks of MCP, autonomous agents, and multi-backend orchestration.

S — Spoofing: Agent identity spoofing via forged session claims or stolen JWTs; model weight impersonation (model-in-the-middle attacks).
T — Tampering: Merkle tree manipulation of memory graph or documents; tool call parameter tampering in transit; model weight poisoning.
R — Repudiation: Agents denying tool calls or actions; lack of immutable audit trails.
I — Information disclosure: PII leakage through logs or MCP responses; cross-tenant or cross-vertical recall exposing restricted data.
D — Denial of service: Rogue agent GPU exhaustion; MCP gateway flooding or policy-bypass attempts.
E — Elevation of privilege: Agent escaping sandbox to host; privilege escalation via tool chaining or vertical bypass.

Living Threat Model Process

Mature programs treat the threat model as a living artifact:

Updated quarterly or on any major change (new integration, new proxy plugin, new MCP tool).
Linked directly to controls in your defense-in-depth documentation.
Reviewed as part of significant Helm or infrastructure upgrade gates.
Stored in version-controlled, signed repositories with full history.

New components (e.g., a new vertical or external MCP proxy) require a STRIDE entry before production deployment.

Gating Deployments with STRIDE

No high-risk production change should ship without:

Updated STRIDE analysis for the affected components.
Mapping of new threats to existing or new controls.
Sign-off from the security owner.

This ensures security scales with platform growth rather than becoming a checkbox.

Key Takeaways

STRIDE for agentic systems must address dynamic behaviors like tool chaining, memory recall, and multi-backend routing. Threat modeling must be continuous and tied to deployment gates, not a static document. Every new feature or integration requires explicit threat analysis and control mapping. A living STRIDE model turns security from reactive to proactive across the entire software lifecycle.

This strategic practice ties together all technical controls in this curriculum and prepares the platform for long-term evolution.

Next module: OWASP Agentic Top 10: Mapping Risks to Architectural Controls.

Commercial training use

You may reuse this curriculum internally or in paid consulting / training engagements. Keep examples aligned to the customer’s actual stack; substitute your own runbooks, tool names, and compliance frameworks (SOC 2, ISO 27001, sector regulators) where cited examples use a reference architecture only.