Map the OWASP Top 10 for Agentic Applications to cloud controls

What the list covers and where controls stop

Cloud controls cover the OWASP agentic risks unevenly. Amazon Bedrock AgentCore, Microsoft Foundry Agent Service and Gemini Enterprise Agent Platform all document enforceable controls for tool misuse (ASI02), identity and privilege abuse (ASI03) and unexpected code execution (ASI05): per-agent identities, a policy checkpoint in front of tool calls, and sandboxes that isolate generated code. Supply chain (ASI04), inter-agent communication (ASI07), cascading failures (ASI08) and rogue agents (ASI10) get partial coverage from registries, authenticated agent endpoints, rate limits, detection and a way to disable an agent. Agent goal hijack (ASI01) and memory and context poisoning (ASI06) get classifiers and storage isolation, which narrow the problem without settling it. Human-agent trust exploitation (ASI09) has no infrastructure control at all. ^[1]

The OWASP GenAI Security Project released the list on December 9, 2025, as the Top 10 for Agentic Applications for 2026, built with more than 100 contributors. Each entry gives a description, common examples, attack scenarios and mitigations. The document asks teams to apply Least Agency as well as least privilege: avoid autonomy where it adds no value, because every unnecessary degree of freedom widens the attack surface. It also treats observability as mandatory, since teams cannot contain agents whose tool calls and reasoning they cannot see. ^[1]

This guide maps each risk to controls that AWS, Microsoft and Google document for their managed agent platforms, using documentation reviewed on October 7, 2026. Where a provider documents nothing that addresses a risk, the mapping says so rather than stretching an adjacent feature to fit. Product status matters here, because several of the controls below are in preview, and a preview control is a weaker basis for a security commitment than a generally available one.

Source. Conceptual mapping by the editors from OWASP and provider documentation. ^{[1][5][10][11][12][13][15][16][18][20][21][23][24][25][26][27][28][31][32][33][34][35][36][37][38][39]}

Method. Conceptual mapping. Each cell names a control the provider documents as of October 7, 2026; detect and enforce labels are the editors' classification. Absence means none was found in the reviewed documentation.

Accessible table and figure data

Figure 1 accessible table

Risk	AWS AgentCore	Microsoft Foundry	Google Agent Platform
ASI01 Goal Hijack	Guardrails prompt attack filter; skips tool results (detect)	Indirect attack check on tool responses, preview (detect)	Model Armor and Semantic Governance (detect)
ASI02 Tool Misuse	Policy on Gateway, Cedar, default deny (enforce)	allowed_tools, require_approval, egress rules (enforce)	Agent Gateway IAM egress check, default deny (enforce)
ASI03 Identity and Privilege	Workload identity; vault bound to agent and user	Entra agent identity; on-behalf-of flow	SPIFFE Agent Identity; certificate-bound tokens
ASI04 Supply Chain	Agent Registry approval lifecycle	Versioned toolboxes; no approval workflow found	Agent Registry checked by Gateway
ASI05 Code Execution	MicroVM per session, memory sanitized	Hyper-V sandbox without outbound network	Code Execution sandbox without network
ASI06 Memory Poisoning	Namespace and actor condition keys; screening is yours	Per-user scope, preview; screening is yours	Scope IAM conditions, TTL, revisions
ASI07 Inter-Agent	A2A with SigV4 or OAuth 2.0	A2A requires Entra token and role	A2A preview; mTLS and DPoP
ASI08 Cascading Failures	Temporal policy rate limits	No managed circuit breaker found	Anomaly Detection for loops, preview
ASI09 Human Trust	Approval gate only	Approval gate only	No documented control
ASI10 Rogue Agents	Forbid policy; IAM revocation	Disable identity; Defender, preview	Threat Detection and Anomaly Detection, preview

Figure 1 accessible table

