In June, Google DeepMind did something unusual: it published an AI control roadmap premised on the idea that its own AI agents might turn against it.
The AI Control Roadmap treats advanced internal agents as potential insider threats — the way a company treats a rogue employee who already has badge access. It builds on MITRE ATT&CK with a new taxonomy, TRAIT&R (Taxonomy of Rogue AI Tactics and Routines), covering loss of control, work sabotage, and direct harm. And it sequences defenses on two capability ladders: D1–D4 for detection (scaling with the agent’s ability to evade oversight) and R1–R3 for prevention and response (scaling with the severity of what the agent could do).
It’s genuinely good. The insider-threat framing is the right mental model. The capability ladders are a real advance over static control checklists. And it’s empirically grounded — the team analyzed roughly a million coding-agent trajectories, and found that most anomalies came from over-eagerness and misinterpretation, not malice.
But it can be improved. The roadmap organizes what the attacker does (TRAIT&R) and how hard the attacker is to stop (the D/R ladders). It never systematically answers where — where in the system a threat originates, which trust boundaries it crosses, who owns the control at each boundary, and what evidence proves the chain was broken.
That “where” is exactly what the Cloud Security Alliance’s MAESTRO framework provides. And the roadmap needs it.
MAESTRO (Multi-Agent Environment, Security, Threat, Risk, and Outcome), published by CSA in February 2025, decomposes any agentic system into seven layers:
1.Foundation Models — the models doing the reasoning
2.Data Operations — retrieval, memory, embeddings, corpora
3.Agent Frameworks — planners, tools, orchestrators, policy hooks
4.Deployment & Infrastructure — compute, containers, networks, secrets, sandboxes
5.Evaluation & Observability — traces, monitors, telemetry, alerting
6.Security & Compliance — identity, policy, audit, governance (vertical; cuts across all layers)
7.Agent Ecosystem — peer agents, registries, marketplaces, A2A/MCP-style exchanges
Figure 1 illustrates the MAESTRO reference architecture, decomposing an agentic system into seven distinct operational layers alongside an orthogonal security and governance plane. Treating an agent as an undifferentiated system obscures where trust boundaries fail. In this layered decomposition, each tier isolates specific operational responsibilities: base inference and fine-tuned adapters at Layer 1 (Foundation Models), retrieval pipelines and persistent memory at Layer 2 (Data Operations), reasoning planners and tool execution hooks at Layer 3 (Agent Frameworks), compute runtimes and container sandboxes at Layer 4 (Deployment & Infrastructure), runtime telemetry and automated evaluation at Layer 5 (Evaluation & Observability), governance policy and audit logging at Layer 6 (Security & Compliance), and inter-agent communication channels at Layer 7 (Agent Ecosystem). Threats materialize not as isolated component exploits, but as traversals across these architectural seams—such as untrusted content entering via Layer 2 retrieval, manipulating task planning at Layer 3, triggering unauthorized external API execution at Layer 4, and propagating across peer agents at Layer 7. The CSA companion Agentic AI Red Teaming Guide (with OWASP, 2025) translates these cross-layer threat paths into twelve concrete operational test categories.
Figure 1: The 7 MAESTRO layers
The synthesis is simple. Every defensive obligation should be a tuple:
control = (behavior, capability, architecture)
TRAIT&R answers: what is the attacker trying to do? The D/R ladders answer: how capable is the agent at hiding or executing? MAESTRO answers: where does the risk enter, propagate, and terminate?
Without the third axis, the same mitigation means different things at different layers — and “implemented” becomes a checkbox. An agent framework may expose a tool allow-list while the runtime still grants broad cloud credentials. A monitor may score every trajectory while a peer-agent side channel goes unlogged. A shutdown API may exist while the inventory can’t enumerate spawned instances.
The integration rule: no roadmap mitigation should be considered complete until every relevant MAESTRO layer has an enforcement point, an evidence source, and a tested failure response.
Figure 2 illustrates the three-dimensional control model, synthesizing adversary behavior, defensive capability, and architectural topology into a unified operational space. In this model, every control requirement is represented as a coordinate in a discrete 3D space: adversary objectives categorized under TRAIT&R along the behavioral axis (loss of control, work sabotage, and direct harm), defensive maturity defined by the detection (D1–D4) and response (R1–R3) capability ladders, and architectural location pinpointed across MAESTRO Layers 1 through 7. As shown in the diagram, a single cell in this coordinate space—such as deploying an output monitor at Layer 5 capable of D3 detection against work sabotage—defines an exact engineering specification. By anchoring capability requirements to specific architectural layers, engineering teams prevent checklist fallacies where a high-level mitigation at the framework layer leaves underlying runtime environments or inter-agent communication channels exposed.
Figure 2: The 3D control model — behavior × capability × architecture
1.Memory is an ungoverned persistence layer (L2). The roadmap recognizes long-term memory as a risk amplifier but doesn’t specify data-lifecycle controls. Agent memory carries instructions, credentials, and plans across sessions — a poisoned write can sit dormant, activate only in later context, and spread when another agent retrieves it. MAESTRO’s prescription: provenance-tag every memory entry, enforce TTLs, separate tool observations from instructions, and test that a memory reset actually purges poisoned state from indexes, caches, and peer stores — not just the session.
2.The supervisor is a single point of failure (L5). The entire detection story rests on “trusted” AI monitors. But checker-out-of-the-loop is one of CSA’s twelve threat categories, and tool poisoning has been shown to evade output-based safety checks in the vast majority of cases. Monitors need documented independence: a different model family, raw event access (not agent-authored summaries), isolation from the acting agent, and a fallback signal. A high-consequence action should never be authorized solely by a monitor whose evidence the acting agent can modify.
3.Multi-agent trust is under-modeled (L7). The control loop is one worker plus one supervisor. But agents now discover peers, delegate tasks, share memory, and cross organizational boundaries. The security question stops being “can this agent act?” and becomes “which claims about this agent should another agent trust?” The roadmap needs explicit delegation semantics: non-transitive grants, signed lineage, depth and expiry limits — and cascading revocation, so killing a parent actually kills its descendants’ authority.
4.The metrics can hide catastrophic gaps (L5). Coverage, recall, and time-to-response are necessary but insufficient. One headline coverage percentage can hide zero coverage of a rare, catastrophic action. The fix: report coverage by layer, action class, and risk tier; measure time-to-contain and time-to-revoke separately from time-to-alert; track residual autonomy after shutdown. Every percentage must publish its denominator.
Figure 3 diagrams how an attack path traverses multiple architectural boundaries while remaining undetected by isolated, single-layer security controls. In this four-stage exploit sequence, poisoned records written to persistent memory at Layer 2 satisfy local input schemas and bypass static storage filters. When subsequent user requests retrieve this context, the poisoned instructions steer the foundation model’s reasoning at Layer 1 without employing flagged prompt-injection keywords. Guided by this contaminated plan, the orchestration framework at Layer 3 invokes a privileged tool using valid syntax and authorized credentials, which the runtime environment at Layer 4 executes as an approved system call, producing an irreversible side effect. Because each atomic operation falls within normal operational parameters, every isolated component-level monitor registers a successful, benign execution. Detecting and disrupting such attacks requires cross-layer trajectory tracking that correlates the initial data mutation at Layer 2 through model planning, tool dispatch, and runtime execution.
Figure 3: One attack, four layers — zero single-layer detections
For the roadmap’s next version:
1.Tag everything with MAESTRO layers — every TRAIT&R technique, mitigation, test, and incident gets entry/path/target layer metadata.
2.Define control completeness by path — enforcement, evidence, containment, and recovery at each relevant seam.
3.Expand the metrics — precision, authoritative-action coverage, trace completeness, time-to-contain/revoke, rollback success.
4.Make memory a named control domain — ingest, retrieve, write, share, revoke, recover.
5.Specify delegation semantics — non-expanding authority, lineage, expiry, cascading revocation.
6.Require monitor independence — documented model/data overlap, raw evidence, isolation, fallback.
7.Adopt the twelve CSA red-team categories as a minimum operational test catalog, mapped to TRAIT&R and D/R levels.
8.Publish an assurance profile per level — owner, scope, evidence, change invalidation, degraded mode, exception policy, recovery proof.
None of this displaces the roadmap’s core logic. Keep TRAIT&R. Keep the D/R ladders. Add MAESTRO as the architecture axis that tells teams where controls must live, which trust boundaries attacks cross, and what evidence proves containment.
If the roadmap adopts one sentence, make it this:
“The AI Control Roadmap uses TRAIT&R to describe adversary behavior, D1–D4 and R1–R3 to scale controls with capability, and MAESTRO to map architectural origin, propagation, ownership, and evidence.”
Behavior explains the attack. Capability explains the escalation. Architecture explains where control must hold.
The previous explains the idea. This section builds a playbook that youc an use. By the end, you will have a MAESTRO-tagged control graph for your own agent system — the thing that turns the roadmap’s two axes into three.
Get your team in a room (or a doc). List every component of your agent system — models, prompts, vector DBs, tools, sandboxes, monitors, the works — and assign each to exactly one MAESTRO layer. If a component spans two layers, split it: the boundary is where attacks cross.
Worked example — a coding agent (IDE extension plus cloud runner):
•L1: the code LLM plus its fine-tuned adapter
•L2: the repo index, embedding store, conversation memory
•L3: the planner, tool definitions (file edit, shell exec, PR creation), delegation to sub-agents
•L4: the cloud sandbox, container isolation, network egress policy
•L5: trajectory logging, the output monitor, your eval suite
•L6: the audit log, access policies, compliance evidence collection
•L7: the marketplace of shared sub-agents and MCP servers you consume
The output is a one-page layer map. You will use it in every step below.
A PDF crosswalk is useful for discussion. A machine-readable schema is what lets your red team, your SIEM, and your governance docs query the same control graph. Tag every control and every test with this record:
{
“id”: “control.example.017”,
“traitr”: [”memory-context-manipulation”],
“csa_test_categories”: [”Memory & Context Manipulation”],
“capability”: {”detect”: “D3”, “respond”: “R2”},
“maestro”: {
“entry”: “L2”,
“path”: [”L2”, “L1”, “L3”, “L4”],
“governance”: [”L6”],
“ecosystem”: false
},
“asset”: “protected-code-repository”,
“action”: “write”,
“enforcement_points”: [”tool-policy-proxy”, “workload-identity”],
“evidence”: [”retrieval-provenance”, “policy-decision”, “cloud-audit”],
“response”: [”block”, “quarantine-memory”, “revoke-session”],
“owners”: [”agent-platform”, “security-operations”],
“tests”: [”eval.case.442”],
“status”: “implemented”
}
Field notes for builders:
•maestro.path is the cross-layer attack path this control interrupts — the single most important field. A control with no path is a control you cannot compose.
•capability pins the roadmap ladder: which detection level (D1–D4) and response level (R1–R3) this control is evidence for. Do not claim D3 with D1 evidence.
•evidence lists the telemetry an auditor (or your future self) needs to verify the control fired. If you cannot name the evidence, the control does not exist yet.
•response must include recovery, not just blocking — quarantine, revoke, roll back.
Start with 10 records covering your highest-risk actions. Grow the graph from there.
Figure 4 illustrates the machine-readable schema for a MAESTRO-tagged control event, providing an auditable data structure that integrates red-team findings, SIEM detection rules, and compliance records. The schema organizes telemetry into six core modules: adversary taxonomy (identifying the specific TRAIT&R tactic and CSA test family), architectural mapping (recording entry points, cross-layer propagation paths, and governance boundaries), capability ratings (scoring detection and response maturity), enforcement targets (binding policies to specific assets and proxy mechanisms), evidentiary records (specifying required audit logs and recovery responses), and operational ownership. By structuring controls around explicit cross-layer propagation paths (such as L2 → L1 → L3 → L4) and verifiable recovery actions—including memory quarantine and credential invalidation—this format enables automated security pipelines to validate whether defensive coverage exists across the entire lifecycle of an attack.
Figure 4: The MAESTRO event schema
The CSA/OWASP Agentic AI Red Teaming Guide gives you twelve test families. For each: the primary MAESTRO layers, the roadmap level it exercises, and the test to run.
1.Agent Authorization and Control Hijacking — L3, L4, L6, L7 — R2–R3 — attempt parameter escalation, identity substitution, and policy-version rollback through delegation.
2.Checker-Out-of-the-Loop — L3, L5, L6 — D2–D4; R2 — suppress, delay, spoof, or overload the checker; verify fail-closed behavior and an independent path to intervention.
3.Agent Critical System Interaction — L3, L4, L6, L7 — R2–R3 — exercise irreversible operations, timing hazards, stale state, emergency stop, and recovery under degraded connectivity.
4.Goal and Instruction Manipulation — L1, L2, L3, L7 — D1–D3 — inject direct, indirect, delayed, cross-agent, and multi-turn instructions while preserving benign task pressure.
5.Hallucination Exploitation — L1, L2, L3, L5 — D1–D3; R1–R2 — induce unsupported claims that become tool parameters; require provenance or block action when evidence is inadequate.
6.Impact Chain and Blast Radius — all layers — R2–R3 — chain individually permitted actions; measure affected assets, downstream agents, durable state, and recovery completeness.
7.Knowledge Base Poisoning — L2, L5, L6 — D2–D3; R2 — insert provenance-poor content, trigger delayed retrieval, identify consumers, revoke derived embeddings, restore clean state.
8.Memory and Context M…
