OWASP Top 10 for Agentic Applications Mapped to AWS Controls - What Each Control Mitigates and What Residual Risk Remains

First Published: 2026-08-12
Last Updated: 2026-08-12

There is a specific moment in an agent project where the security conversation stops being philosophical. The prototype works, someone has attached a tool that writes rather than reads, and a reviewer asks the only question that matters: what is stopping this thing from doing something we cannot undo. At that point you need a list of risks and a list of controls, and you need to know which control lands on which risk.

Both lists exist. The industry has an agent-layer risk list, and AWS has a control surface that reaches every stage of an agent's execution path. What does not exist, in either primary source, is the table that joins them. This article is that table, written with a column that most mappings leave out: what each control fails to cover.

Every fact below was verified against primary sources on 2026-08-09, with the page linked at the point of use. The risk list was read from the publisher's own PDF rather than from secondary summaries, and every AWS control name was checked against AWS documentation. Nothing here was measured or executed. No agent was run, no guardrail was created or modified, no policy was applied, and no credential was issued or revoked, because those actions are either irreversible or capable of changing a live system's behavior. No pricing figures appear in this article, and no attack procedure, proof of concept, or evasion technique appears either - each risk is described only to the depth needed to decide what to build against it.

1. Introduction: Choosing Controls for an Agent That Is Already Running
2. Model-Layer Risks Are Not Agent-Layer Risks
3. How to Read This Mapping
4. The Control Surface on AWS
5. ASI01 Agent Goal Hijack
6. ASI02 Tool Misuse and Exploitation
7. ASI03 Identity and Privilege Abuse
8. ASI04 Agentic Supply Chain Vulnerabilities
9. ASI05 Unexpected Code Execution
10. ASI06 Memory and Context Poisoning
11. ASI07 Insecure Inter-Agent Communication
12. ASI08 Cascading Failures
13. ASI09 Human-Agent Trust Exploitation
14. ASI10 Rogue Agents
15. Where Human Approval Is Required
16. Detection Signals and Query Design
17. A Minimum Control Set
18. Failure Modes
19. Frequently Asked Questions
20. Summary
21. References

1. Introduction: Choosing Controls for an Agent That Is Already Running

The decision this article supports is narrow and practical: you have an agent in production or close to it, you have a list of named risks, and you have to decide which AWS controls to put in place first and what to tell your reviewers about the gaps that remain.

The list side of that decision is settled. In December 2025 the OWASP Gen AI Security Project published OWASP Top 10 For Agentic Applications 2026 through its Agentic Security Initiative. The cover of the document carries the label Version 2026 and the date December 2025, it is licensed under CC BY-SA 4.0, and it is not marked as a draft or a release candidate. Its ten entries are identified as ASI01 through ASI10, and that identifier scheme is how practitioners cite individual entries in threat models and vendor mappings.

The control side is also well documented, but scattered. Guardrails are described in the Amazon Bedrock User Guide, session isolation and network modes in the Amazon Bedrock AgentCore documentation, session policies in the IAM User Guide, egress filtering across the Amazon VPC and Route 53 documentation, and audit coverage across CloudTrail and CloudWatch. Each page answers a question about one control. None of them answers the question a reviewer actually asks, which is about one risk.

What is missing is the join, and its absence is verifiable rather than assumed. The OWASP document contains its own mapping matrix in Appendix A, but that matrix maps ASI entries only to other OWASP artifacts, specifically the Non-Human Identities Top 10, the T-codes of the Agentic AI Threats and Mitigations taxonomy, and the AI Vulnerability Scoring System. It does not map to any cloud provider's controls. From the other direction, the AWS Prescriptive Guidance document Security for agentic AI on AWS states plainly that it "maps its best practices to the OWASP Top 10 for Large Language Model Applications" - which is the model-layer list, not the agent-layer one. Neither primary source produces the table below.

1.1 Scope

In scope: the distinction between model-layer and agent-layer risk lists and why conflating them produces bad control decisions; how to read a mapping table without over-claiming; the AWS control surface an agent's execution path passes through; a section for each of the ten entries covering what can go wrong, the primary and secondary controls, the residual risk, and the detection signal; the criteria for deciding which actions need human approval; what to query in audit data; a minimum control set for teams that cannot deploy everything at once; and the failure modes that follow from treating a mapping as a checklist.

Out of scope, with delegation:

The defense-in-depth model itself. Where each class of defense lives in an agent's lifecycle is developed in AI Agent Defense in Depth Model (AIDDM). That article and this one compose: it answers where a control belongs, this one answers which risk a control reduces and by how much.
Guardrails implementation detail. Policy types, the ApplyGuardrail API, detection modes, and cross-Region guardrail profiles are covered in Amazon Bedrock Guardrails Implementation Deep Dive.
Skill and extension vetting procedure. The static inspection workflow is in Agent Skills Security Vetting Guide.
Responsible-AI governance. Content safety as an organizational control is in Responsible-AI Guardrails Architecture on AWS.
How to discover threats in the first place. This article assumes a published list and maps it. The methodology for enumerating threats specific to your own system is the subject of a companion article, Threat Modeling Generative AI Applications on AWS.
Pricing. Several controls below are billable. No figures appear here, and no control is recommended or dismissed on the basis of what it costs.

1.2 A note on versioning

A risk list is a snapshot of consensus, and this one says so about itself: the authors describe an intent to keep evolving the list through community review and evidence from real deployments. Treat the version label and the date as part of the citation, not as decoration. This article maps Version 2026, dated December 2025, as published at the resource page linked above and read on 2026-08-09. If you are reading this well after that date, check the publisher's resource page before assuming the identifiers still carry the same names.

2. Model-Layer Risks Are Not Agent-Layer Risks

Two OWASP lists are in circulation and they are routinely mixed together in the same paragraph, which is the single most common reason control decisions land in the wrong place.

The model-layer list is the OWASP Top 10 for LLM Applications, whose current entries carry the LLM01:2025 through LLM10:2025 identifiers. It is about an application that sends a prompt to a model and does something with the response. The agent-layer list is the subject of this article, and it is about a system that plans, holds memory across sessions, calls tools, talks to other agents, and acts with delegated authority.

The agentic document states its relationship to the model-layer list explicitly rather than leaving it implied. Its entry for goal hijacking notes that unlike the model-layer prompt injection entry, which concerns altering a single model response, the agentic entry captures the broader case where manipulated input redirects goals and multi-step behavior. Its tool entry builds on the model-layer excessive agency entry by extending it to orchestration and delegation chains. The agentic list is not a replacement for the model-layer list and it is not a superset of it. It assumes the model-layer controls are already in place and addresses what autonomy adds on top.

Model-layer risks and agent-layer risks are different scopes

The practical consequence is a scoping rule. If the harm you are worried about is fully described by what the model wrote, it is a model-layer concern and the model-layer list is the right index. If the harm requires the system to have taken an action, remembered something, delegated to something, or continued past the point where a human would have stopped it, it is an agent-layer concern and belongs in the table below. This article maps the agent-layer list only. Where a model-layer control is the right primary defense, it is named as such and attributed to the layer it belongs to.

