hidekazu-konishi.com

OWASP Top 10 for Large Language Model Applications Mapped to AWS Controls - What Each Control Covers, Where It Stops, and What the Application Still Owns

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

Reviews of generative AI applications inevitably lead to the same question: which controls are in place for each of the industry-standard risks? The risk lists are publicly available, and AWS controls are also documented. What's missing is a table that connects the two, and even more so, a description of what responsibilities remain with the application itself for each risk.

This article provides that table. As of August 15, 2026, all information has been verified against the original source materials. The risk list was read directly from the publisher's PDF rather than from explanatory articles, and every AWS control name was cross-referenced with official documentation. Nothing here comes from measurement. This article invokes no model, creates or changes no guardrail, and applies no policy. Doing so would be irreversible or would alter the behavior of a live system. No AWS pricing figures appear anywhere in this article. Neither do attack procedures, proof-of-concept code, or bypass techniques. Each risk goes only as deep as you need to decide what to build against it.

This article includes a column that other mapping tables rarely carry: a column for the scope that the control does not cover.

Table of Contents

1. 1. Introduction
2. 2. The Model-Layer List and the Agent-Layer List Are Different Lists
3. 3. What Changed Between the 2025 and 2026 Editions
4. 4. How to Read This Mapping Table
5. 5. The AWS Control Surface
6. 6. LLM01:2026 Prompt Injection
7. 7. LLM02:2026 Sensitive Information Disclosure
8. 8. LLM03:2026 Excessive Agency
9. 9. LLM04:2026 Supply Chain
10. 10. LLM05:2026 Data and Model Poisoning
11. 11. LLM06:2026 Unbounded Consumption
12. 12. LLM07:2026 Misinformation
13. 13. LLM08:2026 Hidden Context Exposure
14. 14. LLM09:2026 Vector and Embedding Weaknesses
15. 15. LLM10:2026 Improper Output Handling
16. 16. Differences from the Mapping Table Published by AWS
17. 17. Three Items That AWS Controls Alone Do Not Close
18. 18. Detection Design
19. 19. Failure Modes
20. 20. Frequently Asked Questions
21. 21. Summary
22. 22. References

1. Introduction

The decisions this article supports are narrow in scope. You are in a situation where you have an application actively calling a model in production, a pre-defined list of risks, and you need to determine which AWS controls to implement, and how to explain any remaining gaps to your reviewers.

The risk list is publicly available. The OWASP Gen AI Security Project maintains a list of risks specifically for large language model applications, with each item identified by a code from LLM01 to LLM10. This coding system has become the common reference point for citing individual items in threat models, internal standards, and vendor mapping tables.

The controls have documentation too, but it is scattered. The Amazon Bedrock User Guide describes the guardrail policy types, a different chapter of the same guide covers the knowledge base metadata filter, the Service Quotas chapter covers quotas, and the CloudTrail and CloudWatch chapters cover the reach of the audit trail. Each page explains what a particular control is, but none of them explain what risks it mitigates.

However, a table that bridges this gap actually exists, albeit partially, within AWS documentation. This article will not ignore it. Section 16 names that table and states what matches and what does not. Undervaluing existing resources to differentiate this article is the one thing this article most wants to avoid.

1.1 Scope

Included:

• A clarification of why the model-layer list and the agent-layer list are different lists.
• The versions this article references, and the status of each.
• A listing of AWS controls, ordered by request path.
• For each of the 10 items: what happens, the primarily effective AWS controls, the limits of those controls, the remaining risks, and the detection signals.
• The differences from the mapping table published by AWS.
• An in-depth examination of items not fully addressed by AWS controls alone.
• What to query in audit data.
• The failures that occur when the mapping table is read as a checklist.

Excluded:

• Risk items specific to the agent layer. Autonomy adds its own risks around planning, memory, tool invocation, and agent-to-agent communication, and those belong to OWASP Top 10 for Agentic Applications Mapped to AWS Controls. This article is limited to the model layer.
• The multi-layered defense design model itself. AI Agent Defense in Depth Model (AIDDM) outlines where each defense mechanism sits in the lifecycle. That one answers where a control belongs; this one answers which risk it reduces, and how far.
• Implementation steps for guardrails. Details on configuring the policy types, using the APIs, and managing cross-Region profiles live in Amazon Bedrock Guardrails Implementation Deep Dive. This article will not reiterate these procedures but will instead refer to the existing documentation.
• Inspections performed by WAF. AWS WAF Generative AI Prompt Injection Patterns holds the edge-side inspection and its limits. This article does not reproduce those tables.
• Methods for identifying threats. This article assumes the use of publicly available threat lists and focuses on mapping them accordingly. The methodology for identifying system-specific threats is the subject of Threat Modeling Generative AI Applications on AWS.
• The design of the containment boundaries. Where each control stops is stated per entry below, but choosing the unit that a breach is confined to — the execution environment, the credential, the network, the data key, or the lifetime — is the subject of Agent Sandboxing and Blast-Radius Isolation on AWS. This article names the residual risk; that one bounds how far it reaches.
• Costs. Some of the controls discussed may incur charges. This article names no AWS pricing figures, and it neither recommends nor rejects a control on cost grounds.

1.2 Referenced Versions and Their Status

The version label and the date are part of the citation, not decoration. Because the status of this list was somewhat complex as of August 15, 2026, this section states plainly what the check found.

The publisher's LLM Top 10 landing page lists ten items, ranging from LLM01:2025 to LLM10:2025 as of the date of verification. The underlying document is OWASP Top 10 for LLM Applications 2025, which displays Version 2025 and November 18, 2024 on its cover, and also includes 2024-11-18 Version 2025 Release in its revision history.

In contrast, the resource library on the same site holds OWASP GenAI LLM Top 10 2026, published on August 3, 2026, and available as a 122-page PDF. The cover of this document states OWASP Top 10 for LLM Applications 2026 and Version 2026. However, the publication date field remains a placeholder, reading [Publication date to be set], and the final line of the revision history also states [2026 release date] Version 2026 Release. While it does not have explicit labels such as "draft" or "release candidate," it is a fact that it is being distributed before the publication date is finalized. The license is the same as the 2025 edition: CC BY-SA 4.0.

This article maps against the 2026 edition. There are two reasons for this. First, the identifiers are being renumbered, so covering only the 2025 edition would leave readers out of step with the version they face from now on. Second, as mentioned later, the mapping table published by AWS is currently fixed to the 2025 edition, and applying that table to the 2026 edition results in discrepancies in the identifiers. It is this discrepancy that poses a practical risk, and to explain it, it is necessary to present both versions.

If you are reading this article significantly after the verification date, first check the publisher's resource library to confirm whether the publication date has been finalized and whether the identifiers and names remain consistent.

2. The Model-Layer List and the Agent-Layer List Are Different Lists

The OWASP Gen AI Security Project maintains separate lists: one for large language model applications and another for agent-based applications. These two are frequently conflated in the same discussion, which is a primary source of errors in control decisions.

This article focuses on the model-layer list, which addresses risks when the model is a component within an application. This involves sending prompts, receiving responses, and acting upon those responses. The agent-layer list, on the other hand, addresses systems that plan, maintain memory across sessions, call tools, interact with other agents, and act with delegated authority.

The 2026 edition explicitly draws a line between these two. As long as the model remains an internal component within an application, this list owns the associated risks. However, the moment the model can call tools, maintain memory across sessions, and independently produce downstream results, the risks shift to the agent-layer list. The document also notes that many reported incidents fall precisely on this boundary.

In practice the split works like this. If the potential harm can be explained solely by what the model generated, that falls under the scope of the model layer, and the table in this article serves as a reference. If the realization of the harm requires the system to take action, store information, delegate tasks, or exceed a point where human intervention should have occurred, that falls under the scope of the agent layer, and the companion mapping table is the index to use. The definition of the layer boundary itself belongs to the companion article, so refer to that for the detail.

