This document catalogs the 12 OWASP Top 10 for LLM (OW-XX) checks produced by the AI/ML Security Assessment framework, and how each maps back to the underlying BR/SM/AC/FS checks it is derived from.
EnableOWASPAssessment=true on the deployment stack.FS-* checks. To guarantee
full OWASP coverage, the state machine automatically runs the Responsible
AI GRC Lambda whenever EnableOWASPAssessment=true, even when
EnableResponsibleAIGRCAssessment=false. In that case, Responsible AI GRC
findings are used only to derive OW-XX rows, are hidden from the report
UI (no Responsible AI GRC nav item, service card, or section), and the
raw responsible_ai_grc_security_report_*.csv is not copied to the
customer-facing report bucket. Enable
EnableResponsibleAIGRCAssessment=true explicitly if you want the
Responsible AI GRC section to appear alongside OWASP.These mappings are PRELIMINARY and ILLUSTRATIVE. They have not been reviewed by AWS Security Assurance Services or external auditors. Each organisation should validate them against its own interpretation of the OWASP Top 10 for LLM 2025 controls before relying on them as audit evidence.
OW-01 through OW-10 are derived by mapping existing findings, so the
OWASP Lambda itself does not call AWS APIs for those mapped rows. When OWASP
is enabled and Responsible AI GRC is not, the state machine still runs
Responsible AI GRC once to produce the FS-* source findings that feed OWASP
mappings; that can increase scan time and use the Responsible AI GRC IAM
surface. In CodeBuild-based deployments, the Responsible AI GRC source CSV
is filtered out when results are copied to the customer-facing report bucket
unless EnableResponsibleAIGRCAssessment=true. OW-11 and OW-12 are the only
native OWASP checks: they inspect Bedrock guardrails and Lambda env vars
for signals specific to LLM07 (System Prompt Leakage) that the existing
checks do not cover.
The OWASP Lambda runs after the per-service Lambdas have written their CSVs.
Bedrock, SageMaker, and AgentCore write per-region CSVs. Responsible AI GRC
writes one execution-scoped CSV whose unscoped evidence is labeled Global
rather than copied into target regions. OWASP reads those CSVs, applies the
OWASP_CHECK_MAPPINGS dict, runs OW-11 and OW-12, and writes
owasp_security_report_<execution>_<region>.csv.
Service selection affects only the Bedrock, SageMaker, and AgentCore source CSVs; Agent Registry is not an OWASP source. For each affected OW check ID, an N/A/Informational coverage row identifies the deselected evidence sources. Remaining mapped findings retain their status. OW-07 remains visible as unassessed when Bedrock, its only source, is deselected. OW-05 (GRC-only) and native OW-11/OW-12 are unaffected by direct-service selection. GRC still runs as a dependency and can assess deselected services through its own API calls.
If a required source CSV is missing, the Lambda emits an informational OW-00
coverage row instead of silently omitting all derived rows from that source.
OW-00 is not an OWASP Top 10 control; it is a report-completeness marker.
The OWASP mapping regression coverage tracks 34 check IDs added across the recent catalog expansions. Twelve have direct OWASP mappings. The remaining 22 are intentionally unmapped, including all AWS Agent Registry controls:
BR-35 checks harmful-content image modality coverage. It does not verify
image-borne prompt-injection defenses or downstream output validation, so
mapping it to LLM01 or LLM05 would overstate the observed control.BR-36 checks whether application inference profiles have governance tags.
Tags support ownership and cost allocation but do not themselves enforce
the limits required for LLM10 Unbounded Consumption.AC-17 checks whether online evaluation is operational, but it does not
require a particular evaluator type. It therefore cannot establish coverage
for a specific OWASP risk such as LLM09 Misinformation.AG-28 through AG-32 are synthesized from BR/AC source findings. Mapping
them again would duplicate source evidence for AG-28 through AG-31 and
would bypass the deliberate AC-17 non-mapping for AG-32.AR-01 through AR-08 assess AWS Agent Registry IAM access and governance.
AG-33 through AG-38 synthesize related evidence. None directly proves an
OWASP LLM01–LLM10 control, so Registry CSVs are intentionally not read by the
OWASP Lambda and all fourteen Registry-derived controls are excluded from
OWASP mapping.The “By Compliance Standard” sidebar section is data-driven — future NIST AI
RMF (NR- prefix) and EU AI Act (EU- prefix) additions require only
appending a new entry to COMPLIANCE_STANDARDS in report_template.py and
following the same Lambda/CFN wire-up pattern (EnableNISTAssessment /
EnableEUAIActAssessment). Each new prefix must be 2–3 uppercase letters to
satisfy the Check_ID regex ^[A-Z]{2,3}-\d{2}$.
Each emitted OW row uses the category-specific OWASP remediation reference
for its Reference field:
Maps from:
| Source | Signal |
|---|---|
| BR-04 | Bedrock model invocation logging enabled (§4.3 prompt logging) |
| BR-34 | Preventive Bedrock Guardrails PROMPT_ATTACK input filter |
| BR-23 | Guardrail content filter coverage |
| BR-27 | Contextual grounding guardrail |
| SM-26 | GuardDuty AI Protection feature enabled |
| FS-51 | PROMPT_ATTACK filter at Standard tier |
| FS-52 | Bedrock-calling Lambda runtimes not deprecated |
| FS-53 | WAF SQLi + KnownBadInputs managed rule groups |
| FS-54 | Adversarial testing evidence via tagging |
| FS-69 | Prompt-input validation Lambda present |
Maps from:
| Source | Signal |
|---|---|
| BR-26 | Guardrail PII / regex filter policy |
| BR-37 | Bedrock account data retention and provider-sharing boundary |
| BR-38 | Automated Reasoning policies use customer-managed KMS encryption |
| BR-40 | Marketplace model endpoints use customer-managed KMS encryption |
| AC-14 | AgentCore Identity token vault uses customer-managed KMS encryption |
| FS-43 | CloudWatch log data protection policies |
| FS-44 | Amazon Macie sensitive-data discovery |
| FS-45 | Guardrail PII entities coverage (Responsible AI GRC) |
| FS-46 | S3 data-classification tagging |
| SM-03 | SageMaker notebooks, domains, and training jobs use encryption controls |
| SM-15 | SageMaker Feature Store offline stores use KMS encryption |
| SM-27 | HyperPod root and secondary EBS volumes use customer-managed KMS encryption |
Maps from:
| Source | Signal |
|---|---|
| BR-30 | Imported-model KMS encryption |
| BR-33 | Amazon Inspector Lambda code scanning (§2.5 SBOM / static analysis) |
| BR-39 | Marketplace model endpoints use controlled VPC network boundaries |
| FS-12 | SCP-enforced model allowlist |
| FS-13 | Custom-model provenance tags |
| FS-14 | AWS Config rules for model onboarding |
| FS-15 | Adversarial evaluation coverage |
| FS-16 | ECR image scanning |
| SM-01 | SageMaker notebooks/domains avoid direct internet exposure |
| SM-10 | SageMaker notebooks are deployed inside a VPC |
| SM-11 | SageMaker model containers use network isolation |
| SM-14 | SageMaker models pull containers through controlled repository access |
| SM-21 | SageMaker AutoML jobs use network isolation |
| SM-25 | SageMaker Experiments and lineage associations track model provenance |
| SM-28 | HyperPod instance groups use controlled VPC network boundaries |
| SM-30 | Model Registry resource policies restrict public and unapproved cross-account access |
Maps from:
| Source | Signal |
|---|---|
| BR-25 | RAG evaluation coverage |
| BR-27 | Contextual grounding on retrieved data |
| FS-20 | Feature Store OfflineStoreConfig |
| FS-21 | Training-data S3 versioning |
| FS-42 | SageMaker Model Card documentation (§3.1 model system card reviews) |
| SM-07 | SageMaker Model Monitor schedules detect quality regressions |
| SM-22 | SageMaker Model Registry approval workflows gate model promotion |
| SM-23 | SageMaker drift detection monitors production endpoints |
| SM-25 | SageMaker lineage tracking links data, training runs, and model artifacts |
Maps from:
| Source | Signal |
|---|---|
| FS-55 | Output-validation Lambda in response path |
| FS-56 | WAF XSS protection |
| FS-57 | Output encoding libraries in Lambda |
| FS-58 | Step Functions output schema validation |
Maps from:
| Source | Signal |
|---|---|
| BR-21 | Agent action-group Lambda role least privilege |
| BR-28 | Bedrock agent guardrail association |
| BR-29 | Agent idle session TTL bound |
| AC-02 | AgentCore IAM least privilege |
| AC-10 | AgentCore resource-based policies |
| AC-15 | AgentCore custom Code Interpreter VPC isolation |
| AC-16 | AgentCore custom browser VPC isolation |
| FS-07 | Agent execution role least privilege (Responsible AI GRC) |
| FS-08 | AgentCore runtime inbound authorizer (Responsible AI GRC) |
| FS-09 | Agent tool concurrency limits |
| FS-10 | Step Functions HITL callback tasks |
| FS-67 | Agent transaction thresholds in Cedar / config |
Mapping-based (OW-07) signals:
| Source | Signal |
|---|---|
| BR-04 | Bedrock model invocation logging enabled (§4.3 prompt logging) |
| BR-07 | Bedrock Prompt Management adoption (§2.2 prompts as code) |
| BR-16 | Guardrail Standard tier (Standard tier additionally detects prompt-leakage) |
Native checks fill the gap:
OW-11: System Prompt Embedded in Lambda Env Var
Heuristic: flag Lambda functions whose env vars are ≥ 200 chars and
match at least two distinct prompt-shaped multi-word phrases from
SYSTEM_PROMPT_HEURISTIC_PHRASES (e.g. "you are a", "you are an",
"your role", "your task", "you must", "you should",
"helpful assistant", "as an assistant", "system prompt",
"system instruction", "never reveal", "do not reveal",
"internal instruction", "respond politely"). Multi-word phrases
and the ≥ 2-match requirement are deliberate — the check is designed
not to flag ordinary configuration blobs (policy JSON, log format
strings, runbook text) that contain isolated words like "system" or
"instruction". Recommend moving prompts to Bedrock Prompt Management.
Severity: Medium (control-inherent — same on Passed and Failed).
OW-12: System-Prompt-Disclosure Denied Topic
Verify at least one Bedrock guardrail’s topicPolicy contains a DENY
topic whose name or definition mentions “system prompt”, “instruction
disclosure”, “prompt leakage”, “reveal instructions”, or “internal prompt”.
Severity: Medium (control-inherent — same on Passed and Failed).
Severity convention. OW-11 and OW-12 are native checks; their
severity is control-inherent (same on Passed and Failed), matching the
Responsible AI GRC severity methodology. OW-01..OW-10 mapping rows inherit the
source check’s severity except when the source is N/A, in which case
the OWASP row is downgraded to Informational to avoid inflating
severity totals with tooling / no-resource rows.
Maps from:
| Source | Signal |
|---|---|
| BR-20 | Managed Knowledge Base CMK encryption |
| FS-22 | KB IAM scoping |
| FS-24 | KB metadata filtering |
| FS-25 | OpenSearch Serverless encryption (CMK) |
| FS-26 | OpenSearch Serverless network policy |
Maps from:
| Source | Signal |
|---|---|
| BR-18 | Model evaluation jobs |
| BR-25 | RAG evaluation for faithfulness |
| BR-27 | Contextual grounding for faithfulness |
| FS-31 | Knowledge Base ingestion freshness |
| FS-32 | Source attribution via citations |
| FS-33 | KB S3 data-source integrity |
| FS-42 | SageMaker Model Card documentation (§3.1 model system card reviews) |
| FS-47 | Grounding filter threshold ≥ 0.70 |
| FS-48 | Active Knowledge Base present |
| SM-06 | SageMaker Clarify evaluates bias and explainability |
| SM-07 | SageMaker Model Monitor schedules detect quality regressions |
| SM-22 | SageMaker Model Registry approval workflows gate production release |
| SM-23 | SageMaker drift detection monitors production endpoints |
Maps from:
| Source | Signal |
|---|---|
| BR-22 | Service Quotas throttling limits |
| BR-32 | CloudWatch consumption alarms |
| SM-26 | GuardDuty AI Protection anomalous invocation and cost-harvesting detection |
| FS-01 | WAF rate-based & Shield protection |
| FS-02 | API Gateway usage plans |
| FS-03 | Bedrock TPM/RPM quotas customised |
| FS-04 | AWS Cost Anomaly Detection |
| FS-05 | Token / throttle alarms |
| FS-06 | AWS Budgets with Bedrock filters |
| FS-68 | API Gateway request body size limits |
| SM-11 | SageMaker model network isolation limits uncontrolled outbound calls |
OW rows follow the same rules as every other check in the framework:
Severity and Status are inherited from the source finding.
An N/A source produces an OW row with Severity=Informational and
Status=N/A — never an inflated High/Medium.N/A, never
Failed.OW-00 with
Severity=Informational and Status=N/A.Reference field on every OW row points to the category-specific
remediation page linked from https://genai.owasp.org/llm-top-10/, not the
AWS docs. This keeps report rows aligned to the OWASP category they satisfy
even when the underlying misconfiguration was surfaced by a BR/SM/AC/FS
source check.