3. How to Read This Mapping

Three properties of the table are worth stating before the first row, because a mapping read the wrong way is worse than no mapping.

Every row is a mitigation, not a solution. No AWS control eliminates any of the ten entries. Each control narrows the conditions under which the risk produces harm, and the narrowing is partial in a way that is specific to the control. A table that lists a control against a risk and stops there invites the reader to consider the row closed. That is why every section below ends with a residual risk statement, and why the residual risk column is not optional commentary but the point of the exercise.

The AWS side of the mapping is anchored to an AWS-published structure, not to my own taxonomy. The Security pillar of the AWS Well-Architected Agentic AI Lens organizes agent security into nine capabilities, identified as AGENTSEC01 through AGENTSEC09, each with named best practices listed in Appendix A of that lens. Where an ASI entry corresponds to one of those capabilities, the section names it. That gives you a second, AWS-side index to search when you need more depth than a single article can carry, and it keeps the mapping from being one person's opinion about which control matters.

Primary and secondary have specific meanings here. The primary control is the one that would have to fail for the risk to produce harm through its most direct path. Secondary controls reduce the blast radius after that failure, or catch a different path to the same harm. Both matter, and the ordering is not a ranking of importance — a secondary control is often the one you can deploy this week.

The following table is the compact form. The sections that follow expand each row.

ID	Official entry name	Nearest lens capability	Center of gravity on AWS
ASI01	Agent Goal Hijack	AGENTSEC04, AGENTSEC08	Input treatment and approval on goal-changing actions
ASI02	Tool Misuse and Exploitation	AGENTSEC02	Per-tool authorization and egress control
ASI03	Identity and Privilege Abuse	AGENTSEC03	Distinct agent identity and scoped, short-lived credentials
ASI04	Agentic Supply Chain Vulnerabilities	AGENTSEC02, AGENTSEC09	Curated targets and pinned, reviewed tool definitions
ASI05	Unexpected Code Execution (RCE)	AGENTSEC08	Sandboxed execution with no ambient credentials
ASI06	Memory & Context Poisoning	AGENTSEC01	Memory partitioning by namespace and validation on write
ASI07	Insecure Inter-Agent Communication	AGENTSEC06	Authenticated, authorized agent-to-agent calls
ASI08	Cascading Failures	AGENTSEC05, AGENTSEC06	Budgets, circuit breaking, and fan-out visibility
ASI09	Human-Agent Trust Exploitation	AGENTSEC07	Approval interfaces that show evidence, not conclusions
ASI10	Rogue Agents	AGENTSEC07	Behavioral baselines and a working containment path

Entry names in this table are given as printed in the source document, which is why ASI06 appears with an ampersand while ASI02 and ASI03 appear with the word and - the document uses both forms in different places, and the forms above match its section headings and its abbreviation appendix.

4. The Control Surface on AWS

Before the per-entry sections, it helps to see the controls as positions on a path rather than as a list of product names. An agent request passes through a sequence of places where something can refuse it, and a separate set of places where something records that it happened. Those two sets behave differently under attack and should never be confused.

Where each AWS control sits on the agent execution path

4.1 Identity and credentials

Amazon Bedrock AgentCore Identity gives an agent a workload identity of its own and a token vault that holds the credentials it needs for downstream resources. An agent obtains a workload access token, then exchanges it for a resource token through a configured credential provider. The on-behalf-of flow uses GetWorkloadAccessTokenForJWT to carry the end user's inbound token as the subject of the exchange, so the downstream call is made in a context that names both the agent and the user.

On the AWS side of the boundary, session policies are the tool for narrowing what a role can do for the duration of one task. The IAM documentation is unambiguous about the direction they work in: the resulting session's permissions are the intersection of the role's identity-based policy and the session policies, and session policies cannot grant more than the role already allows. Inline and managed session policy text is bounded at 2,048 plaintext characters, which is a real constraint when you try to express per-task scoping in policy alone.

4.2 Content controls

Amazon Bedrock Guardrails provides content filters covering hate, insults, sexual, violence, misconduct, and prompt attack categories; denied topics; word filters; sensitive information filters for PII and custom regex entities; contextual grounding checks; and Automated Reasoning checks. Guardrails can be invoked independently of a model call through ApplyGuardrail, which matters when you want to screen content that is not on its way to a model.

Guardrails can also be made mandatory rather than advisory. The Bedrock User Guide documents how to enforce the use of specific guardrails in model inference requests through the bedrock:GuardrailIdentifier condition key, which lets an IAM policy deny any inference request that does not carry the specified guardrail, across Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream. This converts a control that a developer could forget into one the platform enforces.

4.3 Execution isolation

The default serverless mode of AgentCore Runtime places each user session in its own microVM with isolated compute, memory, and filesystem, and terminates the microVM and sanitizes memory when the session ends. Sessions persist up to eight hours of total runtime and terminate after fifteen minutes of inactivity.

Which mode you deploy on changes the boundary, so establish it before you write the threat model. Since 2026-08-06, AgentCore Runtime Instances is the second option, and AWS describes it as complementing rather than replacing the microVM-based one. There, a session is an isolated Amazon EC2 instance provisioned from a capacity provider, it runs for a maximum of fourteen days rather than eight hours, and stopping a session terminates the instance while retaining the session's persistent volumes so that a later invocation with the same session ID re-attaches them. Two consequences follow for the sections below: the ephemerality that section 12 leans on for blast-radius containment is a property of the serverless mode, not of both; and a fourteen-day session with persistent storage widens the window during which a poisoned working set survives, which is an ASI06 concern rather than an ASI08 one. The credential exposure described next applies to both modes.

Instances also moves the granularity of the boundary, and the security model for Runtime Instances states it plainly: the session is the isolation unit, where a session identified by the pair of capacity provider and session ID maps one to one to an EC2 instance, and agents on an instance are not isolated from each other. Multiple agents can run on the same instance and share its filesystem, and AWS says that whether they run in containers or as processes directly on the instance, neither provides a security boundary between workloads on the same instance, so every agent sharing an instance must be mutually trusted. On the serverless mode the microVM and the session coincide, so the distinction never arises; on Instances it is the difference between a boundary per agent and a boundary per session, and only the second one exists. The compensating fact is that the instances run in your own account and VPC, so your service control policies, permission boundaries, and VPC controls apply to them, and the session data stays with you.

The security best practices page for AgentCore Runtime is explicit about two boundaries of that isolation, and both belong in your threat model rather than in a footnote. First, AgentCore does not enforce session-to-user mappings - your backend must maintain that relationship and enforce limits such as the maximum number of sessions per user. Second, any code running inside the microVM can obtain the execution role's credentials from the metadata endpoint, which means the isolation boundary protects other tenants from this session, not this session's credentials from this session's code.