Neither list replaces the other, and neither contains the other. The agent-layer list assumes that the model-layer controls are already in place and focuses on the additional risks introduced by the agent's autonomy. Therefore, completing the table for agent applications does not mean that concerns related to the model layer have been addressed.

3. What Changed Between the 2025 and 2026 Editions

The 2026 edition has altered the method for determining rankings. According to the document, the practitioner vote accounts for three-quarters of the weighting, while records gathered from publicly available vulnerability databases and an AI harm database comprise the remaining quarter. The project pulled together 7,714 incidents, and classifiers sorted the 6,639 that carried enough detail. Discrepancies between the votes and the records have resulted in shifts in the rankings.

Here are some of the most significant ranking changes, along with the document's own explanations. "Excessive Agency" climbed to third place, which the document calls the most consequential move on the list. This was because both the vote and the incident record showed that agentic deployments are where the damage is landing. "Unbounded Consumption" moved up four positions. "Improper Output Handling" experienced the most significant drop, falling from fifth to tenth place. "Prompt Injection" maintained its top ranking. The document notes that if ranked solely by the raw number of incidents, "Prompt Injection" would fall outside the top ten, but explains that this is a result of effective defenses and does not indicate a lower level of risk.

There have also been name changes. "System Prompt Leakage" has been renamed Hidden Context Exposure. This is not simply a name change; the scope has expanded to encompass more than just system prompts. It now includes retrieved policy documents, tool and function schemas, and any other instructions or materials that an application assembles in the context window.

For practical application, it is important to note that some items have been renumbered, meaning they now appear under a different number. The following table shows the correspondence between the two editions.

2025 Edition Identifiers and Names	2026 Edition Identifiers and Names	Change
LLM01:2025 Prompt Injection	LLM01:2026 Prompt Injection	The identifier remains unchanged. The scope has been expanded to include multi-modal instructions, such as those hidden within images or audio.
LLM02:2025 Sensitive Information Disclosure	LLM02:2026 Sensitive Information Disclosure	The identifier remains unchanged. Reasoning traces and observable properties were explicitly added to the disclosure surface.
LLM03:2025 Supply Chain	LLM04:2026 Supply Chain	The identifier has changed. It now adds the failure of trust that occurs when a promoted artifact is not what it claims to be.
LLM04:2025 Data and Model Poisoning	LLM05:2026 Data and Model Poisoning	The identifier has changed. It now absorbs the subversion of fine-tuning.
LLM05:2025 Improper Output Handling	LLM10:2026 Improper Output Handling	Moved from rank 5 to rank 10. The scope now includes potentially unsafe code generated in large quantities by the assistant.
LLM06:2025 Excessive Agency	LLM03:2026 Excessive Agency	Moved from rank 6 to rank 3.
LLM07:2025 System Prompt Leakage	LLM08:2026 Hidden Context Exposure	Renamed and redefined. Expanded to encompass all hidden control contexts.
LLM08:2025 Vector and Embedding Weaknesses	LLM09:2026 Vector and Embedding Weaknesses	The identifier has changed.
LLM09:2025 Misinformation	LLM07:2026 Misinformation	Moved to a higher rank. This item highlighted the greatest discrepancy, with low voting scores but high incident records.
LLM10:2025 Unbounded Consumption	LLM06:2026 Unbounded Consumption	Moved from rank 10 to rank 6.

As you can see from this table, identifiers alone are insufficient to accurately represent risks; the meaning changes as the version changes. If an internal standard or an audit trail records only LLM06, in the 2025 edition it refers to "Excessive Agency," while in the 2026 edition it refers to "Unbounded Consumption." The required controls are entirely different.

This is not a theoretical risk. As shown in Section 16, AWS publishes a mapping table that is fixed to the 2025 edition. When you compare that table with the 2026 edition documentation, the resolution of the reference numbers is inconsistent.

4. How to Read This Mapping Table

Three properties of the table matter before you read the first row. An incorrectly interpreted mapping table is worse than having no mapping table at all.

Each row represents a mitigation, not a resolution. For any of the ten items listed, there are no AWS controls that completely eliminate the risk. Each control simply narrows the conditions under which the risk could lead to harm, and the way it does so is specific to each control. A table that lines up controls against risks and stops there leads the reader to take each row as settled. Therefore, each section below will conclude with a description of the remaining risk. The remaining risk is the core purpose of this exercise, not merely supplemental commentary.

There is a specific distinction between primary and secondary controls. A primary control is the one that must be broken for the risk to reach harm along its most direct path. A secondary control either limits the impact if the primary control fails, or addresses alternative pathways to the same harm. The order is not a ranking of importance. A secondary control often goes in first.

The granularity on the AWS side is specified using the names of services and features. The names used are the ones actually specified in the console and in policies, such as ApplyGuardrail or bedrock:GuardrailIdentifier, rather than chapter numbers from a guide. This is a deliberate difference from the mapping table AWS publishes, as covered in Section 16.

The following table is a condensed version. Each subsequent section will expand upon each row in this table.

ID	2026 Edition Formal Name	What Happens	Primarily Effective AWS Controls	Core Remaining Risks
LLM01	Prompt Injection	Input alters the model's behavior, deviating from the developer's intended direction.	Guardrail prompt attack filters and pre-assessment of retrieved content via ApplyGuardrail.	No mechanism separates instructions from data in the context window.
LLM02	Sensitive Information Disclosure	Sensitive information is exposed to unauthorized parties, regardless of the pathway.	Guardrail sensitive information filters, knowledge base encryption, and the account or project data retention mode.	Reasoning traces and audit logs themselves can become exposure points.
LLM03	Excessive Agency	Unexpected output leads to the execution of potentially destructive actions.	IAM with minimum privileges for the identity used by the tool.	IAM authorizes API calls but does not authorize intent.
LLM04	Supply Chain	Model artifacts and dependencies are not as claimed.	Restriction of intake pathways and control over artifact staging.	Even in secure formats, vulnerabilities may remain embedded within weights and computation graphs.
LLM05	Data and Model Poisoning	Data used for training or retrieval is permanently corrupted.	Encryption of data sources and access control over write pathways.	Contamination that arrives through a legitimate path passes straight through access control.
LLM06	Unbounded Consumption	Inference consumption is uncontrolled, impacting availability and cost.	Bedrock token-based quotas and triggering of budget actions.	Quotas are separate for two inference endpoints and are not user-specific.
LLM07	Misinformation	Incorrect output is trusted, driving decision-making and actions.	Guardrail contextual grounding checks, and Automated Reasoning checks in detect-only mode.	Both checks fail to detect errors resulting from omissions.
LLM08	Hidden Context Exposure	Hidden control context is extracted or reconstructed.	Design that avoids placing sensitive information in prompts.	Design can only assume that hidden context is discoverable.
LLM09	Vector and Embedding Weaknesses	The geometry of the embedding space and similarity search mechanisms are exploited.	Separation of indexes by trust level and key management.	The caller attaches the metadata filter; it is not an authorization boundary.
LLM10	Improper Output Handling	Unvalidated output reaches downstream systems.	No AWS control is decisive here. An application-side layer performs deterministic validation between the model and the downstream system.	Guardrails are unaware of the context to which the output is delivered.

The names follow the 2026 edition.

5. The AWS Control Surface

This section lists the AWS controls in the order a model-layer request travels. Each section below points to somewhere on this control surface. The diagram draws the request path itself, so it carries the inspection points of Sections 5.1 and 5.3. The controls that sit beside that path rather than on it are not drawn: the IAM condition key of Section 5.2, the call-path restriction of Section 5.4, the quotas of Section 5.5, and the audit stores of Section 5.6. Section 5.7 is further out still, describing how data is handled after it has traveled the path rather than any point on it.

5.1 Input and Output Inspection

Create your guardrail lists the policy types that Amazon Bedrock Guardrails offers. As of the verification date:

• Content filters: Detect and remove harmful text or images contained within input prompts and model responses. Categories include Hate, Insults, Sexual, Violence, Misconduct, and Prompt Attack, with adjustable intensity levels for each category. The documentation explicitly states that reasoning content is excluded from the scope. In the Standard tier, detection extends to include code elements such as comments, variable names, and string literals.
• Prompt attacks: Provided as a category within content filters, it detects jailbreaks, prompt injection, and prompt leakage. This is only available in the Standard tier.
• Denied topics: Defines a set of topics to avoid in the application's context, blocking both user inquiries and model responses when detected. As with content filters, the Standard tier extends detection to include code.
• Word filters: Blocks content based on exact matches of specific words or phrases.
• Sensitive information filters: Detects standard formats of personal information and entities defined using custom regular expressions, blocking or redacting them. The documentation describes this as a probabilistic, machine learning-based system that is context-dependent.
• Contextual grounding checks: Verifies whether the response is grounded in the provided sources and relevant to the user's inquiry.
• Automated Reasoning checks: Verifies whether the model's response adheres to logical rules and policies defined in natural language.

The same page includes a note stating that if model invocation logging is enabled, any content blocked by the above policies appears in plain text in the model invocation logs. This note applies to both Section 7 and Section 18.

The ApplyGuardrail API is decoupled from the underlying model calls. It allows you to evaluate any text at any point within your application's flow. The documentation provides RAG (Retrieval Augmented Generation) as an example, stating that you can evaluate user input before retrieving information, rather than waiting for the final response to be generated. Since this is the only inspection point on the AWS side that means anything against indirect injection, the positioning is worth remembering.

5.2 Enforcing the Use of Guardrails

Simply creating guardrails is not enough; they only have meaning if the requesting party specifies them. Enforce the use of specific guardrails in model inference requests explains that by including the bedrock:GuardrailIdentifier condition key in the IAM policy, you can reject any inference API request that does not carry the specified guardrail.

The inference APIs to which this applies are Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream. This scope comes up repeatedly below, so this section states it explicitly.

5.3 Boundaries of Retrieved Data

Amazon Bedrock Knowledge Bases include metadata filters applied at retrieval time. The Retrieve and RetrieveAndGenerate operations allow the use of operators such as equals, greaterThan, lessThan, in, notIn, and andAll in the filter field. However, fully managed Knowledge Bases do not support the startsWith and stringContains operators.

AWS guidance is direct regarding this functionality. The AWS guidance page Providing secure access to data and systems for generative AI states that it is the responsibility of the application or agent to include the correct metadata with each API call to filter results based on the necessary key-value pairs. Section 14 covers the remaining risks that follow from this.

Regarding encryption, the policy is clear. According to Encryption of knowledge base resources, in fully managed Knowledge Bases, a single KMS key, specified during creation, encrypts both the temporary data ingested and the persistent data used for indexing. Bedrock creates a grant for this key and retires it when the knowledge base is deleted. Data encryption notes that model customization jobs, agents, data source ingestion jobs for Knowledge Bases, vector stores in Amazon OpenSearch Service, and model evaluation jobs can all be encrypted with KMS keys. To maintain this security posture, Security Hub CSPM Bedrock.1, along with the AWS Config rule bedrock-data-source-encryption-enabled, continuously monitors whether data sources are encrypted with customer-managed KMS keys.

5.4 Limiting Call Paths

Using interface VPC endpoints (AWS PrivateLink) states that calls to the bedrock, bedrock-runtime, bedrock-mantle, bedrock-agent, and bedrock-agent-runtime APIs can be routed through interface endpoints. bedrock-fips and bedrock-runtime-fips also exist for FIPS compliance, but AWS offers them in only six Regions. An endpoint policy can also narrow access to specific base model ARNs and specific principals.

5.5 Usage Limits

According to Quotas for Amazon Bedrock, quotas on token usage control model inference in Amazon Bedrock. Amazon Bedrock provides two inference endpoints: bedrock-runtime and bedrock-mantle, and each endpoint has independent quota allocations for each model. Even when calling the same underlying model, traffic to the two endpoints is counted against separate quotas.

bedrock-runtime Endpoint Quotas combines input and output tokens for each model into a single quota. bedrock-mantle Endpoint Quotas applies separate quotas for input tokens per minute and output tokens per minute. Furthermore, it notes that additional rate limits, not visible in Service Quotas, may also be applied internally.

The handling of requests per minute differs between the two endpoints and is not consistent. For bedrock-runtime, the requests per minute quota is model-specific, and the documentation states that it applies to some models but not others, providing examples of models where it does not apply. bedrock-mantle does not apply any requests per minute quota; it is solely limited by token quotas. Furthermore, the number of tokens per minute is only publicly available for the models listed in a table; the processing capacity for other models is determined by internal service capacity and is not reflected in Service Quotas.

To prevent costs from exceeding a certain level, budget actions are available. These actions can automatically or manually apply IAM policies or SCPs, or target specific instances, when a threshold is exceeded. A threshold can sit on actual usage or on forecast usage.

5.6 Auditing and Visibility

The model invocation logs defined by Monitor model invocation using CloudWatch Logs and Amazon S3 collect the complete set of data, including request data, response data, and associated metadata. By default, this feature is disabled. The supported destinations are CloudWatch Logs and Amazon S3, and both must sit in the same account and Region. The operations tracked include Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream.

The documentation explicitly states that model invocation logs are only supported for calls made via the bedrock-runtime endpoint. Calls made through other endpoints, such as the Responses API for the bedrock-mantle endpoint, are not currently captured. This is a prerequisite for both Section 11 and Section 18.

The example of InvokeModel logging shown by Monitor Amazon Bedrock API calls using CloudTrail indicates that the eventCategory is Management, the requestParameters only include modelId, and the responseElements are null. CloudTrail records that a call occurred; it does not keep what was sent. When using cross-Region inference, the log entry is stored in the originating Region, and the additionalEventData includes the inferenceRegion which specifies the Region where the actual processing took place.

However, this description refers to the bedrock-runtime endpoint. A separate page documents the CloudTrail logs for bedrock-mantle, and Monitor bedrock-mantle API calls using CloudTrail outlines three key differences. First, inference operations are recorded as data events, rather than management events. While bedrock-runtime continues to log certain actions, such as Converse, as management events without additional charges, bedrock-mantle treats inference operations, including CreateInference, as data events. Therefore, if you require a log trail, you must explicitly enable the collection of data events. Second, the eventSource is bedrock-mantle.amazonaws.com, and the resource type begins with AWS::BedrockMantle::. The documentation clearly states that queries and detection mechanisms within CloudTrail Lake that are filtered by bedrock.amazonaws.com or bedrock-runtime.amazonaws.com will not capture the activity of bedrock-mantle. Third, any customer-side metadata associated with CreateInference is recorded verbatim in CloudTrail, so if you are collecting data events, you must not include any sensitive information within that metadata.

As data events within CloudTrail, resource types are available for Bedrock agent aliases and knowledge bases. Within CloudWatch, you can retrieve runtime metrics, including Invocations and InputTokenCount, at a one-minute granularity. For guardrails, you can view metrics categorized by GuardrailPolicyType.

Regarding the relationship with model providers, Data protection in Amazon Bedrock explains that a separate model deployment account exists for each model provider within each Region. The Amazon Bedrock service team operates these accounts, and providers have no access to them. Furthermore, providers do not have access to Bedrock logs, nor do they see customer prompts or responses.

5.7 Data Retention Modes

The statement that Amazon Bedrock does not store any input or output is no longer unconditionally true. Getting this point wrong distorts the whole of Section 7, so read the following two pages separately.

Amazon Bedrock abuse detection outlines the default settings. Amazon Bedrock employs a zero-operator access data security model, meaning that service operators do not have access to either the model's input or its output. It also runs a zero data retention model, so by default the service stores neither input nor output. However, the same page also lists exceptions. For several OpenAI GPT-5 models, classifier-flagged traffic stays for up to 30 days for automated offline abuse detection. For Anthropic Claude Fable 5, inputs and outputs stay for up to 30 days. Using this model requires agreeing to share the retained traffic with Anthropic for abuse detection and human review. Under cross-Region inference, retained inputs and outputs land in the destination Region, meaning the Region that processed the request.