Risk	AWS AgentCore	Microsoft Foundry	Google Agent Platform
ASI01 Goal Hijack	Guardrails prompt attack filter; skips tool results (detect)	Indirect attack check on tool responses, preview (detect)	Model Armor and Semantic Governance (detect)
ASI02 Tool Misuse	Policy on Gateway, Cedar, default deny (enforce)	allowed_tools, require_approval, egress rules (enforce)	Agent Gateway IAM egress check, default deny (enforce)
ASI03 Identity and Privilege	Workload identity; vault bound to agent and user	Entra agent identity; on-behalf-of flow	SPIFFE Agent Identity; certificate-bound tokens
ASI04 Supply Chain	Agent Registry approval lifecycle	Versioned toolboxes; no approval workflow found	Agent Registry checked by Gateway
ASI05 Code Execution	MicroVM per session, memory sanitized	Hyper-V sandbox without outbound network	Code Execution sandbox without network
ASI06 Memory Poisoning	Namespace and actor condition keys; screening is yours	Per-user scope, preview; screening is yours	Scope IAM conditions, TTL, revisions
ASI07 Inter-Agent	A2A with SigV4 or OAuth 2.0	A2A requires Entra token and role	A2A preview; mTLS and DPoP
ASI08 Cascading Failures	Temporal policy rate limits	No managed circuit breaker found	Anomaly Detection for loops, preview
ASI09 Human Trust	Approval gate only	Approval gate only	No documented control
ASI10 Rogue Agents	Forbid policy; IAM revocation	Disable identity; Defender, preview	Threat Detection and Anomaly Detection, preview

Download imageDownload table CSV

How the list relates to the LLM Top 10

The agentic list does not replace the OWASP Top 10 for LLM Applications 2025. It assumes an agent is built on an LLM application and extends the older entries to systems that plan, keep state and act through tools. Appendix A of the agentic document maps every ASI entry to LLM entries, to the threat codes in OWASP's Agentic AI Threats and Mitigations guide and to AIVSS scoring categories. The table below reproduces the LLM column. ^[1][2]

Two boundaries in the text matter for control design. ASI02 covers an agent misusing privileges it legitimately holds; once the misuse involves escalation or inherited credentials it becomes ASI03, and once it produces code execution it becomes ASI05. ASI08 describes propagation, not origin: OWASP says to file the initial defect under ASI04, ASI06 or ASI07 and use ASI08 only when it spreads across agents, sessions or workflows. Those boundaries map neatly onto infrastructure layers, which is why the mapping below works better for some entries than others. ^[1]

How to read the mapping

Every control in the matrix belongs to one of six layers, and the layer tells you how much weight it can bear. Identity, tool authorization and execution isolation are enforcement layers: a request either carries a valid token, passes a policy and runs inside a boundary, or it does not. Content inspection is a detection layer built on classifiers, so it returns a probability that a prompt or tool response contains an attack. Telemetry and response record what happened and let an operator stop it. The last layer, application and process design, holds what no provider configures for you: how the agent decides on goals, what it is allowed to remember, and how a person reviews an action.

A risk is well covered when an enforcement layer can prevent the damaging outcome even if the model is fully compromised. ASI02 qualifies: a policy that permits refunds only below a set amount holds regardless of what the model was persuaded to want. ASI01 does not, because the harm of a hijacked goal is mostly a sequence of individually permitted actions. Read each cell of the matrix with that test in mind and the uneven coverage becomes predictable.

The platforms are not identical, and the names have moved recently. Google announced Gemini Enterprise Agent Platform on April 22, 2026 as the evolution of Vertex AI, and its release notes record that Vertex AI Agent Engine is now Agent Runtime. Microsoft documents its service as Microsoft Foundry Agent Service, and its guardrails page notes that roles formerly called Azure AI User and Azure AI Owner are now Foundry User and Foundry Owner. AWS lists Runtime, Gateway, Identity, Memory, Code Interpreter, Browser, Observability, Policy and Registry among the AgentCore services. ^{[4][19][29][30]}

Source. Conceptual model by the editors, informed by OWASP mitigation guidance and provider documentation. ^{[1][5][12][19][31][32]}

Method. Conceptual layering. Strength describes how a control behaves when the model is manipulated, not product quality: detection is probabilistic, telemetry records and supports response, and the last layer has no provider control.

Accessible table and figure data

Figure 2 accessible table

Layer	Decides	Strength	Examples
Identity and credentials	who the agent is and which tokens it holds	enforces	AgentCore Identity, Entra agent identity, Agent Identity
Tool authorization	which calls pass with which arguments	enforces	AgentCore Policy, Agent Gateway, MCP approvals
Execution and network isolation	where generated code runs and what it reaches	enforces	microVM sessions, Hyper-V sandboxes, egress rules
Content inspection	does text look like an attack	detects	Bedrock Guardrails, Foundry guardrails, Model Armor
Telemetry and response	what ran, how to stop it	records	traces, threat alerts, identity disable
Application and process design	goals, memory, approvals	none	your own design

