Combining MAESTRO and ATLAS For AI Threat Modeling

My previous article covered MITRE ATLAS at some depth: what it is, why it matters, and how the maturity filter (Feasible, Demonstrated, Realized) makes it a practical prioritization tool rather than just a theoretical catalog. If you haven’t read it, the short version is that ATLAS gives security teams a structured vocabulary for AI-targeted attacks, grounded in what adversaries have actually done. Fifty of its 167 techniques have been confirmed or “Realized” (another 121 are rated but unconfirmed; 46 remain unrated). That’s the part worth holding onto with this article.

Because here’s what ATLAS doesn’t cover: it can’t tell you how an attack might unfold in a system you’re building or defending right now, especially if that system involves autonomous agents with persistent memory, tool access, and the ability to spawn sub-agents. For a traditional web application, a retrospective TTP catalog is usually enough. The architecture is stable, and past patterns predict future ones with reasonable accuracy. Agentic AI doesn’t behave that way. An autonomous agent that can browse the web, call external APIs, write files, and delegate tasks to other agents creates an attack surface that’s still generating its first wave of documented incidents. The ATLAS case study record hasn’t caught up with what’s already in production.

That’s where MAESTRO comes in.

What MAESTRO Is and What Problem It’s Actually Solving

MAESTRO (Multi-Agent Environment, Security, Threat, Risk, and Outcome) was published in February 2025 by Ken Huang, co-chair of the CSA AI Safety Working Group. The framework’s central premise is that traditional threat modeling approaches weren’t designed for systems that make autonomous decisions, adapt behavior over time, and coordinate with other agents across trust boundaries.

That’s not a provocative claim. STRIDE models systems as static data flows between defined components (relying on Data Flow Diagrams to visualize a system at a specific point in time). PASTA’s attack simulation model assumes the system being analyzed has deterministic, bounded behavior, with no mechanism to represent a system that autonomously modifies its own goals or behavior at runtime.

Neither has a mechanism to address threats arising from goal misalignment, autonomous decision-making, or multi-agent collusion. A peer-reviewed 2025 study (Zambare, Thanikella, and Liu at Texas Tech University) reviewed existing frameworks and directly confirmed the gap, noting that STRIDE “does not model emergent behavior, cognitive reasoning of AI agents very well.” The OWASP Agentic Security Initiative reached the same conclusion, ultimately endorsing MAESTRO as a comprehensive extension of STRIDE for handling Agentic AI.

MAESTRO’s answer is a seven-layer reference architecture, each with its own mapped threat categories: Foundation Models (L1), Data Operations (L2), Agent Frameworks (L3), Deployment and Infrastructure (L4), Evaluation and Observability (L5), Security and Compliance as a vertical layer that cuts across all others (L6), and Agent Ecosystem (L7).

What that structure forces, and what classical frameworks don’t, is cross-layer analysis. Take a LangChain-based agent with RAG access. STRIDE treats it as a system with data flows. MAESTRO requires you to analyze it at L2 (the vector database is a poisoning surface), L3 (the framework itself is a supply chain risk), and L7 (the agent faces tool manipulation and identity attacks in the ecosystem it operates in). In other words, STRIDE asks, “Can someone tamper with the data moving through this system?” MAESTRO asks, “Can someone corrupt what the AI knows, compromise the tools it was built with, and manipulate who it trusts in the world it operates in,” and treats each of those as a separate, distinct problem requiring separate analysis.

Each layer carries its own threat categories, and a compromise in one doesn’t stay contained. Researchers at Texas Tech confirmed this empirically: poisoning a single memory file in L2 caused measurable performance degradation in L4 and L5 without altering any system logic. In essence, someone edited a JSON file, inserting fake high-severity attack entries that the agent reads. The agent didn’t break, but it degraded silently. The attack entered at L2 (data operations — the memory file). It affected L3 (the tuning module changed its behavior). That caused resource exhaustion at L4 (infrastructure) and degraded observability at L5 (the monitoring system itself became less responsive). One layer’s compromise propagated through three others without directly touching any of them. STRIDE would model the JSON file as a data integrity issue at one point in the system. It wouldn’t predict that corrupting the file would degrade the monitoring infrastructure two layers away.

The striking fact is that a single JSON file with no code access caused an autonomous security agent to silently misjudge its environment and waste resources defending against nonexistent threats, while potentially missing those that did exist.

That’s the kind of threat STRIDE doesn’t surface. MAESTRO does.

Where the Real Threats Live

Not all seven layers carry equal risk. Three of them deserve immediate attention.

L2 (Data Operations) is where the most operationally mature threat activity currently resides. ATLAS’s Resource Development tactic shows 9 of 13 rated techniques are “Realized”, meaning adversaries have already industrialized data poisoning against retrieval systems. Any organization running a production RAG pipeline should treat L2 threat modeling as urgent, and the Texas Tech cascade described above began here, with a single poisoned file.

L7 (Agent Ecosystem) is where agentic AI diverges most sharply from everything that came before. Agent impersonation, tool squatting, rug pull attacks against MCP integrations, and compromised discovery registries, none of which have classical equivalents. SesameOp (ATLAS case study AML.CS0042) confirmed adversaries are already using legitimate AI service APIs as covert C2 channels. That’s a fully “Realized” L7 attack chain. What makes L7 defense especially difficult is the governance baseline organizations are actually starting from. A 2025 CSA survey of 383 IT and security professionals found that 51% have no clear ownership of AI identities, and over 16% don’t track when new AI credentials are created. MAESTRO’s L7 threat categories assume someone is watching the identity layer. Most organizations aren’t.

L1 (Foundation Models) receives less operational attention, but two threat classes are particularly relevant for compliance-sensitive environments. Backdoor attacks embed hidden triggers in fine-tuned models that remain dormant until a specific input activates them. Membership inference attacks let an adversary determine whether specific records were used in training. That’s a direct HIPAA or GDPR exposure for any organization fine-tuning on sensitive data.

Using ATLAS and MAESTRO Together

The two frameworks solve different parts of the same problem. MAESTRO generates a systematic threat list from the architecture up. ATLAS tells you which items on that list adversaries have confirmed in the wild.

The workflow that combines them is straightforward. Take each layer of your system and ask: what could go wrong here? That’s the MAESTRO step. Then check ATLAS for each threat you’ve identified: has anyone actually done this? If a technique is tagged “Realized,” it moves to the top of your risk register. If it’s “Demonstrated” or “Feasible,” it still matters, but it’s not yet confirmed in the wild. The CSA Agentic Red Teaming Guide then provides concrete test procedures you can run against each layer to validate whether your system is actually exposed.

The Texas Tech study is the clearest argument for why you need both. The L2-to-L4/L5 cascade, the researchers confirmed, had no corresponding “Realized” ATLAS technique at the time of publication. MAESTRO predicted the attack class. ATLAS didn’t have the incident. That’s exactly where the combined methodology earns its keep.

One honest caveat: 46 of ATLAS’s 167 native techniques are unrated (as of this writing), and most are newer agentic additions. The “Realized” filter works well for L2 and L4 threats. For L7, it’s less discriminating. Treat more L7 items as “Demonstrated” rather than “Realized” until the incident record catches up.

What This Pairing Doesn’t Solve

MAESTRO doesn’t yet have a formal specification. No versioning, no conformance testing, no defined scoring methodology that I could find. The AgentRFC framework from Dartmouth and Palo Alto Networks produced companion security principles with formal conformance language. MAESTRO doesn’t operate at that level of rigor, and practitioners building repeatable assessment processes will hit that ceiling.

Both frameworks share a documented scope gap. ATLAS explicitly excludes malicious use of AI against non-AI targets, and MAESTRO follows the same boundary. AI-enhanced phishing, AI-automated vulnerability discovery, and deepfake-assisted social engineering aren’t covered. If your threat model needs to include those vectors, you’re working outside both frameworks.

There’s also no native scoring engine. OWASP’s Agentic Vulnerability Scoring System needs to be applied separately for quantitative prioritization.

And the constraint that no framework resolves: the CSA NHI survey found only 8% of organizations are highly confident their legacy IAM can handle AI and NHI risks, and 24% take more than 24 hours to revoke a compromised credential after an exposure event. A rigorous threat model is only as useful as the organization’s ability to act on it. Closing that operational gap is a separate, harder problem.

Where to Start

The combined methodology reduces to three questions applied to any AI system your organization operates.

1. What does your AI system actually touch? Map your system against MAESTRO’s seven layers. In practice, this means listing: which foundation model you use (L1), what data sources feed it and where they’re stored (L2), which framework or platform it’s built on (L3), where it runs and who manages that infrastructure (L4), how you monitor its behavior and measure its performance (L5), and what external tools, APIs, or other agents it can access (L7). Many teams will discover layers they haven’t thought about as attack surfaces, particularly L2 (the data the AI trusts) and L7 (the tools and services it connects to).

2. Which of those layers have confirmed attacks in the wild? Cross-reference your layer map against ATLAS. Start with L2: nine of thirteen techniques in ATLAS’s Resource Development tactic are “Realized,” meaning adversaries have demonstrated them in real incidents. If your AI system ingests external data — retrieval-augmented generation, fine-tuning on user data, or any pipeline that feeds information to the model — that’s your most evidence-backed risk. Any layer where ATLAS shows “Realized” techniques goes to the top of your risk register.

3. Can you actually detect and respond if something goes wrong? This is where most organizations hit the real gap. MAESTRO’s L5 (Evaluation and Observability) asks whether your monitoring can detect a compromised AI agent, not just whether the system is up, but whether it’s making trustworthy decisions. And the governance question is unavoidable: the CSA NHI survey found 51% of organizations have no clear ownership of AI identities. If no one owns the AI identity layer, your threat model describes a problem that nobody is accountable for fixing.

For CISSP holders, questions 1 and 2 fall under Domain 1 (Security and Risk Management). Question 3 spans Domain 8 (Software Development Security) for the monitoring and testing controls, and Domain 1 again for the governance structure. The CSA Agentic Red Teaming Guide provides executable test procedures for each MAESTRO layer once you’ve completed the mapping.

Assign ownership first. Then model the threats.