Data retention defines user-configurable settings. Retention runs on a mode rather than a simple on/off switch, set at the account scope or the project scope, and it applies consistently across the Messages, Chat Completions, and Responses APIs. The available modes are default, provider_data_share, none, and inherit. New accounts and projects begin with the inherit mode. The effective mode is the first non-inherit value reading project, then account, then the model's own default.

Three properties of that page change how you design.

First, each model declares the modes it allows, using a setting called allowed_modes. If the effective mode is not among the model's allowed modes, the model appears as status: "unavailable" and requests to it get blocked. The documentation provides examples of Claude Fable 5 and Claude Mythos 5, which only allow the provider_data_share mode, making them unavailable to any account whose effective mode is not provider_data_share. In this case, rejecting data retention and using the model are mutually exclusive.

Second, even when specifying store=false in the Responses API, zero retention is not guaranteed. The documentation states this directly. Even with store=false, some models still retain data for safety review, in which case the data is retained but simply stops being retrievable by the customer. True zero retention is only guaranteed by setting data_retention_mode to none; it is not achieved through the store setting.

Third, the mode can be configured organization-wide through SCP (Service Control Policies). Write operations expose the bedrock-mantle:DataRetentionMode condition key, so by creating a condition that rejects anything other than none, no one in the organization can turn data retention on. The Bedrock control plane has a corresponding setting: bedrock:DataRetentionMode. At launch there is no console screen for this setting, so it is configured through the API or the SDK.

6. LLM01:2026 Prompt Injection

What happens? Input to the model alters the model's behavior in ways unintended by the developers. This input is not limited to what users directly type; it can include retrieved documents, tool outputs, images, audio, video, intermediate reasoning, or even persistent memory. The document states the root cause plainly. Large language models do not structurally differentiate between "instructions" and "data," treating both as the same sequence of tokens. Consequently, there is no clean equivalent to parameterized queries.

Primarily effective AWS controls. The Prompt Attack category inside the guardrail content filters detects jailbreaks, prompt injection, and prompt leakage. This category is only available in the Standard tier, meaning your tier selection directly determines whether this protection is enabled. For indirect injection, evaluating the retrieved content with ApplyGuardrail before it enters the context window is very nearly the only position AWS makes available. Evaluating the response after generation means the injection has already succeeded.

Secondary controls. Add the bedrock:GuardrailIdentifier condition key to the IAM policy to explicitly reject inference requests that carry no guardrail. Use PrivateLink endpoint policies to narrow which principals can call which models.

Limitations of mitigation. There are three key limitations. First, the content filters leave reasoning content out of scope, so injections that travel the reasoning path, and the traces they leave there, are not inspected. Second, the enforcement provided by bedrock:GuardrailIdentifier only applies to the four inference APIs previously mentioned. If an application reaches the model through RetrieveAndGenerate or agent calls, that IAM policy alone will not provide enforcement. Third, and most importantly, the document itself states that prompt injection is an inherent vulnerability in current generative AI systems, and that no truly reliable preventative measures currently exist. For adaptive attackers – those who have read the specifications of deployed defenses – classifiers are merely a means of reducing probability, not a definitive barrier.

Remaining risks. Some of this only the application can do. Strip invisible characters at every ingest and render boundary. Keep credentials and state-changing capability in the application code rather than in the model, and give each operation the least privilege it needs. Before any irreversible or externally visible action, present the actual content that runs rather than a summary, and require human confirmation. AWS offers no control that separates instructions from data inside the context window. This is not necessarily a deficiency of AWS, but rather a limitation inherent in current technology.

Detection signals. Analyze CloudWatch metrics, categorized by GuardrailPolicyType, to monitor the guardrails. A change in the blocking patterns can be an indicator. While the model invocation logs retain the blocked content in plain text, as mentioned later, this itself presents a potential disclosure risk. CloudTrail records the occurrence of calls but does not record their content, making it unsuitable for injection detection.

7. LLM02:2026 Sensitive Information Disclosure

What happens? Confidential, regulated, privileged, or proprietary data could leak through channels not approved by the data subject or administrator. The 2026 edition broadens the definition of these potential channels. Disclosure now encompasses not only the final response, but also arguments for tool calls, reasoning traces, retrieved chunks, multi-modal outputs, logs, telemetry, embeddings, and even externally observable characteristics such as response time, token length, and log probabilities.

Primarily effective AWS controls. Guardrail sensitive information filters detect and block or redact entities represented by standard formats and custom regular expressions. On the retrieval side, encryption using KMS customer-managed keys for the knowledge base, and maintaining posture through Security Hub's Bedrock.1 and corresponding Config rules, are effective. PrivateLink closes the call path. Underneath all of it sits the data retention mode of Section 5.7. The account or project mode decides whether AWS keeps the prompt at all, and an SCP on the bedrock-mantle:DataRetentionMode condition key pins that decision across the organization.

Limitations of mitigation. For this item the limits carry more information than the protections do.

First, filters are probabilistic. The documentation itself states that the sensitive information filters are context-dependent, probabilistic, and based on machine learning. The custom regular expressions are defined by the customer, and configuring patterns that fit the use case is the customer's responsibility.

Second, content filters do not address reasoning content. The 2026 edition treats reasoning traces as a primary output and advocates for their classification and redaction. Guardrail content filters do not address this aspect.

Third, and perhaps most easily overlooked, blocked content appears in plain text in model invocation logs. In other words, turning logs on for audit puts inputs that contain sensitive information into one more store. The documentation acknowledges this and says you can turn the logs off if you do not want blocked content sitting there in plain text. Protection and visibility collide head-on here, so encryption and access control on the log destination deserve the same priority as the guardrail work itself.

Fourth, the model invocation logs only capture calls made through bedrock-runtime. The logs you rely on can miss the endpoints you actually use. Furthermore, on the bedrock-mantle side, the metadata attached to CreateInference is faithfully recorded in CloudTrail. Disclosure concerns extend beyond the main text to include the values associated with each call.

Fifth, zero data retention is not an inherent feature of the service, but rather a conditionally applied setting. As detailed in Section 5.7, the default is zero retention, but specific exceptions are defined, and the actual behavior is determined by the account or project mode, as well as the modes permitted by the model. Some models only allow provider_data_share, so setting the organization to none will not keep the data confidential; it will simply render the model unusable. The Responses API's store=false setting alone does not guarantee zero retention. In cross-Region inference, retained inputs and outputs are stored in the destination Region, while CloudTrail and model invocation logs remain in the originating Region. The audit trail and retained payloads are therefore routed to different locations.

Remaining risks. Authorize access before, rather than after, data retrieval. Enforce the document-level and chunk-level decision inside the index query. Classify reasoning traces as a primary output and avoid directly streaming raw data to an unconstrained observability platform. Implement query budgets at the user and session levels for highly sensitive endpoints. Treat backups of the embeddings with the same sensitivity as the source documents. None of these is a switch in AWS.

Detection signals. Trends in the sensitive information policy dimension of the guardrail metrics. Records of access to the S3 bucket used for log storage. CloudTrail data events related to the knowledge base.

8. LLM03:2026 Excessive Agency

What happens? Destructive actions may be executed based on unexpected, ambiguous, or manipulated outputs. The document categorizes the root causes into three: excessive functionality, excessive permissions, and excessive autonomy. This section deals with the permissions a model holds as a component of an application.

Primarily effective AWS controls. The center of this is least privilege on the IAM role a tool uses to reach downstream systems. Two of the mitigation strategies outlined in the document can be implemented within AWS.

1. Minimize tools
5. Execute tools in user's context

In practice that means a separate execution role per tool, so that a tool which only reads never carries write permissions.

Secondary controls. A session policy narrows temporary credentials further. Operations that require human approval go through a deterministic path outside the model.