Built-in tools carry their own network posture. The AgentCore Code Interpreter supports sandbox mode with limited access to AWS services, public network mode for reaching external resources, and VPC mode for reaching private resources while staying isolated from the public internet.

4.4 Authorization at the tool boundary

Policy in Amazon Bedrock AgentCore evaluates Cedar policies at the gateway before a request reaches a target. The model is default deny: every tool call is blocked unless a permit policy grants it, and the Cedar schema is generated from the gateway's own tool definitions so that actions are named after real tools rather than after conventions. Policies can condition on identity attributes, on action identifiers, and on request context.

The same mechanism reaches memory. Fine-grained access control for AgentCore Memory exists because IAM policies match against the IAM principal that calls Memory, and an OAuth-authenticated caller is not an IAM principal. FGAC evaluates Cedar policies against the claims in the caller's token, so you can require that a caller reaches only events whose actorId equals their JWT sub claim.

4.5 Network egress

Two services filter outbound traffic by name and they do different jobs. Route 53 Resolver DNS Firewall filters DNS queries leaving your VPC through the Route 53 Resolver, and its documentation states a limitation that is easy to miss: it filters on the domain name and does not resolve that name to an IP address to be blocked, and it does not filter other application-layer protocols. AWS Network Firewall complements it by matching domains that appear in network traffic itself, such as HTTP host headers and TLS server name indication fields, and can be used to block external encrypted DNS services that would otherwise route around the DNS Firewall entirely.

4.6 Audit and observability

Three record-keeping systems cover different parts of the path, and knowing which one holds which event determines whether your detection query returns anything.

Signal source	What it records	Configuration note
AWS CloudTrail, AgentCore	`InvokeAgentRuntime` and `InvokeAgentRuntimeCommand` as data events under the `AWS::BedrockAgentCore::Runtime` resource type; `InvokeGateway` as a data event	Request and response contents for data events are redacted, and JWT claims have HTML entities sanitized
AWS CloudTrail, Bedrock	`InvokeModel`, `InvokeModelWithResponseStream`, `Converse`, and `ConverseStream` as management events; `InvokeAgent` and `InvokeInlineAgent` as data events	Data events require advanced event selectors for the relevant resource type
Amazon Bedrock model invocation logging	Invocation metadata plus input and output bodies	Separate feature from CloudTrail, with CloudWatch Logs and Amazon S3 destinations; bodies larger than 100 KB go to S3
Amazon CloudWatch GenAI Observability	Metrics for runtime, memory, gateway, built-in tools, identity, and policy resources; spans and traces	Metrics are provided by default; spans and logs require explicit enablement, and traces require CloudWatch Transaction Search to be enabled

The distinction that matters for security is that the first three are records and the fourth is mostly records too. None of them refuses anything. A design that answers a risk with logging alone has answered a different question than the one that was asked.

5. ASI01 Agent Goal Hijack

What the entry covers. The document describes agents as unable to reliably distinguish legitimate instructions from attacker-controlled content, because both arrive as untyped natural language through the same channels. The result is that an agent's objectives, task selection, or decision pathways can be redirected. The entry is scoped to direct alteration of goals and decision paths, which distinguishes it from persistent corruption of stored context and from autonomous misalignment that emerges without an attacker driving it.

Primary controls. Treat every natural-language input as untrusted regardless of where it came from, which in practice means routing retrieved documents, tool outputs, and peer-agent messages through the same screening as user input. Guardrails content filters include a prompt attack category, and ApplyGuardrail lets you screen content that is not itself a model call — which is the case for most retrieved content. Making the guardrail mandatory with the bedrock:GuardrailIdentifier condition key removes the possibility that a new code path simply omits it.

Secondary controls. Least privilege on tools bounds what a redirected goal can accomplish, and human approval on goal-changing or high-impact actions puts a decision point between a changed objective and an irreversible effect. Both are recognized as best practices under AGENTSEC04 in the lens, whose two entries are guardrails and alignment controls, and human-in-the-loop for critical decisions.

Residual risk. Content screening is probabilistic and adversarially targeted, so a screening rate short of perfect is the expected condition rather than a defect to be fixed. More importantly, the controls above do not restore the missing property: there is still no channel-level distinction between instruction and data inside the model's context. A goal shift that stays inside the agent's granted permissions and produces individually plausible actions will not be refused by any of these controls. What limits the damage in that case is the tool scope you set beforehand and the approval gate you placed on the actions you cannot undo.

Detection. Track a stable identifier for the active goal where the framework allows it, and alert on unexpected transitions. In observability data, the signal is a sequence anomaly rather than a single bad event, which means the query is over spans within a trace rather than over individual log lines.

Aspect	Position
Primary mitigation	Screen all natural-language inputs, enforce guardrail use through IAM
Secondary mitigation	Per-tool least privilege, approval on goal-changing actions
Residual risk	Instruction and data remain indistinguishable in context; in-scope, plausible-looking redirection is not refused
Detection signal	Goal-state transitions and anomalous tool sequences within a trace

6. ASI02 Tool Misuse and Exploitation

What the entry covers. This entry is about an agent that operates within its authorized privileges and applies a legitimate tool in an unsafe or unintended way. The document draws its boundaries carefully: if the misuse involves privilege escalation or credential inheritance it belongs to ASI03, and if it results in arbitrary or injected code execution it belongs to ASI05. Contributing factors named in the underlying taxonomy include resource overload and protocol abuse.

Primary controls. Per-tool authorization is the control that matches the risk shape, because the problem is not that the agent lacks permission but that the permission is broader than the task. Policy in AgentCore expresses this as Cedar permit rules against gateway-generated action identifiers, evaluated before the request reaches the target, with default deny for anything not explicitly permitted. Conditions on request context let a policy bound the arguments rather than only the action, so that a tool the agent may call is still constrained in how it may call it.

Secondary controls. Egress control limits where output can go even when the tool call itself is permitted. DNS Firewall gives you a domain allowlist for resolver traffic and Network Firewall covers what DNS Firewall structurally cannot, which is traffic that never asks the resolver. For agents on AgentCore Runtime in VPC mode, security groups govern outbound reachability at the network layer.

Interceptors sit between the gateway's authorization decision and the target. Gateway interceptors can transform requests, filter which tools appear in a listing, and redact fields from responses, and their decisions are recorded in observability data as an authoritative log of allow and deny outcomes.

Residual risk. Cedar policies constrain the call, not the intent behind it. A tool that is legitimately needed at its granted scope can still be used for harm at that scope, and no policy language resolves that, because the scope was granted on purpose. Two further gaps are worth naming. Egress controls that match on domain names do not stop exfiltration through channels that carry data inside otherwise-permitted requests to permitted destinations. And policy evaluated at the gateway does not govern a tool the agent reaches without going through the gateway — a direct SDK call from inside the microVM using execution role credentials bypasses the entire Cedar layer.

