Threat Modeling Agents with MAESTRO: The Danger Is in the Hops, Not the Boxes

MAESTRO — Multi-Agent Environment, Security, Threat, Risk, and Outcome — is the Cloud Security Alliance’s answer, published in February 2025 by Ken Huang. It is a seven-layer decomposition for agentic systems, and I now reach for it by default.

This post is what I wish I had been handed on day one: what it actually is, honestly where it sits against the frameworks you already run, and a complete worked model of a real system, end to end, with the arithmetic shown.

First, why the whiteboard stopped working

STRIDE is a wonderful piece of engineering and I have no interest in burying it. But its power comes from a specific move: it asks what can go wrong with this element, where an element has a fixed type. Processes get all six questions. Data stores cannot be spoofed, because they do not authenticate. Data flows are only at risk in transit. External actors are outside your control.

That taxonomy is the engine. It is also the thing an agent breaks.

Look at one agent from the system we are about to model. It chooses which tool to call and with which arguments, so it is a process. It holds thread state and a memory of past cases, so it is a data store. It carries contract text out of a document store and into a payment decision, so it is a data flow. It authenticates to the ERP as itself, under its own IAM role, so it is an external actor — to the ERP, it is indistinguishable from a third party.

This is the observation Bishop Fox made sharply, and once you have seen it you cannot unsee it. MAESTRO’s whole contribution is to change that unit — from the element to the layer.

What MAESTRO actually is

Seven layers. Six of them stack; the seventh cuts across all the others.

It is worth being precise about what belongs where, because a vague layer is a layer nobody fills in. Each one below carries the question I actually ask in the room, which is more useful than the label.

L1 — Foundation Models. The model you call and everything you have done to it: fine-tunes, adapters, decoding parameters, the system prompt if it is fixed. What does this system inherit from a component whose behaviour it cannot fully specify? The threats are the classical ML ones — adversarial examples, model stealing, backdoors, membership inference, training-time poisoning — plus the one that bites most teams and is not an attack at all: behaviour drifting across model versions, so a routine upgrade silently changes what the system does.

L2 — Data Operations. Everything that holds or moves the facts the agent reasons over: vector stores, RAG pipelines, embedding jobs, fact stores, and any replica you granted it read access to. Which of these can an outsider write to, directly or eventually? Knowledge-base poisoning, exfiltration, tampering. In my experience this is the most consistently under-modelled layer, because teams inspect the store and forget the pipeline that fills it.

L3 — Agent Frameworks. The planner loop, the tool schemas, memory, state, and messages between agents. What can this agent decide, and what can it invoke? Goal manipulation, tool misuse, framework evasion. Most of the design decisions worth arguing about live here, and so does the single most important line in the system: the boundary between what the model proposes and what code decides.

L4 — Deployment and Infrastructure. Clusters, containers, IAM roles, networking, egress. If this agent is fully compromised, where can it reach? Resource hijacking, lateral movement, IaC tampering. Much of this is ordinary cloud security, and saying so out loud is the point — it lets your existing controls carry the weight instead of being reinvented with “AI” in the title.

L5 — Evaluation and Observability. Traces, evals, drift dashboards, the action log. After an incident, can you reconstruct what was done and on whose authority? Metric manipulation, evasion of detection, and leakage through telemetry — an observability stack is a copy of your data with weaker access control and a longer retention period.

L6 — Security and Compliance. Identity, authorisation, the policy gate, separation of duties, audit evidence, residency, and any agent you run as a control. Which of these is a constraint, and which is a promise? It is drawn vertically because it has to hold while every other layer moves.

L7 — Agent Ecosystem. Registries, marketplaces, other agents, external counterparties, and the humans. Whose decisions does this system trust, and how would you know if one of them changed? Impersonation, tool squatting, compromised registries, malicious agent discovery. This is where agentic systems diverge most sharply from anything a classical framework describes, because most of these threats have no pre-agentic equivalent at all.

The fastest way to see that these are real categories rather than a taxonomy for its own sake is to instantiate them twice, on two systems that share nothing.

That second column is the useful half. On a hosted API you own almost nothing at L1 or L4 — and the layers do not disappear just because someone else operates them. They become inherited risk with a named owner outside your organisation, which is a different answer from “not applicable” and should be written down differently.

The second idea is the one that earns its keep, and it is easy to skim past. Every layer carries two classes of threat:

• Traditional threats, inherent to that layer’s technology and entirely independent of anything agentic. A vector database has the security properties of a database.
• Agentic threats, which are either genuinely novel or are ordinary threats made worse by three properties: non-determinism, autonomy, and the absence of a trust boundary between a component that reasons and a component that acts.

That split is what stops these sessions degenerating into AI theatre. Half of what you find at L4 is just infrastructure security, and naming it as such lets your existing controls take the weight instead of being redesigned in the name of AI.

