STRIDE was built for systems that do what they are told.
Security teams have relied on STRIDE and DREAD for decades because those frameworks match how software behaves. A service receives input, processes it according to fixed logic, and produces output. The threat model asks: where can an attacker spoof, tamper, repudiate, disclose, deny, or escalate? The answers are bounded because the system's behavior is bounded.
AI agents break every one of those assumptions.
What is an agentic AI system, exactly? It is an autonomous system that takes multi-step actions on behalf of users using tools, APIs, and SaaS integrations. It does not follow a fixed execution path. It reasons about goals, selects tools, chains actions, and adapts based on intermediate results. Two identical prompts to the same agent can produce two entirely different sequences of tool calls. That is not a bug. It is the design.
STRIDE asks: "What can an attacker do to this system?" For an autonomous agent, the harder question is: "What can this system do, to whom, under what conditions, and who authorized any of it?" Those are identity and authority questions, not just attack surface questions.
The configuration-time analysis problem is equally serious. Traditional threat modeling happens at design time. Security teams review architecture diagrams, data flow diagrams, and trust boundaries. For AI agents, configuration-time analysis shows theoretical configuration: what the agent is set up to do on paper. It does not show effective authority: what the agent can actually execute inside each SaaS application it touches, given how entitlements resolve at runtime.
One enterprise discovered 377 Microsoft Copilot agents through a security assessment. None appeared in any architecture diagram. None had been through a threat modeling exercise. They existed, they were running, and they had access. That is the shadow agent gap that configuration-time frameworks cannot close.
The result is ghost chasing. Security teams review policy documents and connector configurations, flag theoretical risks, and have no runtime evidence to confirm whether any of it matters. The agents keep running. The blast radius keeps growing.
The OWASP Top 10 for Agentic AI and the companion OWASP Low-Code/No-Code Security (LCNC-SEC) project are the most operationally useful starting points for agentic AI threat modeling. They map directly to the attack patterns that enterprise security teams are already encountering: privilege escalation via maker mode credentials, confused deputy attacks, excessive data access, and agent impersonation.
The table below maps each relevant OWASP category to the threat modeling question it answers and the runtime signal that confirms the risk is real.
OWASP CategoryThreat Modeling QuestionSignal to Look ForLCNC-SEC-01: Account ImpersonationCan a lower-privilege user invoke this agent and receive data they are not authorized to see?Runner identity does not match the entitlement level of the agent's embedded credentialsLCNC-SEC-05: Security MisconfigurationIs this agent publicly accessible or org-wide without access controls?Agent URL accessible without authentication; no invoker identity requirementLCNC-SEC-06: Excessive Data AccessDoes this agent access more data than its workflow actually requires?Agent queries records, files, or objects outside the scope of its stated purposeOWASP Agentic: Privilege EscalationCan this agent acquire permissions beyond its initial grant through action chaining?Agent calls a tool that returns a token or role elevation used in a subsequent callOWASP Agentic: Confused DeputyCan an unauthorized user manipulate this agent into using its elevated permissions on their behalf?Invoker identity has no direct access to the resource the agent retrievesOWASP Agentic: Excessive AgencyDoes this agent have more tool access than its workflow requires?Agent has write or delete permissions on systems it only needs to readOWASP Agentic: Credential ExposureAre credentials embedded in the agent configuration accessible to unintended parties?Hardcoded secrets, shared connectors, or maker mode connections with admin-level credentialsOWASP Agentic: Insecure Agent CommunicationDoes this agent share full context with sub-agents or downstream agents?Supervisor agent forwards entire conversation context including sensitive fields to sub-agents
"The question for security teams should not just be: which agents exist. It is what they can actually execute, on whose behalf, with what downstream reach, and whether any of that is policy-aligned."
OWASP provides the vocabulary. The methodology below provides the process for answering each of these questions systematically, for every agent in your environment. For a deeper look at the attack surface these categories represent, see AI agent attack vectors security teams need to know.
Agentic AI threat modeling requires four sequential phases. Each phase builds on the last. Skipping Phase 1 makes Phase 2 impossible. Skipping Phase 2 makes Phase 3 produce false confidence.
The first question is always: what agents exist? Security teams cannot threat model what they cannot see. This phase produces a complete agent inventory across every platform in scope, including the agents nobody registered.
For each agent, capture:
An orphaned agent whose creator account is disabled but whose credentials are still live is a critical finding at this phase. The agent continues running with inherited permissions that no active owner can review or revoke.
Theoretical configuration tells you what the agent is set up to do. Effective authority tells you what it can actually do inside each connected application after all entitlements resolve.
These two numbers are rarely the same. Ninety percent of agents hold excessive privileges relative to what their workflows actually require. A connector configured for "read access" may resolve to admin-level entitlements inside Salesforce because the creator holds an admin role and the connector inherits it.
For each agent, map:
This phase surfaces the maker mode risk directly. When a user without Salesforce access invokes an agent built with an admin's credentials, the user receives Salesforce data at admin resolution. No access control was bypassed technically. Your IAM was simply invisible to the interaction. Securing Salesforce Agentforce workflows requires this analysis before any other control can be meaningful.
Action chaining is the mechanism by which agents compound access across multiple tool calls. A single agent interaction can involve five, ten, or twenty sequential tool calls, each one building on the output of the last.
Decompose each agent's possible action chains by asking:
This phase frequently reveals that agents with individually acceptable permissions can reach critical data through multi-step sequences that no single permission review would flag. For a structured look at these attack patterns, see the full AI agent attack surface analysis.
Individual risk factors often score as medium severity. Two medium-severity factors on the same agent frequently produce a critical-severity finding. This is the toxic combination problem.
Review each agent's risk factor profile and flag combinations such as:
Each combination multiplies the blast radius of the other factors. A publicly accessible agent with maker mode admin credentials is not two medium-severity findings. It is a single critical-severity finding that warrants immediate remediation. For a deeper framework on how these combinations stack, see AI agent toxic combinations and risk scoring.
A financial services security team is asked to threat model a new Salesforce Agentforce workflow. The workflow is described as: "Summarize open opportunities and surface renewal risk for account executives."
Here is how the four phases apply.
Phase 1 findings: The agent was built by a Salesforce administrator. The administrator's account is active. The agent uses a connector in maker mode, meaning it runs on the administrator's credentials for every invocation. The agent is accessible to all sales users in the organization. No MCP server connections are present.
Phase 2 findings: The theoretical configuration says the agent reads opportunity records. Effective authority analysis shows the administrator's credentials resolve to read access across all Salesforce objects, including contracts, pricing rules, and HR-linked compensation records that the sales team is not supposed to see. The agent's effective authority is significantly broader than its stated purpose.
Phase 3 findings: Action chain decomposition shows the agent's first call retrieves opportunity records. A follow-up call, triggered by the agent's reasoning about "renewal risk," queries contract terms. A third call pulls account contact records including fields tagged as sensitive. The chain runs in under two seconds. No individual call appears alarming in isolation.
Phase 4 findings: Two toxic combinations are present. First: maker mode connector with admin-level effective authority plus org-wide invoker access. Any sales user can now retrieve contract and compensation-adjacent data through the agent. Second: the agent accesses files with sensitivity labels through its connected SharePoint integration, which was not documented in the original workflow description.
The overall risk rating for this agent moves from medium (based on individual factors) to critical (based on toxic combinations). The remediation path requires restricting the connector to a least-privilege service account scoped to opportunity and contact objects only, and limiting agent invocation to the account executive role rather than all sales users.
This is what AI agent governance looks like in practice: not a policy document, but a structured finding with a specific remediation action tied to a specific agent.
A one-time threat modeling exercise produces a snapshot. Agents are not static. New agents appear daily. Creators change roles. Connectors are added. MCP server connections are established without security review. The snapshot is outdated before the report is written.
Continuous threat modeling requires runtime signals feeding back into the model. The four-phase methodology above describes the initial analysis. The continuous loop adds a fifth input: what the agent actually did.
Runtime signals that update the threat model include:
Each of these signals is a reason to re-run Phase 2 (effective authority) and Phase 3 (action chain decomposition) for that specific agent. The threat model is not a document. It is a living picture of every agent's current blast radius.
The operationalization gap is real. Security teams across enterprises describe the same problem: they know agents exist, they know some are risky, but they have no systematic way to prioritize which ones to investigate first. The answer is toxic combination scoring. Agents with multiple simultaneous risk factors get investigated first, regardless of how any individual factor scores in isolation.
Where to start this quarter:
Request an AI agent risk assessment to surface the agents and toxic combinations already present in your environment before the next quarterly review.
Traditional threat modeling frameworks were built for systems that behave as designed. Autonomous AI agents do not. They chain actions, inherit credentials, resolve entitlements at runtime, and operate across platforms that no single security tool was built to see simultaneously.
The OWASP-aligned four-phase methodology in this article gives security teams a structured, repeatable process for answering the questions that matter: what agents exist, what they can actually do, how far their action chains reach, and which combinations of risk factors produce critical-severity findings.
The work does not end with a report. Runtime signals must feed back into the model. Effective authority changes when creators change roles. New connectors expand blast radius without any configuration review. The threat model must evolve with the agents it covers.
Security teams that build this capability now will have a defensible, audit-ready picture of their agentic AI risk. Teams that wait will continue ghost chasing, reviewing theoretical configurations while probabilistic agents operate without deterministic guardrails.
Start with inventory. Confirm effective authority. Decompose the action chains. Find the toxic combinations. Then build the runtime loop that keeps the model current.