The AEGIS Threat Modeling Framework: A Practical Standard for Securing Intelligent Systems

We live in an era where AI doesn't just process information - it makes its own decisions to achieve certain goals. The rise of agentic systems - autonomous or semi-autonomous AI that plans, reasons, and acts across digital and physical environments - is bringing both transformative efficiency and new levels of risk to organizations. Addressing these risks requires a threat modeling approach that extends beyond analyzing static system architecture components.

Instead of concentrating solely on system components, threat modeling of agentic systems requires examining how agents embedded within application architectures form and execute decisions - and how autonomy, memory retention, tool access (MCP), and environmental signals combine to introduce new classes of security risk.

As organizations race to deploy AI's capabilities, the security community faces a pressing question: how do we model, measure, and remediate threats in systems that think and act for themselves?

The AEGIS Framework was built to answer this question.

AEGIS = Agentic Exploits, Guardrails, Impacts, and Safeguards

In agentic systems, the attack surface is no longer confined to static architecture - new surfaces emerge as AI agents form goals and navigate the decision pathways that follow.

Building AI Security at Comcast: Lessons from the Frontlines

In 2023, Generative AI entered our collective consciousness and was soon followed by Agentic AI. Like many organizations, we faced a daunting challenge: keeping pace with the explosive growth of AI across different parts of the business. In early 2024, Comcast launched a program to consider new risks emerging from the use of these capabilities. New technologies were emerging so quickly that the next innovation often appeared before the current one even reached production.

Turning to Industry Research

We decided to anchor our approach in emergent best practices. We explored frameworks from OWASP and MITRE, engaged in conversations with security teams at peer companies, and analyzed research from AI platform providers. We also invested in formal training for our own teams.

This effort confirmed that information about securing AI was fragmented. We needed to consolidate and customize information into a practical framework which could be used by our Threat Model architects, our Security teams, and our developer community. This framework would:

• Synthesize industry research into actionable guidance.

• Identify required safeguards for applications driven by autonomous agents.

• Define the toolset and methodology required to assess AI systems effectively.

Built for Threat Model Architects - Usable by Security Practitioners and AI Developers

AEGIS supports multiple roles responsible for building security into agentic AI applications. This includes developers, engineers, and security professionals who build and interact with agentic systems daily. AEGIS can be applied across the AI system development lifecycle - from model ingestion to runtime decision validation - without requiring deep expertise in data science.

Let's begin with defining an ontology to drive the mental model required to evaluate agentic systems, identify where autonomous decisions originate, and understand how an intelligent system can influence its environment.

Key Foundational Ontology

• Agency
  The degree of an AI System's agentic capabilities - including its ability to reason over inputs, maintain and access memory, form goals, invoke tools, and execute actions - combined with the level of autonomy it has to perform these functions.
  
  A support bot with the power to auto-close incident tickets would have a high degree of agency.
  
  

• Risk
  The degree of an agentic AI system's actions to cause harmful side-effects due to unintended, misaligned, or adversarial influenced decision-making.
  
  An agent incorrectly approving an internal system change because it misread contextual signals that leads to a production outage for a critical system.
  
  

• Memory
  The information an agentic AI system stores or retrieves to inform future reasoning, typically implemented through vector databases, semantic embeddings, or other mechanisms that preserve contextual knowledge over time. It allows AI agents supporting the system to maintain continuity, adapt their decisions, and draw on past interactions or state.
  
  An agentic sales application recalling past customer issues (using a Vector database) to tailor a recommendation for a current issue.
  
  

• Decisions
  The AI system's internal selection of a path forward based on its inputs, reasoning, and available context.
  
  An orchestration agent choosing the fastest workflow route to complete a request.
  
  

• Actions
  The concrete operations carried out by the agentic AI system after making a decision. Actions can be human approved (controlled) or autonomously executed (unbound)
  
  Unbound Action: An agent executing an API call as a result of making a decision without any human approvals
  
  