Limitations of mitigation. IAM authorizes API calls; it does not authorize intent. Even a role limited to s3:GetObject on a single bucket allows access to all objects within that bucket. The document provides an example:

a tool to read the current user's document store connects to the document repository
with a privileged account that has access to files belonging to all users

This scenario could still occur even with the correct application of AWS's principle of least privilege. While AWS's permission granularity extends down to the resource level, it does not automatically extend to the level of the individual user who initiated the request.

Remaining risks. Maintaining the original user's context and authorization scope across delegated processes and multi-stage tool calls. Complete mediation, meaning a mechanism that checks every downstream request against policy, belongs in code rather than in the model. Tiered enforcement, automatically approving reversible operations while routing irreversible ones to a human. All of these are application design.

Escalation to the agent layer. The autonomy that accumulates, potentially leading to tool misuse, abuse of identities and permissions, and cascading failures, is addressed by the companion agent-layer mapping table.

Detection signals. The clue shows up not in Bedrock logs but in the CloudTrail of the downstream service. Tool misuse appears as the API call that the model's output caused, not as the model call itself.

9. LLM04:2026 Supply Chain

What happens? The integrity of training data, models, adapters, transformation pipelines, and deployment infrastructure is compromised. The 2026 edition treats model artifacts, their provenance, and transformation and integration workflows as primary attack surfaces.

Primarily effective AWS controls. These controls narrow what an application takes in. Custom model import requires model files in the Hugging Face weights format, with the weights themselves stored in the Safetensor format under a .safetensors extension. For this path, that removes the problem of the older serialization formats, where arbitrary code runs at load time. S3 versioning and object lock pin the artifact handoff, and CloudTrail records the ingestion jobs. If you operate your own inference infrastructure, vulnerability scanning of container images becomes necessary.

Limitations of mitigation. While safe serialization formats prevent code execution during loading, they do not stop a payload embedded in the weights or the computational graph. The document specifically addresses this point, noting that a backdoor embedded in a model's computational graph persists even in formats widely considered safe. It also notes that weights can be crafted so that the full-precision model evaluates benignly while only the quantized artifact exhibits the behavior the attacker chose. In addition, AWS does not provide a mechanism to present users with the results of signature verification for third-party model artifacts. A successful import does not guarantee that the artifact behaves as claimed.

Remaining risks. Maintain a bill of materials that extends to models, adapters, and datasets. Refer to artifacts using immutable digests rather than mutable tags. Use signatures and transparency logs to link artifacts to their signers. Then, on the premise that a signature shows integrity and origin but not safety, evaluate behavior before promotion. These are all aspects of pipeline design, and not configurations within AWS itself.

Detection signals. Monitor CloudTrail for model import jobs and S3 object writes. There are no AWS-provided signals that indicate a model exhibits different behavior for specific inputs.

10. LLM05:2026 Data and Model Poisoning

What happens? Data or artifacts are modified at any stage – pre-training, fine-tuning, embedding creation, retrieval augmentation, or model distribution – introducing harmful behavior, biases, or exploitable vulnerabilities into the system. The document emphasizes that this contamination targets the learning process itself and cannot be corrected by simply modifying code. It requires re-validation of the data, replacement of the model, or rebuilding of the pipeline.

Primarily effective AWS controls. The boundaries around the data are what matter here. S3 bucket policies and KMS customer-managed keys for knowledge base data sources, along with continuous monitoring through Security Hub's Bedrock.1 and Config rules, control the ingestion pathways. CloudTrail records ingestion jobs as data events, and S3 versioning gives you the ground to roll back to.

Limitations of mitigation. Encryption and access control prevent unauthorized writers, but they do nothing to prevent authorized pipelines from ingesting contaminated content. The document cites results showing that as few as 250 contaminated documents can compromise models ranging from 600 million to 13 billion parameters, regardless of the dataset size. As long as the ingestion pathways are legitimate, the activity appears normal from AWS's perspective.

Remaining risks. Track the provenance of each document, assess the source's reputation, and conduct manual reviews of external content. Validate automated retraining and evaluation processes, placing them under human oversight and rate limiting. At each alignment cycle, probe specifically for hidden triggers. Treat inference artifacts – such as chat templates, tokenizer configurations, adapters, and quantization results – with the same level of scrutiny as executable code, subjecting them to signing and differential verification.

Detection signals. CloudTrail entries for ingestion jobs show that a synchronization occurred, but they do not show what changed in meaning. Detection has to sit on the content itself, before ingestion.

11. LLM06:2026 Unbounded Consumption

What happens? Inference execution becomes uncontrolled, leading to reduced availability, unsustainable costs, or widespread model replication. The document frames the character of this threat as a cost asymmetry. It describes a scenario where attackers can trigger disproportionately expensive computations for the defender, while incurring only minimal costs themselves. Advanced reasoning models, multi-modal inputs, and architectures where a single request can trigger numerous downstream operations amplify this effect.

Primarily effective AWS controls. Amazon Bedrock quotas are token-based and applied on a per-model and per-Region basis. Quotas for requests per minute also exist, but as Section 5.5 notes, on bedrock-runtime they apply to some models and not others, and on bedrock-mantle they do not apply at all. On the cost side, budget actions apply an IAM policy or a Service Control Policy on crossing a threshold and stop the calls. A threshold can sit on actual cost or on forecast cost.

Secondary controls. Alarms configured on CloudWatch metrics for Invocations and InputTokenCount. Limiting invocation sources through PrivateLink endpoint policies. Rate limiting at the application edge.

Limitations of mitigation. The inherent structure of AWS itself creates limitations.

First, quotas are applied separately for two inference endpoints. Imposing a limit on bedrock-runtime does not prevent traffic originating from bedrock-mantle for the same model, which is subject to a separate quota. Looking at only one of them and concluding that a ceiling is in place is a mistake. Furthermore, the documentation states that additional, internal rate limits may be applied to bedrock-mantle that are not visible in Service Quotas, making it impossible to fully determine the effective upper limit based solely on the visible settings.

Second, quotas are defined at the account and Region level, not at the tenant, user, or session level. A single user piling up consumption while staying inside legitimate limits is not stopped by these ceilings.

Third, budget actions react to cost signals, resulting in delays. Costs are aggregated and become apparent over time, making it impossible to proactively prevent rapid accumulation of consumption.

Remaining risks. Token budgets at the user and session levels. Rejecting requests based on estimates provided before inference begins. Setting limits on the number of operations, recursion depth, time, and tokens per execution. The document highlights scenarios involving agent-based sessions where context accumulates over time.

Per-turn cost climbs as the context grows, from roughly $0.001 on the first turn
to about $0.50 by turn 100. No single request triggers rate limits because each
stays individually within budget, yet the aggregate across many concurrent or
long-lived sessions reaches hundreds of dollars.

This pattern is completely invisible from the perspective of individual request limits. While each individual request stays inside the budget, the total amount increases as the system reprocesses the accumulated context with every request. Only application-level accounting, managed on a session basis, can prevent this.

Detection signals. CloudWatch runtime metrics are available with one-minute granularity. The Service Quotas console displays configured quotas, but does not show actual usage. CloudWatch is where you watch actual usage.

12. LLM07:2026 Misinformation

What happens? Models generate inaccurate, incomplete, unsubstantiated, or misleading information, presenting it in a credible manner, and this information drives human decisions, automated processes, or agent actions. The core danger is not the error itself, but the fact that this error is trusted and acted upon. The 2026 edition treats this item as the one where the largest discrepancy appeared, with the vote scoring it low and the incident record scoring it high.

Primarily effective AWS controls. Guardrail contextual grounding checks verify whether a response is grounded in the sources provided and whether it is relevant to the user's query. In a RAG configuration, these checks block or flag responses that stray from the retrieved documents. Another distinct control mechanism is Automated Reasoning checks, which mathematically verify whether a model's response adheres to rules expressed in natural language. The checks return their results as findings in the Converse, InvokeModel, and standalone ApplyGuardrail responses.

