Summary: MAESTRO’s seven-layer reference architecture for agentic AI, with the threat landscape it assigns to each layer, the five cross-layer threats, and its mitigation set.
Sources: raw/Agentic/Agentic AI Threat Modeling Framework_ MAESTRO.md
Last updated: 2026-07-30
MAESTRO decomposes an agentic system into seven layers and assigns each its own threat landscape — roughly 55 named threats in total. Layer numbering runs bottom-up: Layer 1 is the foundation model, Layer 7 the agent ecosystem. Layer 6 is a vertical layer that cuts across all the others.
Read the layers as the unit of analysis. MAESTRO’s whole claim is that threats attach to layers and, critically, to the seams between them — see maestro-asi-crosswalk for how this differs from OWASP’s component-based model.
The stack
| Layer | Name | Nature | Threats named |
|---|---|---|---|
| 7 | Agent Ecosystem | Marketplace, business applications, end users | 12 |
| 6 | Security and Compliance | Vertical — cuts all layers | 7 |
| 5 | Evaluation and Observability | Benchmarking, monitoring, anomaly detection | 6 |
| 4 | Deployment and Infrastructure | Cloud, on-prem, containers, orchestration | 6 |
| 3 | Agent Frameworks | Toolkits, libraries, integration frameworks | 6 |
| 2 | Data Operations | Databases, vector stores, RAG pipelines | 5 |
| 1 | Foundation Models | The LLM or other core model | 7 |
“Each layer serves a specific purpose while abstracting complexity from the layers above it, enabling modular development, clear separation of concerns, and systematic implementation” (source: Agentic AI Threat Modeling Framework_ MAESTRO.md, §3.2).
Layer 7 — Agent Ecosystem
The densest layer, and the one with the least coverage elsewhere in the vault. It models the market for agents, not just the agents:
- Compromised agents — malicious agents posing as legitimate services.
- Agent impersonation — deceiving users or other agents. Compare T9.
- Agent identity attack — compromising identity and authorisation mechanisms.
- Agent tool misuse — manipulation into unintended tool use. Compare T2.
- Agent goal manipulation — redirecting objectives. Compare T6.
- Marketplace manipulation — false ratings, reviews and recommendations promoting malicious agents.
- Integration risks — vulnerabilities in the APIs and SDKs used to integrate agents.
- Horizontal/vertical solution vulnerabilities — weaknesses specific to industry-vertical agent products.
- Repudiation — agents denying actions they performed. Compare
T8, and agent-observability-and-logging for the control. - Compromised agent registry — injecting malicious listings or altering legitimate entries.
- Malicious agent discovery — manipulating discovery to promote malicious agents or bury legitimate ones.
- Agent pricing model manipulation — exploiting agent pricing for financial gain or to inflict loss.
- Inaccurate agent capability description — misleading capability claims causing misuse or over-reliance.
Four of these have no counterpart anywhere else in the vault: marketplace manipulation, compromised agent registry, malicious agent discovery, and pricing-model manipulation. They are the economic and discovery layer of an agent marketplace — a surface that exists only once agents are bought, listed and ranked. MAESTRO is the vault’s only source on it.
The nearest adjacent coverage is the supply chain collection on model-hub trust and ATLAS on malicious models published to Hugging Face — both about artefact distribution, not agent-service discovery and ranking.
Layer 6 — Security and Compliance (vertical)
The framework’s most distinctive move: this layer assumes AI agents are themselves used as security tools, and models attacks against them.
- Security agent data poisoning — manipulating the training or operational data of a security agent so it misidentifies threats or floods analysts with false positives.
- Evasion of security AI agents — adversarial technique to slip past an agent-based detection.
- Compromised security AI agents — taking control of the defence and using it offensively, or to disable other controls.
- Regulatory non-compliance by AI security agents — a security agent breaching privacy law through misconfiguration or improper training.
- Bias in security AI agents — biased security agents protecting some systems less than others.
- Lack of explainability in security AI agents — inability to audit the defence’s own decisions or root-cause its failures.
- Model extraction of AI security agents — stealing the detection model to learn how to bypass it.
This is the only place in the corpus where the defensive AI is the target. Every other framework in the vault models attacks on the protected system. The consequence is uncomfortable and worth stating plainly: deploying agents as security controls extends the attack surface rather than only reducing it, and the controls in the control catalogue that recommend AI-based detection inherit every Layer 1 and Layer 2 threat below.
“Bias” and “regulatory non-compliance” sitting in a threat landscape is a category stretch — these are failure modes rather than adversary actions, though both are reachable by an attacker who controls the agent’s data. The compliance angle connects to AI Act Article 15 and the high-risk requirements.
Layer 5 — Evaluation and Observability
- Manipulation of evaluation metrics — poisoned datasets or biased test cases making an agent benchmark better than it is.
- Compromised observability tools — malicious code in monitoring that exfiltrates data or hides malicious behaviour.
- Denial of service on evaluation infrastructure — blocking the testing that would detect compromise.
- Evasion of detection — agents designed to avoid triggering observability alerts.
- Data leakage through observability — sensitive data exposed via logs and dashboards through misconfiguration.
- Poisoning observability data — corrupting the monitoring feed to mask activity from security teams.
Three of the six are attacks on visibility itself. This is the layer that makes agent-observability-and-logging load-bearing: an audit trail is a control, and MAESTRO’s Layer 5 says the audit trail is a target. The pairing is direct — the structured-log schema in that page is the artefact “poisoning observability data” and “data leakage through observability” both attack.
Layer 4 — Deployment and Infrastructure
Conventional cloud appsec, applied to agent hosting: compromised container images, orchestration attacks (Kubernetes), IaC manipulation (Terraform, CloudFormation), DoS, resource hijacking (cryptomining on agent infrastructure — compare ATLAS’s LLMjacking case study), and lateral movement.
MAESTRO’s contribution here is not novelty but placement: it insists these belong inside the agentic threat model rather than being deferred to “normal” infrastructure security. OWASP ASI’s component model has no layer for them at all.
Layer 3 — Agent Frameworks
Compromised framework components, backdoor attacks (hidden functionality in the framework itself), input validation attacks (code injection through framework input handling), supply chain attacks on framework dependencies, DoS on framework APIs, and framework evasion — agents built specifically to bypass the security controls of the framework hosting them.
Framework evasion is the interesting one, and it has no analogue in T17: it treats the framework’s guardrails as a control an agent can be built to defeat, rather than treating the framework as a component an attacker compromises.
Layer 2 — Data Operations
Data poisoning (training-time), data exfiltration, DoS on data infrastructure, data tampering (in transit or at rest), compromised RAG pipelines.
Fully covered elsewhere and better: the data poisoning collection on poisoning, T1 on retrieval-time corruption, and LLM08 on vector and embedding weaknesses. MAESTRO adds nothing here beyond placement.
Layer 1 — Foundation Models
Adversarial examples, model stealing, backdoor attacks (hidden triggers in the model), membership inference, data poisoning (training phase), reprogramming attacks (repurposing the model for a task other than its intent), and DoS — the last of which is the only entry given more than a sentence.
The DoS entry names sponge attacks specifically: adversarially crafted inputs “that exploit model complexity vulnerabilities” to exhaust compute, degrade inference and cause unavailability, producing “cascade failures across dependent AI agents” and increased cost. This is the vault’s most explicit statement of model-level resource exhaustion cascading through an agent fleet — compare T4 Resource Overload and LLM10 Unbounded Consumption, both of which treat it as a single-system concern.
Otherwise this layer duplicates model theft and data poisoning, which cover the same ground in depth.
Five cross-layer threats
The part of MAESTRO that justifies the layered structure. Threats that exist only between layers:
| Threat | Mechanism |
|---|---|
| Supply chain attacks | Compromise a component in one layer (a Layer 3 library) to reach another (the Layer 7 ecosystem) |
| Lateral movement | Access to Layer 4 leveraged into Layer 2 |
| Privilege escalation | Unauthorised privilege in one layer used to manipulate others |
| Data leakage | Data from one layer exposed through another |
| Goal misalignment cascades | Misalignment in one agent (from Layer 2 poisoning) propagating to other agents through Layer 7 interactions |
The worked chain the source gives: compromise container infrastructure (L4) → gain access to a running agent instance → inject malicious data into its data store (L2) → poison the next model update → compromise the foundation model (L1) (source: Agentic AI Threat Modeling Framework_ MAESTRO.md, §3.2 B).
Goal misalignment cascades is the genuinely agentic one and the closest MAESTRO comes to an original threat. It is the same mechanism as T5 and T12 but framed as goals propagating rather than content — a poisoned objective spreading agent-to-agent. Compare also context poisoning, where the identical cascade occurs with no attacker at all.
Mitigations
MAESTRO’s control set is thin — given once, globally, not per threat:
Layer-specific — “implement controls tailored to the specific threats of each layer,” with no elaboration.
Cross-layer — defence in depth; secure inter-layer communication protocols; system-wide anomalous-behaviour monitoring; an incident response plan for multi-layer incidents (compare AI incident response).
AI-specific — adversarial training; formal verification of agent behaviour and goal alignment; explainable AI for auditability; red teaming; runtime safety monitoring.
Formal verification of goal alignment is the most ambitious control in the entire corpus and is stated in one clause with no method, no tooling and no caveat about tractability. Treat it as an aspiration, not a control. The rest duplicate the ASI playbooks, which are considerably more implementable, and the control catalogue.
No mitigation is mapped to any individual threat. With ~60 threats and ~14 controls stated at framework level, the reader is left to do the mapping — the same defect ATLAS avoids by mapping mitigations per technique.
Related pages
- maestro-framework — the source page, provenance and method
- maestro-asi-crosswalk — these layers against the OWASP ASI component model
- threat-modeling-frameworks — the frameworks MAESTRO argues are insufficient
- agent-observability-and-logging — the Layer 5 audit trail, implemented
- agentic-threat-taxonomy — T1–T17
- Control catalogue — cross-framework control view