Figure 2 accessible table

Layer	Decides	Strength	Examples
Identity and credentials	who the agent is and which tokens it holds	enforces	AgentCore Identity, Entra agent identity, Agent Identity
Tool authorization	which calls pass with which arguments	enforces	AgentCore Policy, Agent Gateway, MCP approvals
Execution and network isolation	where generated code runs and what it reaches	enforces	microVM sessions, Hyper-V sandboxes, egress rules
Content inspection	does text look like an attack	detects	Bedrock Guardrails, Foundry guardrails, Model Armor
Telemetry and response	what ran, how to stop it	records	traces, threat alerts, identity disable
Application and process design	goals, memory, approvals	none	your own design

Download imageDownload table CSV

Goal hijack and tool misuse

ASI01 starts from a premise OWASP states plainly: agents and their models cannot reliably tell instructions from content. A web page, an email, a calendar invite or a peer agent's message can redirect the agent's objective. The mitigations OWASP lists split in two. Some reduce the chance of a hijack (treat all natural-language input as untrusted, filter connected data sources, lock system prompts under change control). Others reduce its consequences (least privilege for tools, human approval for goal-changing actions, monitoring for drift from a behavioral baseline). ^[1]

The cloud controls aimed at the first half are classifiers, and their documented scope is narrower than their names suggest. The Amazon Bedrock Guardrails prompt attack filter detects jailbreaks, prompt injection and, on the Standard tier, prompt leakage, but its documentation says it does not evaluate tool results or tool definitions, and that with InvokeModel it filters only input wrapped in guardrail tags. Indirect injection arriving through a tool response therefore passes the filter unless you route that text through it yourself. ^[12]

Microsoft Foundry guardrails, in preview for agents, can scan four intervention points: user input, tool call, tool response and output. With the indirect attack risk set at the tool response point, Foundry scans the full payload each tool returns and stops the agent immediately when it detects an injection. That check depends on moderation support from the tool, and the supported list is Azure AI Search, Azure Functions, OpenAPI, SharePoint Grounding, Fabric Data Agent, Bing Grounding, Bing Custom Search and Browser Automation. MCP servers are not on it. Agents also support only the annotate-and-block action, and an agent's guardrail fully overrides the guardrail of its model deployment. ^[19][20]

Google routes Model Armor through Agent Gateway, where it scans payloads after the identity and registry checks, and adds Semantic Governance, a preview feature that evaluates each proposed tool call against natural-language rules and denies calls that deviate from user intent. Google's own page warns that the underlying models are probabilistic and their verdicts may not be accurate. The same caveat applies to the AWS and Microsoft classifiers above. ^[32][33]

ASI02 is where infrastructure earns its place. OWASP recommends per-tool least-privilege profiles expressed as IAM or authorization policy rather than convention, and a policy enforcement point that treats planner output as untrusted and validates intent and arguments before execution. AgentCore Policy is that enforcement point on AWS. It became generally available on March 3, 2026, intercepts traffic through AgentCore Gateway, evaluates Cedar policies for every tool invocation, and applies default-deny and forbid-wins semantics. Policies can test the tool arguments in context.input and claims from the caller's token. ^[1][5][7][9] Each tool appears as an action named after its gateway target, such as RefundTool___process_refund, and Cedar has no wildcard actions, so related tools are grouped by putting them behind one gateway target. ^[6]

Two operational details decide whether that policy actually holds. A gateway in LOG_ONLY mode evaluates and logs decisions without enforcing them, and anyone holding bedrock-agentcore:UpdateGateway can switch a gateway from ENFORCE to LOG_ONLY or remove its policy engine; AWS documents no separate condition key for the mode field. Treat that permission as part of the control. Second, the policy only sees calls that go through the gateway, so a tool the agent reaches directly from its own code is outside it. ^[8]