Secondary controls. The citations returned by RetrieveAndGenerate allow users to trace each part of a response back to the specific chunks from which it originated.

Limitations of mitigation. There are two primary limitations.

First, grounding checks verify the response against its sources. If the sources are wrong, a correctly grounded error passes through. This check offers no protection against polluted retrieval corpora. The issues addressed in Sections 10 and 14 remain as underlying assumptions for this section.

Second, Automated Reasoning checks carry four constraints that bite as soon as you try to apply them to this item. These are the ones the documentation lists itself.

The checks only evaluate the rules that have been explicitly defined. The documentation states that a VALID result only guarantees that the portion of the response interpreted as policy variables is correct; claims outside of those variables are not verified. Furthermore, this is a detection-only feature and does not block content. It returns findings and provides feedback, leaving it to the calling system to decide whether to output the response, rewrite it, or seek confirmation from the user. Therefore, relying on this feature to guarantee the absence of errors is not a valid assumption. Additionally, it does not support streaming APIs and can only verify completed responses. Finally, there are availability constraints. According to the documentation, as of the verification date, it is generally available in only six Regions, and it only supports US English. It is not a viable option for multilingual applications or configurations that operate in unsupported Regions.

Remaining risks. Separate generation and execution, and act only after validating claims. Demand structured output with required fields to catch errors caused by omissions. That is the decisive point. Both grounding checks and automated reasoning only verify the correctness of what is written; they do not detect instances where something that should have been written was omitted. The failure, as described in the document, where contraindications are missing from a clinical summary, bypasses both types of checks. Validation and approval pathways for high-impact operations also remain on the application side.

Detection signals. The rate at which grounding checks block a response, and any shift in that trend. Responses that are fluent, confident, wrong, and yet were not blocked. AWS has no signal for that. Detection in this area relies on correlating results downstream.

13. LLM08:2026 Hidden Context Exposure

What happens? Control-related context that users are not intended to see, but which is visible to the model, is extracted, inferred, or reconstructed. This may include system prompts, developer instructions, retrieved policy documents, and the schemas of the tools and functions that an application exposes to the model. The 2026 edition expands the earlier "System Prompt Leakage" item and states the design premise as follows.

Practitioners should design under the assumption that hidden context is discoverable
and that any contents of the context should not be considered a secret.

Primarily effective AWS controls. The primary control here is a design decision, not a service feature. Do not embed credentials, connection strings, or tokens in prompts. Within AWS, this means keeping values away from the model and instead storing them in services like AWS Secrets Manager or the AWS Systems Manager Parameter Store, allowing application code to retrieve and use them.

Secondary controls. The Prompt Attack category in the guardrails covers prompt leakage as a detection target. Word filters can block specific strings based on exact matches.

Limitations of mitigation. The Prompt Attack category is only available in the Standard tier and operates probabilistically. Because word filters rely on exact matches, paraphrasing of policy documents may bypass them. The document's own mitigation rests on keeping sensitive data out of the hidden context and on assuming that all of the context is discoverable. The goal is not to prevent leakage, but rather to ensure that even if leakage occurs, it has minimal impact. This determination, that it is not a problem that can be completely resolved through controls, was already made in the source documentation.

Remaining risks. Implement authorization, separation of privileges, and enforcement of content policies in deterministic mechanisms outside the model. Design tool schemas with the understanding that they can be discovered. If different roles require different levels of access, separate authorization contexts and grant only the necessary permissions for each.

Detection signals. Guardrail metrics. However, there are no signals to indicate that an attacker has reconstructed a tool's schema through conversation. Detection for this item is inherently weak, which is why the design must be adapted to anticipate potential leakage.

14. LLM09:2026 Vector and Embedding Weaknesses

What happens? The mechanisms used to convert text, images, code, and audio into numerical representations, and which decide through similarity search what the model gets to see, are themselves what the attacker exploits. The document clearly distinguishes this from prompt injection, focusing instead on the geometry of the embedding space and the mechanisms used for similarity search. A key observation is that many of these attacks work on content that carries no malicious instruction at all.

Primarily effective AWS controls. Index separation by trust zone carries most of the weight here. In Amazon OpenSearch Serverless, before a collection can be created, encryption policies, network policies, and data access policies must be in place. This aligns with the document's guidance, which emphasizes achieving physical separation to eliminate potential misconfiguration pathways, rather than relying on classification tags within a shared index. KMS customer-managed keys on the knowledge base cover the key side.

Secondary controls. Knowledge base metadata filtering. Access controls on the S3 side for the source corpus.

Limitations of mitigation. This is the most important limit in this article. The caller attaches the metadata filter, and it is not an authorization boundary that the server enforces. AWS's guidance explicitly states that it is the responsibility of the application or agent to attach the correct metadata to each API call. Furthermore, AWS's own documentation lists unauthorized access to sensitive information through inadequate access controls among the risks specific to RAG systems.

This is not coincidental; it matches exactly what the 2026 edition names as the first mitigation for this item. The document recommends enforcing tenant scoping inside the index query and validating it on the server side.

Enforce tenant scoping inside the index query, not as a post-retrieval filter,
and validate it server-side. A client-supplied scope is a suggestion, not a control.

If even a single filter is missed, it will not function as a boundary.

Remaining risks. Server-side validation of scope. Access control at the chunk level. Maintaining a record of the provenance for each embedding. When a source document is deleted, deleting the corresponding embedding within a limited timeframe and verifying this during audit processes. Treat backups of the vector database with the same sensitivity as the source documents. When replacing embedding models, rebuild the entire corpus.

Detection signals. Data events in CloudTrail related to the knowledge base. Access logs from OpenSearch. Neither one shows an anomaly in the embedding space. Anomaly detection during ingestion and retrieval remains an area that must be developed independently of AWS.

15. LLM10:2026 Improper Output Handling

What happens? Content generated by the model is passed to downstream components without validation or sanitization. The document clearly distinguishes this issue from Misinformation, which deals with output that is wrong, and instead focuses on the inadequate handling of the output before it is passed to downstream systems. The result shows up as XSS and CSRF on the browser side, and as SSRF, privilege escalation, and arbitrary code execution on the backend.

Primarily effective AWS controls. To put it plainly, no AWS control is decisive for this item. While guardrails inspect content based on categories of potential harm, they do not examine whether a particular string is safe to pass to a shell, browser, or database. Therefore, the primary control involves placing a layer that performs deterministic validation between the model's output and the downstream execution environment. On AWS, that position takes an AWS Lambda function or a policy engine. If the destination is a browser, an Amazon CloudFront response headers policy delivers the content security policy.

Limitations of mitigation. Even output that passes all guardrail policies can still be a valid and destructive SQL statement. Guardrails do not have a concept of the destination context. The same string that is harmless when written to a log viewer could be fatal when passed to a shell – this distinction falls outside the scope of guardrail protection.

Remaining risks. Almost all mitigation efforts remain on the application side. This includes destination-specific encoding, parameterization during database operations, and sanitization of control characters before writing to terminals, log viewers, or integrated development environments. In chat UIs and integrated development environments, it is crucial to prevent model output from triggering automatic external data retrieval. Specifically, this means disabling Markdown image and link previews, and embedded frames by default, and only enabling them with explicit whitelisting or by routing them through a server-side retrieval mechanism.

Detection signals. The clue shows up not in Bedrock logs but in the logs of the downstream execution environment. The records held by the database, the shell, and the browser are the primary source.

16. Differences from the Mapping Table Published by AWS

AWS has already published a mapping table corresponding to the OWASP list for LLMs. AWS Prescriptive Guidance, specifically Security for agentic AI on AWS, states in its introduction that its best practices align with the OWASP Top 10 for Large Language Model Applications, and it actually has a page titled Mapping to OWASP top 10 for LLM applications.

This table is valuable, and this article is not intended as a replacement for it. However, there are three key differences.

First, the version is fixed at the 2025 edition. The page explicitly references the OWASP Top 10 for LLM Applications 2025, and the order of items remains consistent with that edition. For example, LLM03 is mapped to Supply Chain, LLM05 to Improper Output Handling, LLM06 to Excessive Agency, and LLM07 to System Prompt Leakage.