• Side-effects
  Resulting outcomes of an agentic AI system's actions.
  
  An agent updating a database entry and, as a side-effect, triggering re-runs of downstream analytics jobs.
  
  

• Agency Chain
  A sequence of events within an AI system, initiated by specific inputs and contextual signals, progressing through reasoning and decision-making, leading to actions, and culminating in the side-effects those actions produce.
  
  An agent detects a change in the ownership of an application (input). Since ownership has changed (reasoning), the agent decides to update the assigned owner for all tickets mapped to that application (decision). The agent takes action and invokes an MCP tool in its arsenal that executes an API to update the ownership of these tickets (action). The result is an updated owner of these tickets (side-effect).
  
  

• AEGIS Threat Library
  The structured threat library that catalogs how agentic AI systems can fail or be manipulated, along with the safeguards needed to prevent those failures. This also includes the Applied Threat model Dialogue (ATMD) to uncover the threat's existence. Each AEGIS threat is structured into the following sections: Overview, Mitigations, Guardrails, ATMD.
  
  The excessive agency threat entry within the AEGIS threat library shows how an attacker can abuse over privileged autonomous agents. It also outlines the specific mitigations and guardrails that should be implemented to prevent this threat.

• Agency Levels: Understanding Agentic Capabilities

  In AEGIS, agency refers to the range of agentic capabilities a system possesses, including how it reasons, retains context, interacts with tools, and carries out actions. A system's agency level is determined by how these capabilities are combined in practice - shaping how independently it can operate, how decisions are made, and how much human oversight remains in the loop. This agency level is a foundational input to threat modeling, defining the scope and nature of decisions, actions, and trust boundaries that must be evaluated.
  
  

  The agency levels below provide a practical way to think about increasing agentic capability, from simple, prompt-driven systems to fully autonomous agents operating across environments. As agency increases, so does behavioral complexity, the likelihood of unintended side-effects, and the depth of analysis that is required during a threat model.

Understanding an agentic system's agency level provides essential context for threat modeling, particularly in determining the depth of evaluation required. Systems with more complex decision-making, broader tool access, and richer memory capabilities introduce a greater number of potential decision paths and interaction points. As agency increases, assessors must account for the expanded set of actions an agent can take and the wider range of external systems it can influence. Assessors apply this understanding during assessment.

Turning Understanding into Assessment

While the AEGIS Threat Library defines what can go wrong, Threat Modeling guides how to uncover what can go wrong. Threat Modeling involves three phases:

Preparation → Execution → Post-Analysis

Preparation

Before any meaningful evaluation can begin, assessors need a full picture of the system, its interfaces, and its intended behavior.

Preparation primarily focuses on four questions:

• What are the goals of the agentic system?

• What environments, tools, and data does each agent interact with?

• What is the projected Agency Level of the system, including the deterministic versus non-deterministic decision pathways?

• What is the projected risk level of the system?

Architects review system diagrams, goals, inputs, outputs, and the boundaries where autonomy begins and ends. We leverage Comcast-developed AI security tools to enrich pre-engagement understanding of the system under review. These tools understand industry standards, security frameworks, and have contextual knowledge of Comcast's cybersecurity posture. This allows threat modelers to quickly analyze system artifacts, source code, and architecture details to surface relevant AEGIS threats that could exist along with high-risk agency chains and areas requiring deeper manual scrutiny using relevant context.

The outcome results in documents that architects review ahead of the interactive session, thus allowing them to determine and map out an analysis approach for the highest-risk decision paths and agency chains.

Execution

Once the groundwork is laid, architects begin evaluating how the reasoning, memory, and actions of the system being assessed could be influenced or misdirected. This interactive threat modeling exercise is conducted with the system's agentic AI developers. This phase is the heart of the Threat Model Methodology.

Execution uses structured, dialogue-driven techniques that walk through:

• How the system:

  • Interprets inputs

  • Accesses and retains memory

  • Is intended to behave versus how it realistically behaves

  • Reasons and determines decision paths

  • Decides which actions to execute

• Tools and APIs it can access

• Side-effects produced by actions

• Where adversaries could influence or exploit agency chains

As this walkthrough unfolds, specific threat conditions begin to surface. These conditions emerge when the system's architecture, configuration or absence of protective controls aligns with known agentic failure patterns. Examples include overly permissive actions that enable excessive agency, lack of input filtering that allows prompt injection, and ambiguous approval boundaries that permit workflow manipulation. At this stage, the objective is to identify and validate probable threats based on observed system behavior.

Each AEGIS threat includes an Applied Threat Model Dialogue (ATMD), which serves as a foundational guide for threat discovery during this phase. It provides structured questions and investigative prompts that help architects and developers examine agentic behavior and identify where it could be exploited. ATMD is intentionally not prescriptive or exhaustive; its purpose is to establish a common analytical baseline that architects can apply and adapt across different agentic system designs, use cases, and technology stacks. While ATMDs are defined within the AEGIS Threat Library, they are applied selectively during execution based on pre-engagement documents and observed system behavior, allowing threat validation to be driven by evidence rather than assumptions.

Used this way, ATMD helps teams consistently surface and reason about threats by anchoring discussion in the system's actual behavior and configuration. It enables architects to evaluate whether appropriate protections exist in scenarios where agent behavior could be misused or manipulated, while allowing for architectural judgment and domain-specific nuance.

Dialogue-driven analysis also examines how agent orchestration workflows unfold over time, including unusual sequencing, repetition, or timing of actions that may indicate misuse or manipulation, even when individual steps appear valid.

The outcomes of these discussions - including evaluation of agentic behavior, threat identification, and gaps in protections - carry forward into the post-analysis phase.

Post-Analysis

The post-analysis phase translates the outcomes of the execution phase into concrete security decisions through in-depth analysis.

This includes:

• Identifying misalignments between intended versus actual system behavior.

• Consolidating and reviewing identified threats

• Mapping confirmed threats to AEGIS identifiers

• Designing appropriate remediations that fit the system's architecture

Following the execution phase, the same Comcast-developed AI security tools mentioned previously are used for post-analysis by reviewing session notes, identified agency chains, and observed behaviors. By correlating these outputs with known threat patterns, standards, and historical system issues, the tools highlight potential gaps and generate additional AEGIS threats based on context retrieved during the execution phase. This supports a more thorough analysis while reinforcing the need for ongoing reassessment as systems evolve.

During post-analysis, validated threats are mapped to their corresponding entries in the AEGIS Threat Library to ensure consistent interpretation and remediation. The Mitigations and Guardrails sections of each threat provide design-time and runtime control patterns - including orchestration-level protections that govern how actions are sequenced and executed across workflows. Architects evaluate and tailor these threats to the system's architecture, level of agency, and operational constraints. This mapping ensures remediation decisions are grounded in known agentic exploit patterns rather than ad hoc fixes, while also informing ongoing monitoring and orchestration hardening as agent behavior evolves.

Post-analysis outputs become the backbone of secure design plans, engineering backlogs, and future maturity improvements as the system's agency level continues to evolve. Because agentic systems change over time, threat modeling cannot be treated as a one-time exercise. As teams introduce new capabilities, relax approval boundaries, or expand tool access, both agency and risk levels will likely increase, warranting re-assessment to ensure controls remain aligned with the system's actual behavior and potential impact. Tracking how agency and risk evolve provides clear guidance on new decision paths, tools, or interactions requiring renewed scrutiny.

The value of agentic threat modeling isn't just diagnosing risks - it produces clear, defensible guidance on how to reduce risks. Post-analysis ensures the insights don't stay theoretical; they become concrete architectural decisions.

Applying the AEGIS Threat Library