Google's equivalent sits on the network path. In Agent-to-Anywhere mode, Agent Gateway has Identity-Aware Proxy check for an IAM policy that grants the agent identity iap.resources.egressViaIAP on the destination, evaluates Principal Access Boundary, then checks Agent Registry, and denies the request when no matching access policy exists. For MCP traffic the gateway parses request data into attributes that policies can test, which allows restrictions by tool. Agent Gateway reached general availability on June 18, 2026. ^[30][32]

Microsoft's controls are spread across the tool configuration. The MCP tool accepts an allowed_tools list, which otherwise defaults to every tool the server exposes, and a require_approval setting whose default is always; the agent then receives an mcp_approval_request and proceeds only after an mcp_approval_response. Microsoft also advises treating tool descriptions, annotations and results from remote MCP servers as untrusted. For toolboxes, the documentation is explicit that the MCP endpoint does not block tools/call and that enforcing approval is entirely the agent runtime's responsibility. Hosted agents add network egress controls in preview, with Allow, Deny, Transform and Rewrite rules, an Audit mode and fail-closed evaluation. ^[21][22][24]

// Example fragment: AgentCore Policy (Cedar) for two hypothetical gateway tools.
// Placeholders only. Each policy names one action and one specific gateway ARN.
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"RefundTool___process_refund",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/example-gateway"
)
when {
  principal.hasTag("scope") &&
  principal.getTag("scope") like "*refund:write*" &&
  context.input.amount < 500
};

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"OrderTool___get_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/example-gateway"
);

Identity and privilege abuse

OWASP locates ASI03 in a mismatch: identity systems were built for users, and an agent without a distinct, governed identity of its own works in an attribution gap where least privilege cannot be enforced. The listed failure modes are un-scoped privilege inheritance when a manager agent delegates, credentials cached in memory and reused by a later user, a low-privilege agent relaying instructions to a high-privilege one, and authorization checked at the start of a workflow but not at the moment of use. The mitigations start with task-scoped, time-bound credentials per agent. ^[1]

All three providers now issue that kind of identity. AgentCore Identity implements agent identities as workload identities so agents authenticate as themselves rather than impersonating users, and its token vault stores OAuth tokens and API keys so they can be retrieved only by the agent and user combination that obtained them. It supports client credentials for machine-to-machine calls and the authorization code grant when the agent needs a user's consent. ^[10]

Microsoft Foundry provisions an agent identity blueprint and agent identities in Microsoft Entra ID. Under the Agent Application publishing model, every unpublished agent in a project shares one project identity; publishing creates a distinct identity, and role assignments made to the shared identity do not carry over. Microsoft calls the shared identity a broader blast radius and recommends publishing an agent that needs tighter controls or its own audit trail. Agents can run attended, through the on-behalf-of flow so they reach only what the user is authorized for, or unattended under their own role assignments. In the Entra admin center, administrators can apply Conditional Access, Identity Protection and governance settings such as owners and expiration to agent identities. In Foundry's newer agent object model, each agent receives its own identity, instance_identity, at creation, and publishing does not change it. ^[18]

Google's Agent Identity gives each deployed agent a SPIFFE ID and an X.509 certificate valid for 24 hours and renewed automatically. The identity appears in IAM allow policies as a principal:// identifier, cannot be impersonated, does not permit long-lived service account keys, and binds its Google Cloud access tokens to the certificate to prevent token theft. Across Agent Gateway it adds Demonstrating Proof of Possession, so credentials are bound twice. Google's release notes list Agent Identity for general availability on April 22, 2026. ^[30][31]

These controls close the attribution gap and shrink standing privilege. They do not, by themselves, stop the confused-deputy pattern among your own agents. If a finance agent accepts an instruction from an email-sorting agent because both carry valid identities in the same tenant, every token check passes. OWASP's answer is per-action authorization that re-checks the original intent, and it belongs in your policy layer: a Cedar condition on the principal's claims, an IAM condition on the calling agent, or an application check that refuses delegated requests above a threshold. The TOCTOU case needs the same treatment, because a token issued at the start of a long workflow can outlive the approval behind it. ^[1][5][31]

Supply chain and code execution

ASI04 differs from the LLM Top 10 supply chain entry because agents compose capabilities at runtime. Tools, MCP servers, prompt templates and peer agents are loaded while the agent runs, so OWASP's mitigations include signed manifests, curated registries, pinning by content hash, and a kill switch that can revoke a tool or connection across all deployments at once. The document also draws a line: a legitimate tool whose interface is manipulated at runtime is ASI02, while a tool that is malicious at the source is ASI04. ^[1]