Second, what each risk maps to is not an AWS service name but a best-practice number from the guide itself. It lists items such as 1.2 Determine agent scoping and 6.2 Apply defense-in-depth principles. While easy to read as design guidance, it does not directly translate to specific settings within a console.

Third, the page does not include descriptions of residual risks. It explains which best practices contribute to which risks, but it does not specify what risks remain once you implement them.

Of these three differences, the most practically concerning is the first one. The same number can have different meanings in the two different documents.

Identifier	Resolution on AWS Public Page (2025 Edition)	Resolution in 2026 Edition Document
LLM03	Supply chain	Excessive Agency
LLM04	Data and model poisoning	Supply Chain
LLM05	Improper output handling	Data and Model Poisoning
LLM06	Excessive agency	Unbounded Consumption
LLM07	System prompt leakage	Misinformation
LLM08	Vector and embedding weakness	Hidden Context Exposure
LLM09	Misinformation	Vector and Embedding Weaknesses
LLM10	Unbounded consumption	Improper Output Handling

Any internal document that cites identifiers alone has its meaning swapped in one of these eight rows. Only LLM01 and LLM02 remain consistent across both editions.

Therefore, there is only one way to operate a mapping table: always include the edition and name along with the identifier. Instead of writing LLM06, write LLM06:2026 Unbounded Consumption. The :2026 suffix is specifically included in the 2026 edition to serve this purpose.

AWS also has documentation that organizes model layer design guidelines from a perspective of capabilities rather than risks. The Security section of the Generative AI Lens in the AWS Well-Architected Framework highlights key areas such as endpoint security, response validation, event monitoring, prompt security, excessive agency, and data poisoning. It does not line up one-to-one with the OWASP names, but it is a useful index when you want to dig in using AWS's own vocabulary.

17. Three Items That AWS Controls Alone Do Not Close

Of the ten items, there are three areas where even with proper configuration of AWS controls, fundamental aspects of the application's design remain critical. These three areas are often mistakenly believed to be resolved solely through AWS settings, particularly when prioritizing tasks.

17.1 LLM10 Improper Output Handling Lives Almost Entirely in the Application

As mentioned in Section 15, guardrails are unaware of the context where the output is delivered. The safety of the output is not determined by what the string itself is, but by where it is sent. The same response could be harmless if read by a person, but potentially catastrophic if passed to eval. That judgment can only be made outside the model, and not at the point that calls the model but immediately before the output reaches its destination.

The practical consequence shows up in how you set priorities. While configuring guardrails may seem to show visible progress, it does not address this issue. The core task is a tedious and seemingly endless process: meticulously listing every piece of code that receives the model's output and implementing appropriate encoding and validation for each specific destination.

17.2 LLM09 Metadata Filters Are Not Designed as Authorization Boundaries

As mentioned in Section 14, the application attaches the knowledge base metadata filter on every call. Therefore, filtering cannot be managed as a simple binary on/off setting. If ten paths call retrieval, you need a mechanism that guarantees the correct filter goes on at all ten. A single omission in any one path does not just represent a failure within that specific path; it exposes the entire index.

There are two practical design options. One is to consolidate the paths that call retrieval into a single internal function, and to build the filter inside that function from the user's principal, so that callers never supply the filter themselves. The other option, for highly sensitive data, is to forgo shared indexes and instead separate the indexes themselves based on tenant or trust level. The latter approach eliminates the potential for misconfigured paths entirely, which is why the 2026 edition prioritizes index separation over classification tags.

17.3 LLM06 Limits Do Not Align with Application-Level Units

As mentioned in Section 11, Bedrock's quotas are defined by account, Region, model, and endpoint, and are separate for two inference endpoints. Applications, however, need to track usage based on units such as users, tenants, sessions, and executions. These two systems of measurement are incompatible.

So a design that says the quota is set, therefore consumption is under control, does not survive review. Quotas protect the account, while the application's accounting system protects the users. A situation where only account-level quotas are in place allows a single user to exhaust the account's limit, potentially impacting all users. The context growth in long-lived sessions that the document describes is exactly this scenario.

18. Detection Design

Design detection around which store carries which signal, not around whether you collect logs. Amazon Bedrock has places where this correspondence runs against intuition, so it is set out in a table here.

18.1 Which Store Holds Which Signal

Store	Information Available	Information Not Available
AWS CloudTrail (Management Events - bedrock-runtime)	Details of invocations, the initiator of the call, modelId, and the actual processing Region (if cross-Region inference)	The prompt sent and the response received. responseElements is null.
AWS CloudTrail (Data Events - bedrock-mantle)	Inference operations such as CreateInference, the model used, and the customer-provided metadata.	No information is available by default. It will not appear even when filtering by bedrock.amazonaws.com or bedrock-runtime.amazonaws.com.
Amazon Bedrock model invocation logs	The complete request data, response data, and associated metadata, including content blocked by guardrails (in plain text).	No information is available by default. Calls made via the bedrock-mantle endpoint are also excluded.
Amazon CloudWatch Runtime Metrics	Invocations and InputTokenCount at a 1-minute granularity.	The content of individual requests, and a breakdown of who used them.
Guardrail CloudWatch Metrics	The number of interventions and trends, categorized by policy type.	Inputs that bypassed the guardrail. Specific events in the reasoning content.
CloudTrail data events (knowledge bases and agent aliases)	Operations performed on knowledge bases and agent aliases.	Anomalies in the embedding space. The validity of the results obtained.
CloudTrail and Application Logs of Downstream Services	Operations executed as a result of tool calls.	The link back to which model output produced them.

18.2 What to Query

From the table above, the queries worth building look like this:

1. Inference requests that carry no guardrail. If the bedrock:GuardrailIdentifier condition key is denying such requests, the denial itself lands in CloudTrail. Any change from zero in the number of rejections indicates an increase in unexpected invocation paths.
2. Unexpected models or Regions. Compare the modelId in CloudTrail's requestParameters and the inferenceRegion in additionalEventData against the approved combinations.
3. Trends in intervention by policy type. An increase in interventions related to sensitive data policies suggests a change on the input side.
4. Usage growth. Arrange for InputTokenCount to be available in a per-principal dimension. Service Quotas only display configured limits, so this is the only place to track actual usage.
5. Access to log storage. If you have model invocation logging on, monitor access to the S3 bucket and the CloudWatch log group, treating it with the same level of scrutiny as direct access to sensitive data.
6. Whether the trail covers the endpoints actually in use. This one checks the premise behind the other queries. On bedrock-mantle inference lands as a data event, so nothing reaches the trail until you turn data event capture on, and detections that filter on eventSource never fire. The five queries above mean something only inside the reach of the trail you actually have.

18.3 Limitations of Detection

Of these ten items, several cannot be detected from AWS signals at all, as a matter of principle. This section names them.

• Injections that pass through without being blocked. By definition, if they are not blocked, they will not appear in intervention metrics.
• Fluent and confident errors. Once they pass the guardrails, no signal appears.
• Reconstruction of the tool schema through conversation. Each individual request is, in itself, valid.
• Retrieval hijacking that exploits the geometry of the embedding space. The retrieval record remains an ordinary search.
• Models that change behavior only on a specific trigger. Their record in normal operation is completely normal.

For these cases detection is not available, and the only remaining option is to close the gap through design. The three deep dives in Section 17 are, in that sense, the counterpart to this section.

19. Failure Modes

Here is a list of failures that actually occur when the mapping table is put to use. These failures do not stem from the table itself, but rather from how it is interpreted.

Treating guardrails as the sole security control. Guardrails represent probabilistic checks and do not constitute a boundary against adaptive attackers. The primary source itself states that no reliable prevention mechanism against prompt injection exists in current generative AI. Guardrails lower the probability that an attack succeeds; they do not make success impossible.

