What is MAESTRO and how do I threat-model an AI agent with it?

What MAESTRO is

MAESTRO stands for Multi-Agent Environment, Security, Threat, Risk, & Outcome. It is a layered threat-modeling framework purpose-built for agentic AI by Ken Huang under the Cloud Security Alliance (CSA) AI Safety Initiative. Where STRIDE and PASTA were designed for conventional software, MAESTRO decomposes an agent system into seven architectural layers plus one cross-cutting layer, then drives threat identification both *within* each layer and *across* layer boundaries — capturing the AI-specific and emergent cross-layer threats that traditional frameworks miss.

• The unit of analysis is the agent stack, not a single binary or service.
• Threats are enumerated per layer, then between layers (the signature move).
• L6 Security & Compliance is vertical / cross-cutting — it spans every other layer rather than sitting in the stack.

The 7 layers

L1 — Foundation Models

Role: the core AI model (LLM or other foundation model) that supplies the agent's reasoning and generation. It is the bottom of the stack; every higher layer depends on it.

Representative threats (the complete canonical L1 set — seven):

• Adversarial Examples
• Model Stealing (extraction)
• Backdoor Attacks
• Membership Inference Attacks
• Data Poisoning (training phase)
• Reprogramming Attacks
• Denial of Service Attacks

Mitigations: adversarial training and robustness testing; model provenance/integrity verification and signing; input/output guardrails and content filtering; rate limiting and resource quotas to blunt model-level DoS; restrict model access and protect against extraction via query throttling and watermarking.

L2 — Data Operations

Role: data processing, preparation, and storage — databases, vector stores, embeddings, and RAG pipelines that supply the agent's knowledge and memory.

Representative threats: data/RAG poisoning, vector-store and embedding manipulation, knowledge-source tampering, and data exfiltration from knowledge stores.

Mitigations: data validation, provenance tracking, and integrity checks; secured and access-controlled vector stores / RAG sources; encryption at rest and in transit; anomaly detection on data pipelines; poisoning-resistant ingestion and source allow-listing.

L3 — Agent Frameworks

Role: the development frameworks, SDKs, toolkits, and APIs used to build agents — orchestration libraries, tool-calling interfaces, and planning logic.

Representative threats: supply-chain compromise of framework dependencies, insecure framework APIs, unsafe tool/function execution, and injection through framework integrations.

Mitigations: supply-chain security (dependency scanning, SBOM, pinned/verified components); strict input validation on framework APIs; secure-coding and code review of integrations; sandboxing of tool/function execution; rate limiting on framework APIs.

L4 — Deployment and Infrastructure

Role: the runtime environment hosting the agent — cloud, on-premise, containers, and orchestration (Kubernetes, IaC).

Representative threats: container/image compromise, misconfigured orchestration, IaC misconfiguration, lateral movement, and resource hijacking / infrastructure DoS.

Mitigations: container image scanning and signing plus hardened base images; secure orchestration config and least-privilege RBAC; IaC scanning and policy-as-code; network segmentation to limit lateral movement; resource quotas to prevent hijacking/DoS.

L5 — Evaluation and Observability

Role: performance monitoring, testing harnesses, evaluation metrics, logging, tracing, and anomaly detection that watch the agent's behavior.

Representative threats: tampered evaluation metrics or logs, blind spots in monitoring, data leakage through telemetry, and evasion of observability.

Mitigations: integrity protection and signing of evaluation metrics and logs; secured and access-controlled observability tooling; redaction/minimization to prevent leakage through telemetry; tamper-evident logging and alerting; cross-check evaluation results against independent baselines.

L6 — Security and Compliance (cross-cutting)

Role: a vertical / cross-cutting layer that enforces security controls, governance, and regulatory compliance across all other layers — including AI security agents that can themselves be attacked. It spans L1–L5 and L7 rather than occupying a slot in the stack.

Representative threats (canonical L6 set):

• Security Agent Data Poisoning
• Evasion of Security AI Agents
• Compromised Security AI Agents
• Regulatory Non-Compliance
• Bias in Security AI Agents
• Lack of Explainability
• Model Extraction

Mitigations: defense-in-depth across all layers; protect and validate security AI agents against poisoning/evasion; explainability and audit trails for security decisions; bias testing of security agents; continuous compliance monitoring and regulatory mapping.