Registries are the documented control. AWS Agent Registry, which manages agents, tools, skills and MCP servers, gives records a lifecycle from DRAFT through PENDING_APPROVAL to APPROVED, REJECTED or DEPRECATED, and its discovery APIs and MCP endpoint return only approved revisions. Editing an approved record creates a new draft while the approved revision stays discoverable, and rejecting a record hides it from discovery. Records submitted for approval emit an Amazon EventBridge event, and auto-approval, which skips review, is optional. The registry now runs under the agent-registry namespace; the preview bedrock-agentcore namespace is supported only until October 30, 2026. ^[15]

Google's Agent Registry, generally available since June 18, 2026, catalogs internal agents, tools and MCP servers, and Agent Gateway consults it before allowing an outbound connection, which turns the catalog into an enforcement point rather than a directory. Microsoft's nearest equivalent is the toolbox: a curated tool set behind one MCP endpoint, with immutable versions that are created, tested and promoted to default. The pages reviewed for this guide describe no approval workflow for Foundry tools comparable to the AWS record lifecycle. ^{[17][22][30][32]}

None of these registries inspects behavior. An approved MCP server that later begins forwarding data, as the malicious postmark-mcp package OWASP cites did by secretly copying emails to the attacker, passes every registry check. Pinning versions, re-reviewing on change and keeping the ability to deprecate or reject a record quickly are the parts you operate. ^[1][15]

ASI05 is the most fully served risk in the set, because sandboxing is a mature infrastructure pattern. OWASP asks that generated code never run as root, run in containers with network limits, and be separated from production by validation gates. AgentCore Runtime gives each session a dedicated microVM with isolated compute, memory and filesystem, then terminates it and sanitizes memory when the session ends. AWS notes that it does not map sessions to users, so your backend must keep that relationship. ^[1][11]

Foundry's Code Interpreter runs in Azure Container Apps dynamic sessions isolated by a Hyper-V boundary, and those sessions cannot make outbound network requests or inherit the agent's subnet. Microsoft warns that when Code Interpreter is used through a toolbox in a hosted agent, user isolation is not supported and all users in a project share one container context. Google's Code Execution sandbox offers a limited file system and no network access, and keeps execution state for up to 14 days, with a configurable TTL. Check the sharing and retention behavior of whichever sandbox you use against the data it will see. ^[23][36]

Memory, inter-agent communication and cascading failure

ASI06 covers persistent corruption of anything an agent retains or retrieves: summaries, embeddings, RAG stores and long-term memory. OWASP's mitigations include encryption and least privilege, scanning memory writes before commit, segmentation by user and domain, provenance, refusing to re-ingest the agent's own outputs as trusted memory, and expiry for unverified entries. Providers cover the storage half of that list and hand the content half back to you. ^[1]

AWS says so directly. The AgentCore Memory best practices page places responsibility for input validation and prompt injection prevention in memory extraction on the customer, likens it to preventing SQL injection on a managed database, and recommends sanitizing input with guardrails before CreateEvent persists it. On the storage side, IAM condition keys restrict CreateEvent and ListEvents by bedrock-agentcore:actorId and bedrock-agentcore:sessionId, and RetrieveMemoryRecords and ListMemoryRecords by bedrock-agentcore:namespace. Memory can be encrypted with a customer-managed KMS key. ^[13][14]

Google's Memory Bank keeps an isolated collection per scope, supports TTL-based expiry and records immutable revisions you can inspect and roll back. IAM conditions on the aiplatform.googleapis.com/memoryScope attribute limit which scopes a principal can touch, though methods that span scopes, such as ListMemories and PurgeMemories, need an unconditional role. Google's page names memory poisoning and suggests Model Armor, red teaming and sandboxed execution. Foundry memory is in preview: per-user isolation comes from setting scope to {{$userId}} on the memory search tool, Microsoft names prompt injection and memory corruption as risks, and memory stores do not support virtual network integration. ^[25][34][35]

Scope isolation stops one user's poisoned memory from reaching another user. It does nothing about a user, or a document that user opens, poisoning that user's own memory through the normal write path, which is the pattern in OWASP's own scenario of an assistant's memory implanted through indirect prompt injection. That half requires an admission rule for what may become memory. ^[1]