Referring to identifiers alone. As shown in Section 16, the meaning of eight items can change depending on the version. When referencing internal standards, audit trails, or tickets, always include both the version and the name.

Widening the disclosure surface in the name of audit. Enabling model invocation logs can result in blocked content being stored in plain text in a different location. Deciding to enable it and designing the encryption and access control of its destination are one task, not two.

Assuming quotas represent a user-level limit. Quotas are defined at the account, Region, model, and endpoint levels. Furthermore, two different inference endpoints have separate quota limits.

Believing that not storing data is an inherent characteristic of the service. While the default is zero retention, specific exceptions are defined, and the actual behavior is determined by a combination of the account or project mode, and the modes permitted by the model. Some models only allow provider_data_share, and setting store=false in the Responses API alone does not guarantee zero retention.

Reading the metadata filter as an implementation of authorization. The caller attaches it. Paths where filters are omitted will not function as a boundary.

Assuming that grounding checks eliminate errors. Grounding checks compare against a source. If the source is compromised, a correctly grounded error can still pass through. Conversely, neither check catches an error of omission.

Believing that either the agent-layer table or the model-layer table is sufficient. The two lists are neither replacements nor subsets of each other. The agent-layer list is written on the assumption that the model-layer controls are in place.

Reading the mapping table as a checklist. This is the final and most significant failure. Every row still carries residual risk. If the "Core Remaining Risks" column is empty, it does not mean there is no risk; it means the analysis is incomplete.

20. Frequently Asked Questions

Does implementing this mapping table mean you are compliant with something?

No. This table correlates a list of risks with AWS controls; it is not a certification and not a standards requirement. The 2026 edition document itself includes a section on aligning with external frameworks as an index, but this is a reference, not a statement of compliance.

There are 10 items listed, so do you need 10 separate mitigation programs?

No. Controls can provide overlapping coverage. For example, the retrieval boundary around the knowledge base works on LLM02, LLM05, and LLM09 at the same time. Closing the invocation path with PrivateLink is part of the primary control for LLM02 and at the same time a secondary control for LLM01 and LLM06. Some, like LLM10, cannot be shared at all. Starting with the ones that can be is the natural order.

If this article does not address risks related to the agent layer, where should you look?

The companion agent-layer mapping table addresses items ASI01 through ASI10 in a similar format. The 2026 edition document on the model layer also includes references from each item to the agent layer section.

If AWS already provides a mapping table, what is the purpose of this article?

The versions, granularity, and presence of residual risks differ. The AWS mapping table is fixed to the 2025 edition, referencing the guide itself with best practice numbers, and does not explicitly state residual risks. This article focuses on the 2026 edition, using service and feature names, and details what risks remain after each control. Neither is inherently correct; they simply serve different purposes.

Will implementing guardrails address LLM01?

No. Content filters leave reasoning content out of scope, the Prompt Attack category is available only in the Standard tier, and the primary source states that no reliable prevention mechanism exists. Guardrails are the primary control, but a design that keeps credentials and state-changing capability outside the model, and human confirmation before irreversible operations, both have to be in place at the same time.

Will enabling model invocation logs be sufficient for auditing?

No. Three facts have to be held together: logging starts disabled, it captures only invocations through bedrock-runtime, and blocked sensitive information sits in it in plain text. CloudTrail supplements it but carries no content. And on bedrock-mantle, CloudTrail files inference as a data event, so you have to turn data event capture on.

Does Amazon Bedrock retain your prompts?

The behavior is determined by the configuration and model. The default is zero data retention, with named exceptions for abuse detection. The actual behavior depends on the retention mode configured at the account or project level, and the modes permitted by each model. Some models only allow provider_data_share, in which case you must either accept data retention or choose not to use that model.

Are Automated Reasoning checks available in all applications?

Not always. As of the verification date, they are generally available in six Regions and support US English only. The feature also detects and reports; it does not block. That rules it out for multilingual applications, for configurations that run entirely in unsupported Regions, and for any design that expects blocking.

How often should this table be reviewed?

The two sides move independently. On the risk list side, the very fact that a version with an unsettled publication date is in circulation sets the frequency. On the AWS side, feature names and policy types keep accumulating. The remaining-risk column earns its keep exactly when a new control arrives. The only way to update this table is to name the gap the new control filled and the gaps that remain.

Why is the "Core Remaining Risks" column more important than the controls column?

The controls column fills in as you implement things. The remaining-risk column names what implementing them does not fill in. Reviews should focus on the latter, not the former. If you cannot articulate the remaining risks, you likely do not truly understand what the controls are actually doing.

21. Summary

The mapping between the model-layer risk list and AWS controls can be written as a table of ten rows. The value of that table, however, lies not in the controls column but in the remaining-risk column.

Of the facts confirmed for this article, three carry the most weight for anyone building the mapping table.

First, the versions are not straightforward. The publisher's landing page carries the 2025 identifiers, while the resource library holds a 2026 edition whose publication date is still a placeholder. On top of that, the identifiers swap meaning across eight items. An operating practice that writes the identifier on its own is already broken at that point.

Second, AWS also publishes a mapping table, but it is fixed to the 2025 edition. When comparing that table with the 2026 edition, discrepancies arise. Rather than ignoring the prior work, anyone who publishes a mapping table owes the reader an explicit account of where it agrees and where it does not.

Third, there is a discernible pattern to the areas where AWS controls do not reach. The content filters for guardrails do not examine the reasoning content. IAM authorizes API calls but not the underlying intent. The caller attaches the metadata filter. Quotas live at the account level and count separately for each endpoint. Logging starts disabled, and for some endpoints it does not exist at all. Not retaining data is a default rather than a property of the service, and the modes each model permits constrain it. These are not the result of overlooked configurations; they are intentional design choices. You can fix what you forgot; a design boundary is something the application has to take on.

The moment filling in the mapping table becomes the goal in itself, that table becomes detrimental. A table where all ten rows carry a control name is also a table where all ten rows still carry residual risk. The sole proof of the table's value lies in the ability to articulate those remaining risks.

22. References

• OWASP Top 10 for LLM Applications
• OWASP GenAI LLM Top 10 2026
• OWASP Top 10 for LLM Applications 2025
• Create your guardrail - Amazon Bedrock User Guide
• Use the ApplyGuardrail API in your application
• Enforce the use of specific guardrails in model inference requests
• What are Automated Reasoning checks in Amazon Bedrock Guardrails
• CreateGuardrail - Amazon Bedrock API Reference
• Monitor model invocation using CloudWatch Logs and Amazon S3
• Monitor Amazon Bedrock API calls using CloudTrail
• Monitor bedrock-mantle API calls using CloudTrail
• Quotas for Amazon Bedrock
• Quotas for the bedrock-runtime endpoint
• Quotas for the bedrock-mantle endpoint
• Configure and customize queries for managed knowledge bases
• Encryption of knowledge base resources
• Data encryption - Amazon Bedrock User Guide
• Use interface VPC endpoints (AWS PrivateLink) with Amazon Bedrock
• Use Custom model import to import a customized open-source model into Amazon Bedrock
• Data protection in Amazon Bedrock
• Data retention - Amazon Bedrock User Guide
• Amazon Bedrock abuse detection
• Security Hub CSPM controls for Amazon Bedrock
• Configuring budget actions - AWS Cost Management
• Security for agentic AI on AWS - AWS Prescriptive Guidance
• Mapping to OWASP top 10 for LLM applications - AWS Prescriptive Guidance
• Providing secure access to data and systems for generative AI
• Security - Generative AI Lens, AWS Well-Architected Framework
• OWASP Top 10 for Agentic Applications Mapped to AWS Controls
• AI Agent Defense in Depth Model (AIDDM)
• Amazon Bedrock Guardrails Implementation Deep Dive
• Threat Modeling Generative AI Applications on AWS
• AWS WAF Generative AI Prompt Injection Patterns
• Agent Skills Security Vetting Guide
• Responsible-AI Guardrails Architecture on AWS

References:
Tech Blog with curated related content