Detection. Immutable records of tool invocations with parameters, and alerting on unusual chaining patterns, particularly a read from a sensitive source followed by a call to an external destination. Gateway data events in CloudTrail record that InvokeGateway occurred, though the contents are redacted, so parameter-level detection needs the interceptor or observability path rather than the trail.

Tool descriptor integrity is a related but separate concern, treated in ASI04 and in MCP Tool Poisoning Defense Guide. If you are building or reviewing the server side of the tool boundary, MCP Server Implementation Reference covers the implementations. For authoring and testing the Cedar policies themselves, this site has an AgentCore Cedar Policy Builder and Tester.

Aspect	Position
Primary mitigation	Per-tool Cedar authorization at the gateway, default deny, argument conditions
Secondary mitigation	Egress allowlists, gateway interceptors, tool budgets
Residual risk	In-scope misuse is not refused; direct SDK calls from the runtime bypass gateway policy
Detection signal	Tool-chaining patterns, invocation rate anomalies, interceptor deny records

7. ASI03 Identity and Privilege Abuse

What the entry covers. The document locates this risk in an architectural mismatch: identity systems were built around users, and an agent without a governed identity of its own operates in what the document calls an attribution gap, which makes true least privilege impossible to enforce. Identity here includes both the agent's assigned persona and the authentication material representing it, such as API keys, OAuth tokens, and delegated user sessions.

Primary controls. Give the agent its own identity and stop reusing human credentials for it. This is the most consequential and the most frequently skipped control in the entire mapping. The lens states the desired outcome as agent actions and human actions being distinguishable in audit logs, and it names role chaining into human-designated roles as an anti-pattern to be blocked by trust policy rather than discouraged by convention. AgentCore Identity provides the workload identity and the token vault; on the AWS side, a distinct role with a trust policy that does not admit the agent principal into human identity space is the corresponding control.

Secondary controls. Short-lived, task-scoped credentials narrow the window and the reach. Session policies are the mechanism, with the intersection semantics described in section 4.1. For memory access by OAuth-authenticated callers, FGAC lets you bind access to token claims rather than to an IAM principal.

Residual risk. Three gaps deserve explicit statement.

First, the 2,048-character limit on session policy text bounds how much per-task scoping you can express in policy, which pushes complex scoping decisions to the gateway layer or into application logic where they are harder to audit.

Second, the outbound credential mode of a gateway changes which identity is authorized downstream, and the consequences are not intuitive. The AgentCore Memory gateway connector documentation states that with GATEWAY_IAM_ROLE, Memory sees only the gateway execution role, so IAM policies scoped to an individual caller — including a Deny on a specific actorId - are not evaluated against the original caller and do not take effect. A team that writes a per-caller deny and assumes it is enforced has a control that exists in the console and not in the request path.

Third, the credential exposure inside the microVM described in section 4.3 means that the execution role is effectively the ceiling for anything running in the session, regardless of what the agent framework intends.

Detection. Unused access findings from IAM Access Analyzer identify permissions granted and not exercised, which is the practical route to shrinking an agent role that grew during development. External and internal access findings cover the resource-sharing direction. In CloudTrail, token issuance events from AgentCore Identity such as GetWorkloadAccessToken and GetResourceOauth2Token record which credential provider, scopes, and flow were used, with the tokens themselves redacted. For understanding how the policy types interact before you rely on one, see IAM Policy Evaluation Logic Step-by-Step and the IAM Policy Analyzer.

Aspect	Position
Primary mitigation	Distinct agent identity, trust policy blocking assumption of human roles
Secondary mitigation	Short-lived scoped credentials, session policies, memory FGAC on token claims
Residual risk	Session policy size limit; caller-scoped IAM denies are inert under `GATEWAY_IAM_ROLE`; execution role reachable from inside the microVM
Detection signal	Unused access findings, token issuance events, role assumption paths

8. ASI04 Agentic Supply Chain Vulnerabilities

What the entry covers. The document's framing is that agentic ecosystems compose capabilities at run time rather than resolving them at build time, which shifts the security question from the manifest to the runtime. Components in scope include models and weights, tools, plug-ins, datasets, other agents, agentic interfaces such as MCP and A2A, registries, and update channels.

Primary controls. Maintain an approved registry of tools with security assessments behind it, which the lens carries as AGENTSEC02-BP03. On AWS, the concrete expression is that a gateway exposes a curated set of targets rather than resolving arbitrary endpoints at run time, and that adding a target is a reviewed change rather than a runtime discovery event. Fully qualified tool names and version pinning remove the class of problems that arise from name resolution.

Secondary controls. Cedar policies at the gateway bound what a newly added or altered target can do even before anyone notices it changed, which is why default deny matters more here than anywhere else in the mapping. Vetting procedure for skills and extensions is covered in Agent Skills Security Vetting Guide, and capability inspection for MCP servers is available in the MCP Capability Inspector and Validator.

Residual risk. A reviewed component can change after review. Runtime composition means the artifact you assessed and the artifact that executes are separated in time, and nothing in the AWS control surface re-verifies a third-party tool descriptor on every invocation. Registry curation also does not extend transitively: approving an MCP server does not approve whatever that server calls downstream. This is the entry where the residual risk is largest relative to the available controls, and where process, rather than a product setting, carries most of the weight.

Detection. Changes to gateway target configuration are management events in CloudTrail and should be treated as change-controlled rather than routine. Beyond that, the honest answer is that detection here is weak: a descriptor that changed between assessments produces no distinctive signal at invocation time.

Aspect	Position
Primary mitigation	Curated gateway targets, fully qualified names, version pinning, reviewed additions
Secondary mitigation	Default-deny Cedar policy bounding any target, documented vetting procedure
Residual risk	Runtime composition separates assessment from execution; approval is not transitive to downstream dependencies
Detection signal	Target configuration changes as management events; weak invocation-time signal

9. ASI05 Unexpected Code Execution

What the entry covers. Agentic systems generate and execute code, and this entry covers execution that is unexpected or adversarial — scripts, binaries, deserialized objects, template engines, in-memory evaluation — leading to host or runtime compromise, persistence, or sandbox escape. The document separates it from tool misuse specifically because these outcomes require host and runtime mitigations beyond ordinary tool-use controls.

Primary controls. Run generated code in a sandbox that was designed for untrusted input. The AgentCore Code Interpreter provides session-based isolation with configurable network access, and sandbox mode restricts external access to AWS services rather than the open internet. Choosing sandbox mode over public network mode is the single highest-value configuration decision in this section, and the decision should be made explicitly rather than inherited from a quickstart.

Secondary controls. Egress controls apply to the sandbox as they do elsewhere. Where the code interpreter runs in VPC mode to reach private resources, the same security group and firewall layers govern it.

Residual risk. The sandbox contains the execution; it does not make the execution correct. Generated code that runs inside the sandbox and calls a permitted AWS API with the execution role's credentials produces exactly the effect that role allows, and the sandbox is not consulted about whether that effect was intended. Combined with the metadata-endpoint credential exposure noted in section 4.3, this makes the execution role the true boundary for this entry. Scoping that role is not a supporting task here — it is the control.