ASI07 asks for authenticated, integrity-protected channels between agents, with anti-replay and protocol version pinning. The platforms document authentication on the A2A endpoints they host. AgentCore Runtime serves A2A on port 9000 with SigV4 or OAuth 2.0. Foundry's incoming A2A endpoint requires a Microsoft Entra token whose identity holds the Foundry Agent Consumer role, rejects key-based and anonymous access, and serves both A2A v1.0 (generally available) and v0.3 (preview); requests that do not set a version get v0.3, so pin v1.0 with the A2A-Version header. Google's A2A support on Agent Runtime is in preview, and Agent Identity adds mTLS and DPoP across the gateway. Message signing, nonces and semantic validation of what a peer agent says remain application work. ^{[16][17][26][31][39]}

ASI08 is about fan-out: one faulty decision triggering many downstream actions, oscillating retries, queue storms. OWASP's mitigations are mostly architectural, including circuit breakers between planner and executor, independent policy engines and blast-radius caps. Infrastructure contributes bounds. AgentCore Policy supports temporal policies, written in the Cedar-compatible Dogwood language, that limit how often an action runs or keep a running total under a threshold within a session; the pages reviewed do not state their launch stage. Google's Agent Anomaly Detection, in preview for allowlisted users, monitors infinite loops, oscillating retries and feedback amplification and labels the category ASI08. None of the three documents a managed circuit breaker between agents. ^[1][5][38]

Human trust exploitation and rogue agents

ASI09 is the entry with no infrastructure control. OWASP describes an agent, hijacked or simply wrong, that persuades a person to take the final, audited action: approving a payment to attacker bank details, pasting a malicious command, accepting a fabricated rationale for deleting a production database. The logs then show a human decision. The mitigations OWASP lists are interface and process measures: plain-language risk summaries that are not model-generated, confirmation steps, visual cues for high-risk actions, separating preview from effect, and training for the people doing oversight. ^[1]

Provider approval mechanisms help only at the edge. Foundry's require_approval and AgentCore's temporal policies, which can require a prior approval before an action, guarantee that a person is asked. They do not ensure the person is shown evidence the agent could not have fabricated. Design the approval view to show the raw tool arguments and the source of each claim, not the agent's summary of why the action is fine. ^[5][21]

ASI10 concerns an agent whose behavior has diverged from its intended function, whether through compromise or misalignment, after the initial intrusion. OWASP's mitigations are signed and immutable audit logs, trust zones, behavioral monitoring, and kill switches with credential revocation. Here the platforms offer real levers. In Microsoft Entra you can disable an agent identity so it cannot receive tokens while its metadata is retained, disable a blueprint to stop every identity created from it, or use Conditional Access to block agent identities across the tenant. Microsoft Defender, in preview, raises alerts for jailbreak attempts, indirect prompt injection, secret leakage and suspicious access, but only for published Foundry agents. ^{[1][27][28][40]}

On Google Cloud, Agent Platform Threat Detection in Security Command Center, also in preview, watches agents on Agent Runtime for malicious binaries, container escapes and reverse shells, and its control-plane detectors flag data exfiltration attempts, excessive permission denials and suspicious token generation. Agent Anomaly Detection flags agents that abandon their declared role or deviate from system instructions under the ASI10 label. On AWS, the documented levers are the ones already described: a forbid policy on the gateway, which wins over any permit, and the IAM permissions behind the agent's runtime. ^[5][37][38]

Detection catches the crude cases, such as a shell or a credential used from the wrong place. An agent that keeps calling permitted tools in a harmful pattern is the harder case, and catching it depends on baselines you define for that agent.

Where controls run out

The residual risk matrix lists, for each entry, what infrastructure covers, what stays open and who usually owns the gap. The pattern is consistent. Infrastructure answers whether this principal may call this tool with these arguments, from this sandbox, to this destination. It cannot answer whether the call serves the goal the user actually had, whether a remembered fact is true, or whether the person approving understood what they approved.

NIST reaches the same conclusion for prompt injection generally. Its adversarial machine learning taxonomy states that current mitigations do not offer full protection against all attacker techniques, so designers may assume prompt injection is possible whenever a model is exposed to untrusted input, and limit what the model can do with it through separate privileges or well-defined interfaces. Its section on agents notes that tool access turns injection into code execution and data exfiltration. ^[3]

