History
There are already several AI threat modeling methodologies available on the market. However, they all suffer from two problems:
- Many of them are designed exclusively for LLMs, while today the greatest security risks lie not in the language model itself, but in Agentic AI. Especially in its autonomous decision-making, access to tools, persistent memory, and self-modification capabilities.
- The only framework that currently addresses Agentic AI comprehensively (MAESTRO) is very complex and requires significant technical expertise to apply effectively.
This creates an unnecessary barrier. As AI agents become increasingly common, threat modeling must become more accessible so that even professionals without deep AI security expertise can independently assess the risks of agentic systems.
Goal
AGENTIC was designed with four primary objectives:
- Simple by design – applicable without hours of training or extensive preparation.
- Intuitive perspective – questions formulated in a way that can be understood without prior AI security knowledge.
- Designed for Agentic AI – unlike frameworks built primarily for LLMs, AGENTIC addresses the unique characteristics of autonomous AI agents.
- A complement, not a replacement – AGENTIC serves as an entry point that can naturally lead to deeper, more technical frameworks whenever additional analysis is required (see the Comparison with Other Frameworks section).
Target Audience
The purpose of this methodology is to simplify threat modeling for AI agents, currently the highest-risk form of AI deployment. Thanks to this simplification, AGENTIC can be used not only by AI security specialists, but also by:
- Security professionals – enabling them to assess the security of agentic systems even without deep expertise in AI security.
- Software developers and engineers building AI agents – who need a quick security assessment before deploying to production.
- Security Champions within product teams – technical team members who are not dedicated security specialists but serve as the first line of security review.
- Professionals responsible for AI agent adoption – who need a common language for discussing “what could go wrong” with technical teams.
Elements
| Element | Description | Question | |
|---|---|---|---|
| A | Autonomy | The agent’s ability to make decisions and perform actions without human involvement. | How much can the agent do before anyone notices? |
| G | Grounding | How the agent connects its reasoning and actions to the real world. | How does the agent know that what it “knows” is actually true? |
| E | Environment | The execution environment and operational permissions available to the agent. | What can the agent execute or modify? |
| N | Neural Memory / Knowledge | Everything the agent stores and uses as knowledge, including both short- and long-term memory. | What does the agent remember? |
| T | Tools | External capabilities available to the agent. | What is the worst thing the agent could do by combining its available tools? |
| I | Iterative Self-Modification | The agent’s ability to change its own behavior over time. | How can the agent change itself? |
| C | Control | The human ability to supervise and intervene when necessary. | Can anyone stop it before it’s too late? |
A – Autonomy
Description
Autonomy defines the extent to which an AI agent can independently make decisions, plan actions, and execute tasks without requiring human approval.
Detailed Description
Autonomy can take many different forms, as shown in the table below. Moreover, different tasks performed by the same AI agent may operate under different autonomy levels.
| Level | Description |
|---|---|
| L0 – Human-Authorized | AI proposes; the human performs the action. |
| L1 – Human-Approved | AI performs the action, but only after receiving human approval. |
| L2 – Human-Monitored | AI acts autonomously while a human continuously monitors and can interrupt execution. |
| L3 – Human-on-the-Loop | AI acts autonomously with periodic or sample-based human supervision. |
| L4 – Fully Autonomous | AI operates entirely without real-time human oversight. |
Questions to Ask During the Analysis
- How much can the agent do before anyone notices?
- Which decisions can the agent make without human approval?
- Is the autonomy level consistent across all tasks, or does it differ between, for example, read and write operations?
- Is autonomy static, or can it change dynamically based on the system’s own risk assessment?
- Can the agent recognize when it is exceeding its intended authority? If so, what does it do?
- What is the worst realistic scenario in which the agent fully exploits its granted autonomy—whether due to an error or malicious intent by the person controlling it?
Example Threats
- The agent performs an irreversible action (sending an email, deleting a record, executing a financial transaction) without human confirmation.
- Goal drift – the agent pursues the objective in a way that differs from the designer’s original intent (for example, optimizing a metric rather than the intended business outcome).
- Autonomous privilege escalation in an attempt to accomplish its objective more effectively.
Example Mitigations
- Human-in-the-loop for high-impact actions, with approval thresholds based on business impact.
- Scoped goals, where objectives are narrowly defined instead of being open-ended.
- Comprehensive decision logging with full auditability and the ability to reconstruct why each decision was made.
G – Grounding
Description
Grounding describes how an AI agent connects its reasoning and actions to the real world. It covers the data sources the agent relies on, retrieval mechanisms (such as RAG), and the freshness and reliability of the knowledge used to make decisions.
Detailed Description
Grounding defines the relationship between the agent’s internal model of the world and reality. It includes both static knowledge acquired during model training and dynamic knowledge obtained through retrieval systems, search engines, APIs, and external data sources. It also encompasses the mechanisms used to verify that knowledge.
Grounding may exist at different maturity levels:
- No grounding – the agent relies solely on knowledge acquired during training, with no access to current information.
- Single-source grounding – the agent retrieves information from one source without validating it.
- Multi-source grounding – the agent combines information from multiple sources but performs no formal trust assessment.
- Verified grounding – the agent evaluates source credibility and can explicitly communicate uncertainty.
Questions to Ask During the Analysis
- How does the agent know that what it “knows” is actually true?
- Which data sources are considered trusted, and which are considered untrusted? Does the agent distinguish between them?
- What happens when different data sources contradict one another?
- Does the agent express uncertainty (“I’m not sure”), or does it always present answers with equal confidence?
- How frequently is the knowledge used by the agent refreshed?
- Does the agent distinguish between user-provided data, system data, and content retrieved from external sources?
Example Threats
- A hallucinated response is treated as fact and becomes the basis for a real-world action.
- Indirect Prompt Injection through an external document or webpage retrieved during the RAG process.
- Data/RAG poisoning, where the agent’s knowledge source has been intentionally manipulated.
- The agent acts on outdated information without detecting inconsistencies with the real world.
Example Mitigations
- Instruction/data separation to prevent retrieved content from being interpreted as instructions.
- Trust boundaries, assigning different trust levels to different information sources.
- Cross-checking or fact verification before performing high-impact actions.
E – Environment
Description
Environment refers to the execution environment of the AI agent and the permissions it possesses within that environment, including the operating system, network, infrastructure, and the logical or physical resources accessible to the agent.
Detailed Description
Environment represents the infrastructure layer of the system. It includes the operating system, containers, networks, storage, databases, internal APIs, and any resources the agent can actually reach.
Typical deployment models include:
- Fully isolated environment – sandboxed with no network connectivity.
- Partially isolated environment – restricted access to selected resources.
- Shared environment – resources shared with other systems or users.
The execution environment largely determines the risk of lateral movement and the level of monitoring required.
Questions to Ask During the Analysis
- What can the agent execute or modify?
- What capabilities does the agent have within the system? Can it read files, execute system commands, or access the Internet?
- Which specific resources (data, systems, accounts) are technically reachable from the agent’s environment?
- Could the agent theoretically access resources belonging to another team or customer?
- Does the environment have Internet access? If so, is it restricted to approved domains?
- Which logs are generated during the agent’s execution, and how long are they retained?
- Can the agent independently install software or download additional dependencies?
Example Threats
- The agent is granted excessive system privileges (for example, production access instead of a sandbox).
- Lateral movement, where access to one resource enables access to additional systems.
- Exposure of secrets or API keys due to insufficient isolation.
Example Mitigations
- Sandboxing or containerization of the execution environment.
- Domain allowlisting for outbound network connections.
- Resource limits such as rate limiting, quotas, and cost budgets.
N – Neural Memory / Knowledge
Description
Neural Memory / Knowledge covers everything the agent stores and uses as knowledge during its operation. This includes both short-term memory (within a session) and long-term memory (persistent knowledge retained across sessions).
Detailed Description
A key distinction exists between short-term and long-term memory.
Short-term memory is discarded once a session or task ends.
Long-term memory persists between sessions and may include user profiles, previous interactions, learned preferences, or historical decisions.
Possible implementations include:
- No persistent memory – every interaction starts from scratch.
- Read-only persistent memory – stored knowledge cannot be modified by the agent.
- Agent-managed persistent memory – the agent writes information without human review.
- Shared memory across multiple agents or users.
Questions to Ask During the Analysis
- What does the agent remember?
- What information is stored in long-term memory, and under what conditions?
- How long is information retained?
- Can users easily inspect what the agent remembers about them or the organization?
- Is there a mechanism to remove specific memory entries upon request?
- Is one user’s memory fully isolated from another’s?
- Is persistent memory used to personalize high-risk decisions, such as financial or medical recommendations?
- Is stored information classified according to sensitivity, or is everything treated equally?
Example Threats
- Memory poisoning, where malicious information is injected into persistent memory and influences future behavior.
- Cross-user data leakage, exposing one user’s memory to another.
- Failure to support the right to be forgotten, leaving sensitive information permanently stored.
Example Mitigations
- Encryption and per-user or per-session memory isolation.
- Validation of information before it is written to persistent memory.
- Time-to-live (TTL) and automatic expiration of stored information.
- Human-review capabilities for inspecting, auditing, and deleting memory entries.
T – Tools
Description
Tools represent the external capabilities available to an AI agent, including APIs, functions, integrations (such as function calling or MCP servers), and other mechanisms that allow the agent to interact with the outside world.
Detailed Description
Tools are more than simply a list of available APIs. They also include the way these APIs are invoked—for example, whether parameters are validated by the language model itself or by an independent middleware layer.
Another important consideration is tool composition. A single tool may appear harmless on its own, yet multiple tools combined can provide capabilities that none of them possesses individually. For example:
- Read customer data + Send email = potential data exfiltration.
Typical levels of tool capability include:
- No tools – the agent only generates text.
- Read-only tools – the agent can retrieve information but cannot modify it.
- Read/write tools – the agent can create or modify external data.
- High-impact action tools – the agent can perform irreversible operations.
Questions to Ask During the Analysis
- What is the worst thing the agent could do by combining its available tools?
- What actions can the AI agent perform in the external world?
- Which combinations of tools could provide capabilities beyond their intended purpose?
- Who validates the parameters passed to each tool—the language model or an independent middleware layer?
- Is the provider of every tool, especially external services such as MCP servers, trusted and verified?
- Does the agent have access to tools that are never actually required in normal operation?
- Are tools protected by rate limiting or other safeguards against abuse and execution loops?
- Do the tools enforce authorization themselves, or is the agent responsible for deciding whether it has permission to access specific data?
Example Threats
- Tool chaining, where individually harmless tools become dangerous when combined.
- Invocation of a tool with unvalidated parameters.
- A malicious external tool (for example, a compromised MCP server or supply chain attack).
Example Mitigations
- Tool allowlisting with fine-grained permissions.
- Least privilege for every tool integration.
- Validation of inputs and outputs at every tool boundary.
- Supply chain security practices for external integrations, including verification of MCP servers, plugins, and third-party services.
I – Iterative Self-Modification
Description
Iterative Self-Modification describes an AI agent’s ability to change its own behavior over time—for example by modifying prompts, configuration, execution strategies, or even the underlying model based on feedback, learning, or self-reflection.
Detailed Description
Self-modification exists across a broad spectrum, ranging from simple prompt adjustments to online fine-tuning of foundation models or the creation of entirely new sub-agents.
Typical levels include:
- No self-modification – the agent behaves exactly as originally configured.
- Controlled self-modification – the agent adapts only within predefined and approved mechanisms (for example, adjusting thresholds).
- Advanced self-modification – the agent can modify components that are difficult to supervise, such as dynamically fine-tuning models.
- Autonomous expansion – the agent can create new sub-agents or tools independently.
Questions to Ask During the Analysis
- How can the agent change itself?
- Can the agent inspect its own configuration or execution logic in ways that could help it bypass imposed restrictions?
- Can the agent modify its own configuration?
- Which aspects of the agent’s behavior can change autonomously, and which remain immutable?
- Can the agent create new sub-agents or autonomous processes without operator awareness?
- Is there a distinction between changes intentionally initiated by humans and those initiated automatically by the system?
- How quickly can behavioral changes made by one agent propagate to other agents or instances sharing the same configuration?
Example Threats
- The agent modifies its own system prompt to bypass restrictions.
- Reward hacking, where the agent optimizes for the measured metric instead of the designer’s actual objective.
- Unauthorized self-replication or autonomous creation of new sub-agents.
Example Mitigations
- Version control for prompts and configurations with rollback capability.
- Immutable core instructions that cannot be modified by the agent itself.
- Requiring human approval before new sub-agents can be created.
C – Control
Description
Control represents the ability of humans to supervise an AI agent and intervene effectively whenever necessary.
Detailed Description
Control consists of two complementary dimensions that are often confused:
- Observability – the ability to understand what the agent is doing.
- Actionability – the ability to intervene and stop the agent when necessary.
A system may provide excellent monitoring while lacking any practical way to interrupt execution. Conversely, a theoretical kill switch is of little value if operators cannot recognize when it should be used.
Typical maturity levels include:
- No monitoring and no shutdown mechanism.
- Passive monitoring (logs only) with no practical way to intervene quickly.
- Active monitoring with alerting but slow, manual intervention procedures.
- Full real-time supervision with an independent, immediate kill switch.
Questions to Ask During the Analysis
- Can anyone stop it before it’s too late?
- How quickly can a human detect undesirable behavior, and is there a practical mechanism to stop the agent immediately?
- Has the shutdown mechanism ever been tested, or does it exist only on paper?
- Does monitoring include the agent’s internal plans and reasoning process (where technically available), or only the final outcomes of its actions?
- How long would it realistically take to detect abnormal behavior after it begins?
Example Threats
- No functioning kill switch, or one controlled by the agent itself.
- Delayed anomaly detection caused by insufficient monitoring.
- Alert fatigue resulting in operators ignoring warning signals.
Example Mitigations
- An architecturally independent kill switch.
- Continuous monitoring and alerting for suspicious agent behavior.
Threat Modeling Process
- Answer each question in sequence For each of the seven AGENTIC elements, first answer the primary diagnostic question from the main table, followed by the detailed questions for that element.
The recommended order is: A → G → E → N → T → I → C
Each element builds upon information gathered in the previous steps, helping reduce the risk of overlooking important dependencies. - Document every answer Every response should be recorded. Together, these answers become the threat model of the entire agentic system.
- Identify the weakest point within each element After completing all questions for a particular element, identify the area of greatest concern, for example, a missing control, an unclear responsibility, or an overly permissive capability. These become candidates for high-risk findings.
- Continuously identify risks As you progress through the remaining elements, revisit previously identified weaknesses and consider what additional risks they introduce elsewhere in the architecture.
Comparison with Other Frameworks
AGENTIC was not created in isolation. It integrates well with other threat modeling frameworks for AI systems.
| Framework | Scope / Focus | Connection with AGENTIC | Limitations |
|---|---|---|---|
| PHANTOM-B (Shostack + Associates) | A lightweight framework focused on LLM threats. | Both methods provide a simple entry point for different types of systems. PHANTOM-B is designed for LLM-based deployments, while AGENTIC focuses on systems with real autonomy. Both can be used together depending on the type of project. | Focused on LLM deployments rather than dimensions specific to full agentic autonomy. |
| MAESTRO (Cloud Security Alliance) | A framework focused on multi-agent system architecture, divided into 7 comprehensive layers. | AGENTIC serves as a bridge toward this more comprehensive approach. MAESTRO is a good fit for AI security specialists. | Requires modeling the complete layered architecture and significant technical knowledge of the solution. It is less suitable for agents created inside Agentic AI tools. High entry barrier. |
| STRIDE-AI (Tsafac Nkombong & Schwarz, 2026) | A methodology focused on LLM threats. It divides analysis into 5 system layers. | STRIDE-AI can help focus on specific threat categories when combined with the AGENTIC methodology. | The authors explicitly acknowledge that the framework is “currently optimized for LLMs” and does not yet cover full agentic autonomy or multi-step actions in the real world. |
| MITRE ATLAS | The most detailed and continuously updated taxonomy of specific techniques, including an increasing number of techniques dedicated to agents. | MITRE ATLAS provides concrete techniques for each AGENTIC element. It can be used to deepen the analysis. | It is a threat-side taxonomy, not a modeling methodology. It does not define where to start when analyzing a specific system. |
| OWASP LLM Top 10 | A widely recognized common language with product teams, focused on LLM-related threats. | When working with LLM-based systems, this classification allows more detailed analysis of LLM-specific risks. LLM Top 10 fits well as an extension of PHANTOM-B. | Provides limited coverage of agent behavior in the real world (tools, persistent memory, autonomy) — it was primarily designed for LLM-based systems. |
| OWASP Top 10 for Agentic Applications | Focused on agentic applications. A current framework with precisely defined risk categories. | Complements AGENTIC. OWASP Top 10 for Agentic Applications can help focus on specific risk categories. | A risk list (what can go wrong), not a questioning process — it does not guide users step-by-step through analyzing a specific architecture. |
| SAILORS (Vinaya Vasudevan) | Focused on security controls. Analysis is performed for each AI capability. | Works well as an implementation checklist to ensure important AI agent security aspects are considered. | Focused on individual AI capabilities rather than modeling the complete behavior of an autonomous agent over time. Focused on security controls rather than threat identification. |
What AGENTIC Does Not Cover
- Threats at the model/training level — attacks against the training process, weight extraction, membership inference, adversarial examples targeting neural network architecture. These areas belong to frameworks such as MITRE ATLAS in its full scope, rather than AGENTIC.
- Deep analysis of individual prompts/interactions — AGENTIC operates at the architecture and agent configuration level, not at the level of individual conversations. For this purpose, OWASP LLM Top 10 applied directly to the LLM layer is a better fit.
- Regulatory compliance and governance requirements — the model was not designed as a compliance checklist for AI Act, ISO/IEC 42001, or similar regulations. Compliance requirements themselves define requirements that must be addressed by the AI agent.
- Subjectivity of assessments — as with every qualitative model, risk matrix results depend on the knowledge and experience of the person performing the modeling. AGENTIC does not eliminate this subjectivity; it only provides structure for the analysis.
References
Comparative Frameworks
- MAESTRO (Cloud Security Alliance, Ken Huang) — https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
- STRIDE-LM (Lockheed Martin, “A Threat-Driven Approach to Cyber Security”, 2019) — https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Threat-Driven-Ap…
Comparative Frameworks (continued)
- PHANTOM-B (Shostack + Associates, 2026) — https://shostack.org/blog/why-phantom-b/
- STRIDE-AI (Tsafac Nkombong & Schwarz, CIIT 2026) — https://arxiv.org/abs/2605.17163
(tool: https://aisecurityframework.netlify.app) - SAILORS (Vinaya Vasudevan) — https://github.com/vinayavasu/SAILORS
Threat Catalogs and Taxonomies
- MITRE ATLAS — https://atlas.mitre.org
- OWASP LLM Top 10 — https://genai.owasp.org/llm-top-10/
- OWASP Agentic AI Threats & Mitigations (T1–T17) — https://genai.owasp.org/resources/
(a document published as part of the Agentic Security Initiative; the page serves as a central resource hub) - OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10) — https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
Governance Standards and Frameworks
- NIST AI Risk Management Framework (AI RMF 1.0) — https://www.nist.gov/itl/ai-risk-management-framework
- EU AI Act (Regulation (EU) 2024/1689) — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689