Detection. Sandbox sessions produce metrics and, when enabled, spans in GenAI Observability. Downstream API calls made from within the session appear in CloudTrail under the execution role, which is why the separate-identity control from ASI03 pays off again here: if the agent role is distinct, its activity is separable in the trail. Aggregating those trails for query is covered in Centralized Logging and Audit Architecture on AWS.

Aspect	Position
Primary mitigation	Sandboxed execution, sandbox network mode chosen deliberately
Secondary mitigation	Egress filtering, VPC mode where private access is required
Residual risk	Sandbox does not constrain permitted API calls made with execution role credentials
Detection signal	Session metrics and spans; downstream calls attributed to the agent role in CloudTrail

10. ASI06 Memory and Context Poisoning

What the entry covers. Context here means anything the agent retains, retrieves, or reuses — summaries, embeddings, RAG stores — explicitly excluding one-time input prompts, which belong to the model-layer prompt injection entry. The risk is corruption or seeding of that context so that future reasoning, planning, or tool use is biased. The document notes that poisoned memory frequently leads onward to goal hijacking, which makes this entry an upstream cause rather than only a harm in itself.

Primary controls. Partition memory along the boundaries that matter for the workload. AgentCore Memory organizes long-term memory by namespace, using a hierarchical path built from variables such as actorId, strategyId, and sessionId. The documentation recommends a trailing slash specifically to prevent prefix collisions in multi-tenant applications, which is the kind of detail that decides whether the partition holds. Choosing the granularity is a security decision: per-actor-per-session is the tightest, per-strategy-across-actors is the loosest, and the difference is how far a poisoned record can travel.

Secondary controls. Validate content on the way in rather than only on the way out, which the lens carries as AGENTSEC01-BP02. FGAC binds memory access to token claims so that a caller reaches only records under its own namespace. Retrieval grading on the RAG path is a different control for the same failure and is covered in Agentic RAG Architecture on Amazon Bedrock; the broader design question of what to remember and when to forget is in AI Agent Memory Design Guide.

Residual risk. Namespace partitioning contains spread; it does not detect corruption within a partition. A poisoned record written under the correct actorId by a legitimate path is exactly as retrievable as a good one. Long-term memory strategies extract and consolidate content over time, which means a subtly tainted input can influence stored knowledge gradually and without a single event that looks wrong. And the authorization caveat from ASI03 recurs here in its sharpest form: under GATEWAY_IAM_ROLE, caller-scoped IAM denies on a specific actorId do not take effect, so partitioning enforced only that way is not enforced at all.

Detection. Alert on writes that cross namespaces, and on retrieval patterns that change without a corresponding change in the workload. Because consolidation happens asynchronously, comparing what was ingested against what was later extracted is more informative than watching either alone.

Aspect	Position
Primary mitigation	Namespace partitioning at the right granularity, with collision-safe paths
Secondary mitigation	Validation on write, FGAC on token claims, retrieval grading
Residual risk	No integrity signal within a partition; gradual drift through consolidation; partitioning inert if enforced only by caller-scoped IAM under `GATEWAY_IAM_ROLE`
Detection signal	Cross-namespace writes, retrieval pattern shifts, ingest-versus-extract comparison

11. ASI07 Insecure Inter-Agent Communication

What the entry covers. Multi-agent systems coordinate through APIs, message buses, and shared memory, and the document observes that decentralized architecture with uneven trust makes perimeter-based models ineffective. The risk spans transport, routing, discovery, and semantic layers. It is distinguished from identity abuse, which is about credentials and permissions, and from memory poisoning, which is about stored state — this entry is about messages in flight.

Primary controls. Authenticate and authorize agent-to-agent calls rather than treating an internal caller as trusted. The lens is direct about this under AGENTSEC06, whose best practices are encrypting and signing inter-agent messages, workflow orchestration security controls, establishing trust boundaries between agents, and monitoring coordination anomalies. On AWS, routing agent-to-agent traffic through a gateway that validates tokens and evaluates Cedar policies converts an implicit trust relationship into an explicit, auditable one.

Secondary controls. Network placement narrows who can reach whom. VPC mode for AgentCore Runtime with security groups scoped to specific peers is the network-layer complement to token validation. Protocol-level design for cross-runtime agents is covered in Agent Interoperability Architecture on AWS.

Residual risk. Authenticating the sender does not validate the content. A correctly signed message from a genuinely authorized peer that has itself been redirected is delivered and acted upon, which is the path from ASI01 or ASI10 into a second agent. Discovery is also a weak point that message-level controls do not address: an agent that resolves peers dynamically has a trust decision to make at resolution time, and the controls above apply only after that decision has been made.

Detection. Coordination anomalies rather than individual message failures — unexpected peer relationships, message volumes that do not match the workload, and repeated identical intents. Distributed tracing across agents makes these visible; without Transaction Search enabled, the trace data that would show them is not being collected.

Aspect	Position
Primary mitigation	Token validation and Cedar authorization on agent-to-agent calls through a gateway
Secondary mitigation	VPC placement with peer-scoped security groups, signed messages
Residual risk	Authenticated senders can carry redirected content; discovery-time trust is outside the message controls
Detection signal	Unexpected peer relationships, volume anomalies, repeated identical intents in traces

12. ASI08 Cascading Failures

What the entry covers. This entry is about propagation and amplification rather than origin. A single fault — a hallucination, a corrupted tool result, a poisoned memory — spreads across agents, sessions, and workflows into system-wide harm. The document instructs that the initial defect be classified under its own entry and that ASI08 apply only when the defect spreads with measurable fan-out. It also names observable symptoms that make the entry operationally actionable: rapid fan-out, cross-domain or cross-tenant spread, oscillating retries and feedback loops, and downstream queue storms.

Notably, the document does not claim this risk is fully mitigable. It states that the speed and scale of fault propagation in a multi-agent system can outpace human ability to keep up, leaving unmitigated risk that an enterprise must evaluate against its own risk budget. That is the publisher's own residual risk statement, and it is more candid than most mappings are.

Primary controls. Bound the loop before it bounds you. Usage ceilings with automatic throttling, timeout budgets, and circuit breaking between agents are the controls that convert an unbounded cascade into a contained failure. These are engineering patterns rather than product settings, and they are the subject of Agent Reliability Engineering Design Guide, which covers retries, loop detection, timeout budgets, and escalation in depth.

Secondary controls. Session isolation limits blast radius by construction: because each session in the serverless mode has its own microVM and its state is ephemeral, a fault in one session does not carry into another through the runtime. On Runtime Instances the isolation between sessions still holds, but the ephemerality does not, so a fault that corrupts session state can outlive the invocation that produced it. The cross-session path that remains open in both modes is memory, which is why ASI06's partitioning is also a cascade control.