Watch for controls that fail open. Microsoft documents that a hosted agent referencing a guardrail policy ID that does not exist can deploy, report active and apply no content filtering, so harmful prompts reach the agent. AgentCore Policy in LOG_ONLY mode logs denials and lets every call through. Test that each control blocks, not merely that it is configured. ^[8][24]

Source. Conceptual assessment by the editors based on OWASP entry descriptions, NIST AI 100-2 E2025 and the provider controls cited in this guide. ^[1][3]

Method. Conceptual and qualitative. Owners are typical assignments, not a standard; adjust to your organization.

Accessible table and figure data

Figure 3 accessible table

Risk	Infrastructure covers	Still open	Usual owner
ASI01 Goal Hijack	blast radius through tool policy; classifier detection	whether the goal changed	agent designer
ASI02 Tool Misuse	which tool, arguments and destination	a permitted call used for the wrong purpose	tool owner
ASI03 Identity and Privilege	per-agent identity, scoped and bound tokens	delegation between your own agents	identity team
ASI04 Supply Chain	registry approval and versioning	an approved tool that turns malicious	platform team
ASI05 Code Execution	sandbox, network limits, session teardown	harm done through allowed outputs	platform team
ASI06 Memory Poisoning	scope isolation, memory IAM, expiry, revisions	false facts written through allowed paths	agent designer
ASI07 Inter-Agent	authenticated endpoints and caller roles	tampered meaning inside valid messages	agent designer
ASI08 Cascading Failures	rate conditions, session limits, isolation	fan-out where each step is within limits	SRE and platform
ASI09 Human Trust	a required approval step	an approver misled by a fabricated rationale	product owner
ASI10 Rogue Agents	disabling identities, runtime threat detection	judging that behavior has drifted	security operations

Figure 3 accessible table

Risk	Infrastructure covers	Still open	Usual owner
ASI01 Goal Hijack	blast radius through tool policy; classifier detection	whether the goal changed	agent designer
ASI02 Tool Misuse	which tool, arguments and destination	a permitted call used for the wrong purpose	tool owner
ASI03 Identity and Privilege	per-agent identity, scoped and bound tokens	delegation between your own agents	identity team
ASI04 Supply Chain	registry approval and versioning	an approved tool that turns malicious	platform team
ASI05 Code Execution	sandbox, network limits, session teardown	harm done through allowed outputs	platform team
ASI06 Memory Poisoning	scope isolation, memory IAM, expiry, revisions	false facts written through allowed paths	agent designer
ASI07 Inter-Agent	authenticated endpoints and caller roles	tampered meaning inside valid messages	agent designer
ASI08 Cascading Failures	rate conditions, session limits, isolation	fan-out where each step is within limits	SRE and platform
ASI09 Human Trust	a required approval step	an approver misled by a fabricated rationale	product owner
ASI10 Rogue Agents	disabling identities, runtime threat detection	judging that behavior has drifted	security operations

Download imageDownload table CSV

Turning the mapping into a review

A review that walks the ten entries in order spends most of its time on the risks infrastructure cannot settle. Work in layers instead, starting with the controls that hold even if the model is compromised, and keep evidence for each step.

• Inventory every tool, MCP server, memory store and peer agent the agent can reach, and confirm the agent reaches each one through a gateway or tool configuration you control rather than through direct calls from its own code.
• Confirm the agent runs under its own identity: an AgentCore workload identity, a per-agent Foundry identity rather than a shared project identity, or a Google Agent Identity principal. Remove permissions it inherited from a person.
• Put a deny-by-default policy in front of consequential tools, with conditions on arguments and destinations, and restrict who can change its mode. Include the AWS UpdateGateway permission and Google access policies in that review.
• Check sandbox network access, sharing between users and state retention against the data the agent handles.
• Write down which memory scopes exist, who can write to each, and what is screened before a write commits.
• Turn on classifiers at every intervention point the platform supports, then list the tools they do not cover, such as MCP responses in Foundry and tool results in the Bedrock prompt attack filter.
• Rehearse the kill switch: disable the identity or block the gateway route, and time how long the agent keeps acting.
• For ASI01, ASI06 and ASI09, record the design decision and its owner, since no provider setting will close them.