The AEGIS Threat Library supports all phases of the AEGIS Threat Model Methodology. The Threat Library is not applied as a static checklist or a one-time reference. It is used progressively across the threat modeling lifecycle, with different sections of each AEGIS threat informing assessment and decision-making.

During preparation, architects reference threat overviews to understand relevant agentic failure patterns and review associated ATMDs to plan targeted lines of inquiry for execution.

During execution, ATMDs are applied selectively as system behavior is examined, helping validate whether suspected threats exist based on real configurations, agency, and protections.

During post-analysis, identified threats are validated and confirmed threats are mapped to their corresponding AEGIS entries. The Mitigations and Guardrails sections of AEGIS provide the design-time and runtime controls, including controls that operate across agent workflows and orchestration layers, ensuring remediation decisions align with known agentic exploit patterns. By this stage, teams have mapped the system's agency chains, examined how decisions are made, and identified where behavior diverges from intent - including cases where threats emerge from how actions are sequenced or repeated across workflows rather than from a single decision.

The result is a threat assessment grounded in observed behavior, not theoretical risk.

AEGIS Threat Analysis in Practice

AEGIS takes these observed behaviors and maps them to known agentic failure patterns, helping teams determine which threats are most likely to exist. By grounding analysis in real decisions, actions, and side-effects, the framework enables focused evaluation before mitigations, guardrails, and orchestration hardening practices are applied. A key part of this analysis is comparing how a system is intended to behave with how it actually behaves once autonomy, context, and tooling are introduced.

The following example shows how comparing intended behavior to actual behavior exposes agentic failure patterns that may not be obvious during design.

Intended Behavior
An internal support agent is designed to assist engineers by summarizing incident context and suggesting remediation steps. It can read logs, reference historical tickets, and post summaries into an internal collaboration channel.

Actual Behavior
During post-analysis, architects discover that the agent occasionally includes raw log excerpts "for completeness." In several cases, those logs contain internal identifiers, stack traces, and API tokens. The agent isn't malicious - it is optimizing for helpfulness - but it lacks awareness of what should never be logged in clear text.

AEGIS Threat - Context Leakage
This threat applies because the agent's reasoning prioritizes completeness over data sensitivity, allowing internal context to escape through legitimate output channels. The agency chain reveals that no safeguards exist to inspect or redact outbound content before it's shared.

Related Stories

Decision-Making as the New Attack Surface

The example above highlights a core shift in how risk manifests in agentic systems. The issue wasn't a misconfigured control or a missing permission - it was a decision the system made based on context, memory, and optimization goals. This reflects a broader pattern we've observed at Comcast when evaluating agentic systems - risk emerges from dynamic reasoning and action rather than static configuration.

AEGIS provides a way to evaluate this kind of dynamic reasoning directly - helping teams understand how an agent's goals, memory, and decision paths could be influenced, and how those risks scale based on the system's level of agency and potential impact. Architects can then determine where autonomy meaningfully amplifies threat likelihood and where guardrails, mitigations, and orchestration level controls are required.

When decision-making becomes the primary security boundary, identity, accountability, and bounded controls become unavoidable security requirements for agent-driven systems to ensure actions executed by autonomous decision making remain aligned with their intended design and constraints.

Understanding which agent is making those decisions becomes critical, requiring a clear mapping between agents and their identities. Without that mapping, it becomes difficult to attribute actions, trace agency chains, or meaningfully interpret agent observability signals when agents behave in anomalous or unexpected ways that deviate from their intended workflow paths. At Comcast, we are exploring how existing enterprise identity, centrally managed agent registries, agent lifecycle governance, privileged access management controls, and cryptographic capabilities can be extended to support agent identity. We hope to provide an update on this work in a future blog post.

Conclusion

AI-driven autonomy is re-defining how systems behave. AEGIS helps with security assessments of these systems. It is a blueprint to help identify risks in agentic systems. AEGIS is detailed enough for experts, accessible enough for developers, and mature enough to anchor the next generation of secure system design.