Residual risk. Isolation between sessions does not prevent fan-out through shared downstream systems. Ten isolated sessions calling the same API produce the same load as ten uncontained ones. Rate limits and budgets are configured per resource, so the aggregate behavior of many agents is not bounded by any single one of them. And detection is inherently lagging: by the time fan-out is visible in metrics, the actions have been taken.

Detection. The symptoms the document names map cleanly onto observability queries — fan-out counts per unit time, repeated identical intents, retry oscillation between two agents. Non-repudiation matters here as much as detection, because reconstructing which agent initiated a cascade requires that each action be attributable, which returns to the distinct-identity control from ASI03.

Aspect	Position
Primary mitigation	Budgets, timeout ceilings, circuit breaking, loop detection
Secondary mitigation	Per-session isolation, memory partitioning to block cross-session spread
Residual risk	Shared downstream systems still absorb aggregate load; propagation can outpace human response; detection lags the actions
Detection signal	Fan-out rate, retry oscillation, queue depth, repeated identical intents

13. ASI09 Human-Agent Trust Exploitation

What the entry covers. This entry is about human misperception and over-reliance. Fluency, apparent expertise, and anthropomorphic cues build trust that can be exploited to influence decisions, and the document notes the compounding problem that the human performs the final audited action, which makes the agent's role in the outcome invisible to forensics. Insufficient explainability and missing confirmation on sensitive actions are named among the common weaknesses.

Primary controls. This is the entry where AWS product features do the least work and interface design does the most. The lens capability AGENTSEC07 names cognitive load management, clear confidence indicators and manipulation warnings, and multiple reviewers for critical operations. The AWS mechanism that most directly supports it is confirmation before action: user confirmation in Amazon Bedrock Agents presents the action to the user for CONFIRM or DENY before the function is invoked, and the documentation frames this explicitly as a safeguard against malicious prompt injection — if the response includes instructions for the model to invoke unintended actions, the agent will comply absent that gate.

Secondary controls. Requiring more than one reviewer for the highest-impact operations removes the single point of persuasion. Storing the decision context durably before sending an approval request means the reviewer's evidence is not supplied by the same component being reviewed.

Residual risk. A confirmation prompt that shows a conclusion rather than evidence converts human oversight into a formality. The control refuses nothing on its own; it delegates the refusal to a person, and its effectiveness is bounded by what that person is shown and how many times a day they are shown it. Approval fatigue is a predictable failure of a correctly implemented control, not a sign that it was implemented wrong. Neither AWS nor OWASP offers a technical remedy for that, which is why the lens treats reviewer workload as a design variable in its own right.

Detection. Log reviewer identity, timestamps, the operation under review, and the decision. Approval rates approaching 100 percent, and approval latencies too short for the evidence to have been read, are the signals that the gate has stopped functioning while continuing to produce records.

Aspect	Position
Primary mitigation	Confirmation before sensitive actions, evidence-bearing approval interfaces
Secondary mitigation	Multiple reviewers on critical operations, durable decision context stored independently
Residual risk	Control delegates refusal to a human; approval fatigue degrades it without any technical failure
Detection signal	Approval rate near unity, decision latency too short to have read the evidence

14. ASI10 Rogue Agents

What the entry covers. An agent that deviates from its intended function or authorized scope, where individual actions may appear legitimate but the emergent behavior is harmful. The document is precise about the boundary: external compromise may initiate the divergence, but this entry is about the loss of behavioral integrity and governance once the drift has begun, not about the initial intrusion. It is distinguished from over-granted permissions, which is a model-layer concern, and from human misperception, which is ASI09.

Primary controls. Behavioral anomaly detection with a working containment path, which the lens carries as AGENTSEC07-BP04. Containment is the part teams under-build. Detecting drift without a tested way to stop a running agent produces an alert and no remedy, so the control is only complete when the stop path exists and has been exercised. AgentCore Runtime provides the mechanism to stop a running session, and sessions terminate on their own at fifteen minutes idle or eight hours total — but relying on the timeout as your containment plan means accepting up to eight hours of continued action.

Secondary controls. Everything that bounds scope bounds a rogue agent's reach: Cedar policy at the gateway, egress allowlists, and the execution role's permissions. A distinct agent identity is what makes revocation surgical rather than an outage.

Residual risk. Behavior that is individually legitimate does not produce a detectable event; it produces a distribution shift. That requires a baseline, and a baseline requires a period of observation during which the agent was behaving correctly — an assumption that is not verifiable at the time you establish it. Anomaly detection also degrades as legitimate agent behavior evolves, so a baseline that is not maintained becomes a source of false confidence rather than of signal.

Detection. Establish a behavioral baseline covering goal state, tool-use patterns, and access patterns, then alert on deviation. CloudTrail provides the attributable record of what the agent did downstream, and GenAI Observability spans provide the reasoning-level sequence, but only if span emission and Transaction Search were enabled before the incident.

Aspect	Position
Primary mitigation	Behavioral baselines with anomaly detection and a tested containment path
Secondary mitigation	Scope bounds from Cedar policy, egress allowlists, and execution role permissions
Residual risk	Drift appears as a distribution shift, not an event; baselines assume a known-good observation period and decay over time
Detection signal	Deviation from goal-state, tool-use, and access baselines; session lifetime approaching maximum

15. Where Human Approval Is Required

The per-entry sections referred to human approval four times. That control is expensive — it costs latency, reviewer attention, and goodwill — so the question is not whether to use it but where. The useful output of this section is a criterion you can apply to a new tool next quarter, not a list of tools that need approval today.

15.1 The three axes

Classify each action the agent can take on three axes, and require approval when any one of them exceeds your threshold.

Reversibility. Can the effect be undone by an operation the agent or an operator can perform, within a window short enough that the damage does not compound. Sending an email is irreversible. Writing a database row is reversible if you have the prior value and a path to restore it. This axis is the strongest predictor of whether an approval gate earns its cost.

Blast radius. How many principals, tenants, or records the single action touches. An action scoped to the requesting user's own data is a different risk from the same action with a wildcard.

Attribution. Whether the resulting record identifies the agent as the actor. If the action is performed under a shared identity, or the agent's role in the decision disappears once a human clicks confirm, then post-hoc review cannot reconstruct what happened, and pre-hoc approval is the only point at which the decision is visible. This axis is the one most often left out, and it is exactly the property ASI09 describes as making the agent's role invisible to forensics.

The classifier that applies these axes should be deterministic code, not a model call. The lens states this directly under AGENTSEC04-BP02: implement the risk classifier as deterministic logic rather than an LLM. An approval gate whose trigger condition is itself a model output inherits every failure mode the gate was built to contain.

15.2 Matching the mechanism to the runtime

The lens enumerates the mechanisms by execution environment, which saves a design argument.

Execution environment	Approval mechanism
Step-function-driven agents	AWS Step Functions callbacks with the task token pattern
Agents on Amazon Bedrock Agents	User confirmation, or return of control
Agents needing long-running approval processing	Amazon Bedrock AgentCore Runtime async tasks