L7 — Agent Ecosystem

Role: the top layer — the marketplace/ecosystem where agents interface with applications, other agents, tools, and end-users. Covers agent registries, discovery, identity, and multi-agent collaboration.

Representative threats (complete canonical L7 set):

• Compromised Agents
• Agent Impersonation
• Agent Identity Attacks
• Agent Tool Misuse
• Agent Goal Manipulation
• Marketplace Manipulation
• Integration Risks
• Horizontal/Vertical Solution Vulnerabilities
• Repudiation

Mitigations: strong agent identity, authentication, and authorization; tool-use scoping and least-privilege permissions; goal/intent validation and alignment guardrails; trusted agent registry and discovery (signed agent cards/capabilities); reputation, audit, and non-repudiation logging for inter-agent actions.

How the layers fit together

• L1–L5 form the build-and-run stack, from the model up through how it is observed.
• L6 wraps the whole thing as governance and enforcement — and is itself an attack surface because security AI agents can be poisoned, evaded, or compromised.
• L7 is where agents meet the outside world: other agents, tools, marketplaces, and humans. The most dangerous failures are cross-layer — e.g., a poisoned RAG source (L2) bends model reasoning (L1), which drives an over-privileged tool call (L3/L4) that propagates to peer agents (L7).

The MAESTRO methodology (6 steps)

• 1. System Decomposition. Break the system into components and map each to the seven-layer architecture. Define agent capabilities, goals, and interactions.
• 2. Layer-Specific Threat Modeling. For each layer, use that layer's threat landscape (the lists above) to enumerate threats tailored to your system's specifics.
• 3. Cross-Layer Threat Identification. Analyze interactions between layers to surface emergent threats — how a vulnerability in one layer propagates to and compounds in others. This is MAESTRO's distinguishing step.
• 4. Risk Assessment. Assess likelihood and impact of each threat using a risk matrix, then prioritize.
• 5. Mitigation Planning. Build a plan that combines layer-specific, cross-layer, and AI-specific mitigations.
• 6. Implementation and Monitoring. Implement the mitigations, then continuously monitor for new threats and update the threat model as the system evolves.

Practical tip: treat steps 2 and 3 as a loop. Enumerate per-layer first to build coverage, then walk every adjacent and non-adjacent layer pair asking "if this layer is compromised, what does it give the attacker in that layer?" Cross-layer chains — not single-layer findings — are usually the highest-severity outcomes in agentic systems.

How MAESTRO compares to STRIDE and PASTA

• STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is a per-component, threat-category checklist for conventional software. It has no concept of model reasoning, training-data poisoning, persistent agent memory, tool autonomy, or multi-agent coordination — so it leaves agent-specific surfaces (L1, L2, L7) largely unaddressed and does not reason about cross-layer propagation.
• PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric, attacker-simulation methodology with strong business-impact and stage-by-stage rigor, but it too assumes traditional application architecture. It does not provide an agentic decomposition or a built-in catalog of AI-native threats; an analyst must hand-craft all of that.
• MAESTRO is agentic-native. Its seven-layer model gives a coordinate system for *where* a threat lives, it ships per-layer AI-specific threat catalogs, and — uniquely — it makes cross-layer threat propagation a first-class, mandatory step. It also bakes in a cross-cutting Security & Compliance layer (L6) that treats the security AI agents themselves as attackable.
• They are complementary, not mutually exclusive. STRIDE's categories and PASTA's attack-simulation discipline can be applied *inside* a MAESTRO layer; MAESTRO supplies the agentic structure, the AI-specific threat lists, and the cross-layer analysis that STRIDE and PASTA lack. For an agentic system, use MAESTRO as the backbone and borrow STRIDE/PASTA techniques where they sharpen a specific layer's analysis.

Bottom line for engineers and security/compliance leads

• Map your agent system to the seven layers + L6 cross-cutting before enumerating threats — coverage gaps usually hide in L1 (model), L2 (RAG/memory), and L7 (multi-agent/ecosystem).
• The cross-layer step is where MAESTRO earns its keep: the worst agentic incidents are propagation chains, not single-layer bugs.
• Treat L6 as both your control plane and an attack surface — security AI agents need the same poisoning/evasion/explainability scrutiny as the agents they guard.
• Use STRIDE/PASTA as techniques within MAESTRO's structure, not as replacements for it.