How it sits against what you already run

Here is where I want to be careful, because the framing “MAESTRO replaces STRIDE” is both common and wrong, and adopting it will cost you a good tool.

The distinction that matters most in practice is between structure and content.

MAESTRO gives you structure. It tells you where to look — which layers exist, which interfaces between them are load-bearing, and which questions belong at which altitude. What it does not give you is a catalogue of what to look for. Its per-layer threat lists are illustrative, not exhaustive, and treating them as a checklist is the most common way I see the framework misused.

The OWASP Agentic Security Initiative catalogue is the reverse: fifteen named threats, T1 through T15, with real specificity — memory poisoning, tool misuse, privilege compromise, intent breaking and goal manipulation, repudiation and untraceability, rogue agents in multi-agent systems. No structure, but excellent content.

And MITRE ATLAS is neither. It is a record of what adversaries have actually done to real AI systems, which is the only one of the three that can tell you whether a threat you have imagined has ever happened to anybody.

The method, in six steps

Decompose across the layers. Find threats within each layer. Find threats between layers. Score them. Plan mitigations. Monitor, and reopen when the system changes.

Step three is the one that justifies the whole framework, and step three is the one teams skip. So let us do all six on something real.

The worked example: an invoice exception desk

Not a chatbot, not a demo. A system of the kind that actually gets built: a multi-agent desk at a mid-sized manufacturer that clears supplier invoice exceptions — price mismatches, quantity mismatches, a missing purchase order.

It is unglamorous, nobody will present it at a conference, and it can move money.

Step 1 — Decompose

Tag every component with its layer. This takes twenty minutes and it is not busywork: the argument about which layer something belongs to is usually an argument about who owns it, which is exactly the argument you want to have early.

• L1 — one hosted foundation model, no fine-tune, version and temperature pinned.
• L2 — a vector store of supplier contracts ingested from the document management system, and a read-only ERP replica for price history.
• L3 — the orchestrator, three specialist agents, the tool schemas, and per-thread memory.
• L4 — EKS, one MCP server pod per tool, an IAM role per agent, an egress proxy.
• L5 — OpenTelemetry traces into the SIEM, an action log, and 200 historical exceptions as an eval set.
• L6 — the deterministic policy gate, IAM, separation of duties, and the audit evidence the external auditors will ask for.
• L7 — the supplier portal, the AP clerk queue, the downstream payment run.

Step 2 — Threats within each layer

Now walk the layers with the OWASP catalogue in your other hand. The discipline that makes this useful: write each threat as a failure in this system, never as a category name. “Tool misuse” teaches nobody anything. “The history agent’s read-only SQL role can read the full vendor master, including bank details” starts a conversation that ends in a smaller IAM policy.

A sample of what this produces here:

• L1 — the model’s price-variance reasoning is unstable across versions, so a routine model upgrade silently changes what gets auto-posted. This is not an attack, and it is the one most likely to bite you.
• L2 — contract chunks carry no provenance. A clause retrieved from an attacker-supplied amendment is indistinguishable from one in the signed master agreement. (OWASP T1)
• L3 — the planner concatenates retrieved contract text into the same channel as its instructions, so a document can issue commands. (T6, intent breaking and goal manipulation)
• L4 — every MCP server pod shares one IAM role, so compromising the cheapest tool yields the most privileged one. (T3, privilege compromise)
• L5 — the action log records the tool call and the amount, but not which clause authorised it. (T8, repudiation and untraceability)
• L6 — the gate’s threshold is evaluated per invoice, with no cumulative term.
• L7 — the supplier portal accepts contract amendments from any authenticated supplier, and “authenticated supplier” includes a compromised one.

Each of those is individually mundane. Several are arguably not even bugs. Hold that thought.

Step 3 — The chain between the layers

This is the step that pays for the framework, and it is the step a per-layer review structurally cannot perform. Individually, nothing above is alarming. Chained, they are a payment.

Trace it once more slowly, because the shape is the lesson. A supplier — or someone who has taken over a supplier’s portal account — uploads a contract amendment. The ingestion pipeline embeds it alongside the signed master agreement, because the pipeline has no concept of who wrote a clause. The contract agent retrieves it as the governing text, because retrieval ranks by relevance and relevance is not provenance. The planner reads it as instruction rather than data, and the amendment states that the permitted price variance is 40%. The gate checks its three conditions — under ¥500,000, a contract clause cited, variance within the cited limit — and all three are green. Payment posts.

MAESTRO names four classes of these: supply chain, lateral movement, privilege escalation, and data leakage, plus what it calls goal misalignment cascades, where a misaligned goal propagates between agents through ordinary interaction. This one is a supply-chain threat that becomes a privilege escalation without any privilege ever being escalated.

The number nobody wrote down

There is a second defect in that gate, and I find it in this shape constantly, so it deserves its own figure.

The threshold is per invoice. The blast radius is per period. Every one of those forty postings obeys the rule; nobody ever approved ¥19.96M, because nobody ever computed it.

A per-transaction limit with no cumulative term is a rate limit with the rate left blank. If you take one operational thing from this post, make it that — and go and check the gates you already have in production, because I would bet on what you find.

Step 4 — Risk, scored honestly

One of the few published end-to-end applications of MAESTRO — Zambare, Thanikella and Liu’s threat model of a network monitoring agent — scores with R = P × I × E: likelihood, impact and exploitability on a three-point ordinal scale. For our chain that gives likelihood medium (2), impact high (3), exploitability high (3) — 18 out of a possible 27, and a comfortable top-of-list position.

That same paper scores ten threats against its own system, and the ranking it produces is worth sitting with for a moment.

The highest score on the board is infrastructure DoS. Not a jailbreak, not a poisoned embedding — resource exhaustion at L4, the most boring entry in the catalogue, because it is the one that is simultaneously likely, damaging and trivial to attempt. I keep that figure to hand for the meeting where someone proposes rebuilding the platform around a novel AI threat while the rate limits remain unconfigured.

Now the caveat I always give aloud, because otherwise the number acquires an authority it has not earned: multiplying ordinals is not arithmetic. The distance from Low to Medium is not the distance from Medium to High, and nothing entitles you to multiply them. The score is a sorting device for a conversation, not a measurement.

I use it anyway, and I say that sentence every time. What earns the ranking is the argument in the room, not the product of three guesses.

Step 5 — Mitigations, mapped to layers

The chain breaks at every hop, which means you get to choose where to spend. That is the practical gift of doing step three properly.

• L2 — provenance as a first-class field. Every chunk carries its source, signer, and document status. Retrieval filters on it. This one change alone breaks the chain at hop 3, and it is the cheapest control on the list.
• L3 — retrieved content never enters the instruction channel. Contract text arrives as quoted evidence with a provenance envelope, not as prose the planner can act on. This is the prompt-is-a-promise, tool-interface-is-a-constraint distinction I wrote about in the coach post, applied to retrieval.
• L6 — the gate reads provenance, and carries a cumulative term. Only clauses from countersigned master agreements may set a limit. Per-supplier, per-period exposure becomes a condition, not a report.
• L5 — the action log records the authority, not just the action. Which clause, from which document, at which version, permitted this posting. Without it you cannot answer the only question that matters after the fact.
• L4 — one IAM role per MCP server, so that the blast radius of the cheapest tool is the cheapest tool.
• L1 — pin the model version and gate upgrades on the eval set. Those 200 historical exceptions exist precisely so that a model change is a measurable event rather than a surprise.

Notice how few of these are AI controls. Provenance, least privilege, a decent audit record, a cumulative limit — this is largely the security engineering we have done for thirty years, applied at a place we would not have thought to look without the decomposition.

Step 6 — Monitor, and the trigger to reopen

Two things to alert on here: postings where the citing clause came from a document uploaded in the last N days, and cumulative per-supplier exposure crossing a fraction of the period budget. Both are cheap. Neither would have existed without step three.

And the reopening trigger, written down in the model itself: a new tool, a new agent, a model version change, or a new external counterparty. Any of those and the model is stale. This is the same argument I made about security controls needing to live in a sensor rather than a paragraph — a threat model that is not wired to a trigger is a document, and documents rot.

Where MAESTRO costs you

A framework without a bill is marketing, so here is the bill.

Seven layers invite completeness theatre. Give a team a seven-row template and they will fill all seven rows, including the ones where the honest answer is “inherited from the platform, no system-specific threats”. I now explicitly bless empty layers in the first ten minutes.

Layer assignment is genuinely ambiguous, and the debate is a time sink. Is agent memory L2 or L3? You can argue it both ways for forty minutes. The answer that saves the session is that it does not matter, provided it lands somewhere and has an owner. Timebox it.

There is no empirical validation I can find. No published detection rates, no before-and-after data, no head-to-head against STRIDE on the same system. Published applications of it are still counted in single digits. I use MAESTRO because the decomposition matches how these systems actually fail in front of me, which is evidence of a weaker kind than I would like, and I will say so to anyone who asks whether it is proven.

It has no content of its own. Arrive without a threat catalogue and you will produce a tidy seven-layer diagram containing nothing.

And it is too much machinery for small systems. A read-only internal agent over non-sensitive data, with a blast radius you can state in one line, does not need seven layers. Use the four patterns, write the blast radius down, and go home. Applying MAESTRO there is theatre, and theatre teaches engineers that security advice does not distinguish between cases.

How I actually run the session

Ninety minutes, once, with the right six people; not a document produced in isolation and circulated for comment.

In the room: the engineer who wired the tools, the person who owns the data store, someone from the platform team, the business owner who can say what an incorrect payment actually costs, and a scribe who is not me. I facilitate and I do not fill in the threats — the same reason I gave in the coach post: nobody argues about a mitigation for a threat they identified themselves.

The running order: twenty minutes tagging components onto layers, forty minutes on per-layer threats written as failures in this system, twenty minutes — protected, the first thing to be eaten otherwise — on chains between layers, ten minutes ranking out loud.

You will know it worked by a specific signal. Somebody in the room will say “wait, can that actually reach the gate?” and stop talking mid-sentence. That is step three landing, and it is worth the whole ninety minutes.

What you hand over afterwards

The question I get most often is not about layers. It is “so what does the output actually look like?” — and MAESTRO does not answer it, which is a real gap. Here is the answer I have converged on.

The output is not a document. It is six artefacts with three different lifetimes, and the mistake almost everyone makes is putting all six in the same place, at the same cadence, for the same audience.

Three of them belong in the repository that holds the system, as Markdown, reviewed in pull requests: the layer inventory, the threat register and the chain register. If a threat model cannot be diffed alongside the change that invalidates it, it will be out of date before the next release — and it will be out of date silently, which is worse than being absent.

The control map belongs with the code, and its last column is the one that matters: the test that proves this control operates. I have written before about a control that existed, was reviewed, and had never once taken effect; the column exists so that cannot happen quietly. A mitigation with no test is an intention.

The decision log belongs with governance, and every row carries an expiry date. An accepted risk with no expiry is not an acceptance — it is a way of ending the conversation. On expiry it returns to the register and someone has to accept it again, on purpose.

And the reopen triggers live inside the model itself, wired to something that fires: a CODEOWNERS rule, a pipeline check, an issue template. A new tool, a new agent, a model version change, a new external counterparty.

One deliberate omission: there is no executive summary in that list. If leadership needs one, it is generated from the register and the decision log and it is one page, and it is regenerated rather than maintained. Every threat model I have seen die was killed by the effort of keeping a presentation layer in sync with a working document.

What I think it is for

MAESTRO will not tell you anything your best engineers could not have worked out. What it does is make sure the question gets asked at all, in a room where the person who knows the answer happens to be present.

That is not a small thing. Most of the agentic incidents I expect to read about over the next two years will not involve a clever attack on a model. They will look like the chain above: six reasonable components, every control switched on and working to specification, and nobody who ever looked at the whole path.

The map does not find the threat. It just puts you in the right place to notice it — and after two years of whiteboards full of identical boxes, I will take that gladly.

Sources, and what each is good for

Everything above is drawn from public material. Annotated, because a bare bibliography is not much of a gift.

• Agentic AI Threat Modeling Framework: MAESTRO — Ken Huang, Cloud Security Alliance, February 2025. The primary source and the only one you must read. The seven layers, the two threat classes, the six-step method and the cross-layer categories all come from here.
• Threat Modeling OpenAI’s Responses API with MAESTRO — CSA, March 2025. The most useful thing published about MAESTRO after the framework itself: the layers instantiated against a real API, parameter by parameter. It is the right-hand column of the instantiation figure above.
• Agentic AI Threats and Mitigations — OWASP Agentic Security Initiative. The T1–T15 catalogue. This is the content that MAESTRO’s structure needs; bring it to the session.
• MITRE ATLAS — the record of techniques actually observed against real AI systems. The only source here that can tell you whether a threat you have imagined has ever happened.
• Taking MAESTRO in Stride — Bishop Fox. The sharpest published comparison with STRIDE, and the origin of the observation that an agent is simultaneously a process, a data store, a data flow and an actor. It argues for blending frameworks rather than choosing, and it is right.
• Securing Agentic AI: Threat Modeling and Risk Analysis for Network Monitoring Agentic AI System — Zambare, Thanikella & Liu, arXiv:2508.10043, CC BY 4.0. The most complete published end-to-end application of MAESTRO I have found, including the scoring scale and the risk matrix reproduced above.
• MAESTRO Threat Analyzer — CSA’s own LLM-backed tool that drafts a layered assessment from an architecture description. Explicitly educational rather than an audit instrument, and useful mostly as a way to see the framework’s own shape.
• MAESTRO: Layered Threat Modeling for Agentic AI Ecosystems — Snyk Labs. A second independent walkthrough, with a multi-agent trading example.

I write about this work as it develops. If you are modelling one of these systems and want a second pair of eyes, I am reachable on LinkedIn, and the tooling I maintain lives under shenril and BlueSquadron.