The Step Functions callback pattern pauses a task until the token is returned through SendTaskSuccess or SendTaskFailure. Two constraints matter for design: the pause can extend to the one-year execution service quota, and task tokens must be passed from principals within the same AWS account - they do not work across accounts.

Return of control differs from user confirmation in an important way. User confirmation is a boolean gate on an action the agent chose. Return of control hands the parameters back so a human can modify them before execution. Where the risk is that the agent chose a defensible action with an indefensible argument, the boolean gate is the weaker fit.

15.3 Making the gate hold

Two design rules keep the gate from decaying into a formality.

Store the decision context durably before you send the notification. If the reviewer's evidence is assembled by the same component under review, and it is assembled at the moment the reviewer looks, then a compromised component supplies its own justification. Writing the context first and serving it through an authenticated interface separates the two.

Bound persistent trust grants. An approval that says "trust this tool for the rest of the session" is a legitimate usability affordance and an unbounded grant. Scope such grants to a specific command, parameter shape, or resource, tier them by risk, and make them revocable.

Policy in AgentCore can express this bound declaratively rather than in application code. Its temporal policies condition a permit on what has already happened in the session, which makes an approval consumable. The documentation's own example permits a transfer only when a prior approval action completed within the last hour and no transfer has completed since:

permit (
  principal,
  action == AgentCore::Action::"FundsTarget___transfer_funds",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
  !AgentCore::Action::"FundsTarget___transfer_funds"::response{ eventResource: resource }
  since within 1h AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource }
};

Matching on ::response rather than on the request is what makes this work, because an action counts as completed only after it succeeds, so the request being authorized does not block itself. The documentation also notes an operational consequence worth designing around: a response event is recorded shortly after the call completes, so the approving call and the approved call should not be issued back to back.

Finally, decide the timeout behavior before you deploy the gate. An approval request that nobody answers must resolve to something, and the safe default is to block the operation. A gate that fails open under load is not a gate.

16. Detection Signals and Query Design

Detection for agents differs from detection for services in one structural way: the interesting unit is a sequence, not an event. Individually valid calls in an unusual order is the shape of nearly every entry above. That changes where you look and what you write.

16.1 Knowing which store holds the signal

The table in section 4.6 is the routing decision, and getting it wrong is the most common reason an agent detection query returns nothing. Three consequences are worth restating.

Bedrock inference calls are management events. InvokeModel and Converse are recorded as management events, so they appear without configuring data event selectors — but InvokeAgent and InvokeInlineAgent are data events and require advanced event selectors on the relevant resource type. A trail configured for management events only will show you the model calls and not the agent invocations.

AgentCore data event contents are redacted. The gateway CloudTrail documentation states that request and response contents for data events are redacted and that JWT claims have HTML entities sanitized. You can therefore see that a gateway invocation occurred and who made it, but not what was in it. Parameter-level detection has to come from interceptors or from spans, not from the trail.

Spans require enablement, and traces require Transaction Search. Metrics are provided by default for AgentCore resource types, but spans and logs require explicit enablement, and viewing traces requires the one-time setup of CloudWatch Transaction Search. Enabling this after an incident does not retrieve the data you did not collect during it.

There is also a caveat in the CloudTrail documentation that belongs in any review of an agent's audit posture: for management events, only request parameters defined by the API are eligible for redaction, and additional fields you include that are not part of the API are recorded exactly as sent. Custom metadata passed alongside an API call is not covered by the redaction guarantee.

16.2 What to query

Span data is where sequence-level questions are answerable. GenAI Observability writes spans to the aws/spans log group, queryable with CloudWatch Logs Insights, and AWS documentation shows the pattern of filtering on span attributes:

fields @timestamp, attributes.gen_ai.usage.total_tokens, attributes.user.id |
filter attributes.gen_ai.usage.total_tokens > 10000 |
sort attributes.gen_ai.usage.total_tokens desc |
limit 10

Treat that shape as the template and change the predicate to match the entry you are hunting. Useful predicates by entry:

Fan-out per trace for ASI08, counting distinct downstream invocations initiated from a single root.
Tool-sequence pairs for ASI02, looking for a read from a sensitive target followed by a call to an external one within the same trace.
Session lifetime approaching the eight-hour maximum for ASI10, which is cheap to compute and correlates with agents that are not converging.
Repeated identical intents for ASI08, which the source document names as an observable symptom.
Cross-namespace memory writes for ASI06, which is the clearest single indicator that a partition boundary is not holding.

16.3 What detection cannot do here

Two limits should be written into the runbook rather than discovered during an incident. Detection is lagging for every entry in this list, because the agent acts before the span is written. And several entries produce no distinctive event at all - ASI04's altered descriptor and ASI10's gradual drift are visible as differences from a baseline, not as an event that can be alerted on. For those, the control that matters is the one that refused something earlier in the path.

17. A Minimum Control Set

Few teams deploy all of the above at once. The ordering below is what to build first if you are building in order, and it follows a deliberate principle: prefer the controls that refuse things over the controls that record things, and prefer the controls whose absence cannot be compensated for later.

The AWS Agentic AI Security Scoping Matrix is a useful way to decide how far down the list you need to go, since it graduates systems by degree of agency from constrained assistance through to full agency with self-directed activity. A system at the low end of that range can reasonably stop earlier than one whose agents initiate their own work.

Give the agent its own identity. Everything downstream — attribution, revocation, per-caller policy, useful audit queries — depends on this, and retrofitting it after an incident means re-analyzing every log you already have. It is first because its absence cannot be compensated for by anything else on this list.
Scope the execution role. Given the metadata-endpoint exposure, this role is the effective ceiling for anything the agent or its generated code can do. Cheap to do at creation, painful to shrink once workloads depend on the breadth.
Put tool calls behind default-deny authorization. A gateway with Cedar policies converts every new tool from an implicit grant into an explicit one, which is what keeps the surface from growing quietly.
Gate irreversible actions on human approval. Apply the section 15 criteria. Even a small gate on a short list of actions changes the worst case from unrecoverable to embarrassing.
Constrain egress. DNS Firewall plus Network Firewall, or VPC mode with scoped security groups. This is the control that most limits what a successful manipulation can send anywhere.
Make guardrail use mandatory rather than conventional. The bedrock:GuardrailIdentifier condition key is a small policy change that removes an entire class of "this code path forgot" incidents.
Partition memory by namespace at the right granularity. Choose the axis deliberately, and verify that the enforcement mechanism actually evaluates the caller you think it does.
Turn on the audit and observability you will need later. Data event selectors for agent invocations, span emission, and Transaction Search. This is last on the list not because it is unimportant but because it is the only item that produces no protection at all on its own — and the only one whose value depends entirely on having enabled it before you needed it.

18. Failure Modes

These are patterns that recur in agent security reviews. Each one is a way to hold the controls above and still be exposed.

18.1 Treating the guardrail as the security control

