AWS gives builders strong agent controls, but no single AWS control covers an agent end to end. CSA MAESTRO, published in February 2025, gives us 7 layers for agent threats(for full disclosure, I am the creator of the MAESTRO methodology).
AWS AgentCore Policy reached general availability on 3 March 2026. GuardDuty AI Protection offers exactly 3 finding types. We map each AWS control to the layer it actually covers. We name each gap AWS leaves to the customer. We show where an attack chain breaks. We argue one thesis. An agent is secure only when a control outside the model checks each consequential action, an identity trail names who acted, and a log record proves what happened. In the upcoming weeks, we will do the mapping for Microsoft, Google, and other companies every Monday. If you want your company featured here and sponsor our research, please reach out to us via email using the info at distributedapps.ai.
If you are subscribers to this newsletter, we suggest you get a yearly paid plan to get the most up-to-date analysis on agentic AI and Agentic Security. I plan to write an article on how I grew my Substack subscribers from 1 to 132k. Comment below if you have some questions to ask about growth strategy, and I will be sure to cover it in my upcoming article.
Figure 1 is the full MAESTRO stack with the main AWS control on each layer.
Figure 1: Each MAESTRO layer carries one main AWS control set. L6 cuts across all layers. No layer alone secures an agent.
We use MAESTRO as a threat map, not as a control list. MAESTRO does not certify a product. MAESTRO shows where a threat starts, how the threat moves across layers, and where a control must stop the threat. AWS supplies the controls. We, as architects, must place each control on the correct layer, route traffic through each control, and test each gap that remains. Routing decides coverage. A control that traffic never reaches cannot protect an agent.
MAESTRO gives 7 layers. L1 is Foundation Models. L2 is Data Operations. L3 is Agent Frameworks. L4 is Deployment and Infrastructure. L5 is Evaluation and Observability. L6 is Security and Compliance, and L6 cuts across all other layers. L7 is Agent Ecosystem. Each layer names a different threat class. Each layer needs a different control. A team that checks only the model misses the tool. A team that checks only the tool misses the data. A team that checks only data misses identity. The paid section follows that order, layer by layer, so a reader can audit one layer at a time.
Routing is the second idea in this article. Gateway Policy covers routed calls only. Guardrails cover attached calls and scored calls only. Registry covers registered records only. Logging covers enabled resources only. A reader who remembers that rule can read every paid section with one test in mind. The test is simple. Did traffic actually pass through the control? If traffic did not pass through the control, the control gives no protection, even if the control is configured correctly elsewhere.
L1 Foundation Models — the stake is model output. A model can follow a harmful instruction with fluent, confident text. Output alone never proves safety. The paid L1 section states what Guardrails scores, what Guardrails blocks, and what stays with the customer.
L2 Data Operations — the stake is retrieved text. A document, a memory record, or a tool result can carry an instruction. Retrieval turns untrusted text into model context. The paid L2 section states what Knowledge Bases cite, what Memory encrypts, and what no AWS control validates.
L3 Agent Frameworks — the stake is tool action. A plan becomes real impact only when a tool runs. Tool permission decides that impact. The paid L3 section states where Cedar enforces, where Cedar cannot enforce, and where a bypass path remains.
L4 Deployment and Infrastructure — the stake is runtime privilege. An agent process runs with credentials. Those credentials decide lateral movement. The paid L4 section states how PrivateLink, microVM isolation, and execution-role scope fit together.
L5 Evaluation and Observability — the stake is proof. Traces, logs, and evaluations show what an agent did and why. Missing logs remove that proof. The paid L5 section states which logs need explicit enablement and which findings are detective only.
L6 Security and Compliance — the stake is identity separation. User identity, agent identity, and tool identity must stay distinct. One shared role hides who acted. The paid L6 section states the identity pattern and the governance process that must sit around it.
L7 Agent Ecosystem — the stake is peer trust. A peer agent or a tool server needs vetting, registration, and scoped credentials. Registration alone never proves trust. The paid L7 section states what Registry does, what Registry does not do, and where peer trust remains unbuilt.
Five cross-layer attack chains — the stake is the chain, not one step. Each chain shows the step where a control breaks it, and the step where a gap lets it pass. The paid chain section gives a test for each chain in a reader's own environment.
Builder playbook and reference architecture — the stake is reuse. The playbook gives a copy-ready Cedar example, a logging checklist, and an enforcement pattern teams can apply on day one. The architecture section splits enforcement into Reasoning, Action, and Governance and Telemetry.
Start a review with routing. List every tool the agent can call. Mark each tool as Gateway-routed or not Gateway-routed. Mark each Guardrails check as attached, called at a loop point, or absent. Mark each log source as enabled or not enabled. A review that skips that inventory cannot judge coverage. A review that completes that inventory can see the gaps before it reads any policy text.
Continue a review with identity. List the user, the agent, and each tool as separate identities. Check whether downstream systems see the user, the agent, or only a shared role. Check whether a destructive action needs human approval, or whether a policy alone authorises the action. Check whether an agent policy has an owner and a review date. An identity review that finds one shared role has found a real finding, not a paperwork issue.
Finish a review with a chain test. Pick one chain from the paid section. Run the chain in a test environment with test data. Record the step where a control stopped the chain. Record the step where no control ran. A chain test gives a team evidence, not an opinion. A chain test also gives a team a repeatable check for the next release.
The paid section maps each layer in turn. The paid section gives the five attack chains, the control gaps, the three-part reference architecture, and the builder playbook. The paid section keeps every claim tied to a primary source. The paid section drops any claim we could not source. The paid section also names each preview limit that affects a production decision. A reader must not place a preview control on a critical path without knowing the limit. The paid section also states, plainly, where AWS offers no native control at all. Those gaps are not a criticism of one product. Those gaps are the work a team must plan, fund, and own. A team that plans that work early ships a safer agent. A team that discovers that work after launch ships a delay. A reader who wants only the map can stop at Figure 1 and the roadmap below. The roadmap below lists each paid section in reading order, with the stake that section answers and the control that section examines in detail. A reader who wants the enforcement detail can read the paid section in order, or jump to the layer that owns their current risk.