Content filtering addresses one path to one entry. It does not authorize a tool call, does not scope a credential, does not bound egress, and does not stop a cascade. Teams that deploy Guardrails and consider agent security addressed have covered a corner of ASI01 and left ASI02 through ASI10 untouched.

18.2 Granting one broad permission because the tool list is long

The permission that makes twelve tools work is easier to write than twelve scoped ones, and it converts every subsequent tool addition into a silent expansion of the agent's reach. This is the anti-pattern the lens names as a flat trust model, and it is what turns an in-scope tool misuse - ASI02, which is contained by definition — into ASI03, which is not.

18.3 Trusting memory because you wrote the writer

Content that entered through a legitimate path is not thereby trustworthy. The consolidation behavior of long-term memory strategies means the value that influences a decision months from now may be a summary of a summary, and no component in that chain re-checks the original. Partitioning limits how far a bad record travels; it says nothing about whether the record is good.

18.4 Collecting logs and never querying them

Every entry in this article has a detection signal, and none of them fires on its own. Enabling model invocation logging, data events, and span emission produces data whose only value is realized by a query someone runs. The specific version of this failure worth guarding against is enabling collection after designing the detection, so that the fields the query needs were never emitted.

18.5 Letting the approval gate become a formality

Covered in section 13, and it belongs here too because it is the failure that looks most like success. Approval rates near 100 percent with sub-second decision latency describe a gate that is producing a complete audit trail of decisions nobody made. Measure the gate, not just its output.

18.6 Assuming isolation covers what it does not

Per-session isolation is a strong boundary between sessions and not a boundary between the session's code and the session's credentials. Session-to-user mapping is your responsibility, not the platform's. Both facts are stated in the AWS documentation, and both are routinely assumed the other way. Two more assumptions join them once Runtime Instances is in the estate: isolation and ephemerality are not the same property, and only the serverless mode gives you both; and the unit of isolation is the session, not the agent, so co-locating two agents that are not mutually trusted on one session removes the boundary you thought you had.

18.7 Reading a mapping as a checklist

The failure that this article is most likely to cause. Every row above has a residual risk statement because every row leaves something uncovered. A review that walks the table, confirms a control exists for each entry, and concludes the system is covered has used the mapping to produce false confidence more efficiently than having no mapping at all.

19. Frequently Asked Questions

Does implementing this mapping make an application compliant with anything?

No. The risk list is a community-produced awareness document, not a control framework or a certification scheme, and the mapping here is an engineering aid rather than an assessment. If you need an assessment artifact, the Well-Architected lens questions are structured for review; this article is structured for design.

The list has ten entries. Do I need ten separate control programs?

No, and the mapping table in section 3 shows why. Several entries converge on the same small set of AWS controls: distinct identity and scoped credentials appear in ASI02, ASI03, ASI05, ASI08, and ASI10. Building the identity control well moves five rows at once. The entries are distinct as risks, not as remediation projects.

Where should model-layer controls go if this article only maps the agent layer?

They stay where they are, and they stay necessary. The agentic document assumes the model-layer controls exist and addresses what autonomy adds. If your prompt injection defenses are not in place, the right next step is the model-layer list rather than this one.

Can Cedar policies at the gateway stop an agent that calls an AWS API directly?

No. Policy in AgentCore is evaluated by the gateway, so it governs calls that pass through the gateway. Code running in the runtime that constructs an SDK client and calls a service directly is authorized by IAM against the execution role, not by Cedar. This is why the execution role scope is item two in the minimum control set rather than an afterthought.

If AgentCore Runtime isolates each session, why does memory poisoning still matter?

Because memory is the intentional exception to session isolation. Long-term memory exists precisely to carry information across sessions, so it is the one channel by which a fault in one session reaches another through the platform rather than around it. Session isolation and memory partitioning are two different controls and you need both.

Does a deny on a specific actor in an IAM policy protect an AgentCore Memory namespace?

It depends on the gateway's outbound credential mode, and the answer is counterintuitive in one of them. Under CALLER_IAM_CREDENTIALS, Memory sees the caller's own IAM identity and caller-scoped policies are evaluated against it. Under GATEWAY_IAM_ROLE, Memory sees only the gateway execution role, and AWS documentation states that caller-scoped policies — including a deny on a specific actorId - do not take effect. Verify the mode before relying on the policy.

Is DNS Firewall enough for egress control?

No, and its own documentation explains why. It filters DNS queries going through the Route 53 Resolver, it filters on the domain name without resolving it to an IP address, and it does not filter other application-layer protocols. AWS guidance pairs it with Network Firewall, which can match domains in HTTP host headers and TLS SNI fields and can block external encrypted DNS services that would otherwise bypass the DNS Firewall.

How often does this mapping need to be revisited?

Whenever either side changes. The risk list carries a version label and its authors describe an intent to keep revising it, and the AWS control surface for agents has been changing quickly. Rather than scheduling a review, tie it to two triggers: a new version of the list, and any change that adds a tool, an identity, or an egress path to your agent.

Why does the residual risk column matter more than the control column?

Because the control column is what you built and the residual risk column is what you are still carrying. A design review can verify the first from configuration. Only the second tells you what to say when someone asks what happens if the control does not hold, and that question is the one that arrives during an incident rather than during the review.

20. Summary

The agent-layer risk list published as Version 2026 in December 2025 gives ten named entries, ASI01 through ASI10, and the AWS control surface reaches every stage of an agent's execution path. Joining them is worth doing because neither primary source does it — the publisher's own mapping matrix stays inside its ecosystem, and the AWS prescriptive guidance for agentic security maps to the model-layer list instead.

Three conclusions survive the exercise.

The layer distinction decides everything downstream. Model-layer risks concern what the model wrote; agent-layer risks concern what the system then did with memory, tools, delegation, and autonomy. Applying a model-layer control to an agent-layer risk produces a control that is correctly implemented and aimed at the wrong thing.

Identity is the load-bearing control. It appears as primary or secondary in half the entries, it determines whether audit data can attribute anything, and it is the only item on the minimum control set whose absence cannot be compensated for by building something else later.

Every row leaves something uncovered, and the uncovered part is the deliverable. In-scope misuse is not refused by authorization. Sandboxes contain execution without constraining permitted API calls. Namespace partitioning limits spread without detecting corruption. Approval gates delegate refusal to a person who may be tired. The source document is candid about this in its own cascading-failures entry, where it states that propagation can outpace human response and that the remaining risk has to be evaluated against the organization's risk budget. A mapping that reads as a checklist has misread itself.

The companion question to this article — how to enumerate the threats specific to a system rather than mapping a published list — is treated separately in Threat Modeling Generative AI Applications on AWS. For where each class of defense belongs in an agent's lifecycle, see AI Agent Defense in Depth Model (AIDDM). For the AgentCore security building blocks referenced throughout, see Amazon Bedrock AgentCore Implementation Guide Part 2 and the Amazon Bedrock AgentCore Master Index. Terminology used without definition here is defined in AI Agent Engineering Glossary.

21. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi