Coverage & traceability Every framework item, mapped to the AWS security control(s) that address it: OWASP LLM Top 10 (2026) for technical risks, NIST AI RMF for risk governance, the AWS Well-Architected Generative AI Lens security best practices, and AWS Security Hub AI checks for automated runtime validation. Use this to see coverage at a glance and trace each control back to the framework.
ⓘ This maps each framework item (OWASP LLM Top 10 risks, NIST AI RMF functions/categories, AWS Well-Architected Generative AI Lens best practices, and AWS Security Hub AI checks) to one or more AWS security controls in this model. It shows control coverage and traceability; it is not a statement of compliance or certification.
AWS Well-Architected Generative AI Lens (Security) 10/10 items covered
OWASP GenAI/LLM Top 10 (2026) 10/10 items covered
OWASP GenAI Top 10 for Agentic Applications (2025) 10/10 items covered
NIST AI Risk Management Framework (AI 100-1) 15/19 items covered NIST AI RMF is mapped at the function and category level (Govern, Map, Measure, Manage). Not every category applies to a technical security model, so partial coverage here is expected and honest.
Framework item AWS security controls GOVERN.1 Policies, processes, procedures and accountability structures c1.1 c1.11 c2.8 c4.1 c5.1 c6.8 GOVERN.2 Accountability structures, roles, responsibilities and training No control mapped yet GOVERN.3 Workforce diversity, equity, inclusion and interdisciplinary teams No control mapped yet GOVERN.4 Organizational culture that prioritizes risk awareness c1.11 GOVERN.5 Processes for stakeholder engagement and feedback c5.5 GOVERN.6 Policies for third-party software, data and supply chain risk c2.6 c2.8 MAP.1 Context is established and understood No control mapped yet MAP.2 AI system categorization and capabilities are documented c3.8 MAP.3 AI benefits and costs are understood No control mapped yet MAP.4 Risks and impacts are mapped c1.8 c2.5 c2.6 c3.4 c3.5 c5.8 MAP.5 Impacts to individuals, groups and society are characterized c3.5 MEASURE.1 Appropriate methods and metrics are identified and applied c1.12 c2.5 c5.10 MEASURE.2 AI systems are evaluated for trustworthy characteristics c1.3 c1.9 c1.12 c2.9 c3.9 c4.5 c5.6 c5.10 c6.3 MEASURE.3 Mechanisms for tracking AI risks are in place c1.4 c1.10 c2.7 c2.9 c3.8 c4.8 c5.9 c6.7 c6.8 MEASURE.4 Feedback about efficacy of measurement is gathered c5.10 MANAGE.1 AI risks are prioritized, responded to and managed c1.1 c1.2 c1.3 c1.5 c1.6 c1.7 c1.8 c1.9 c1.11 c2.1 c2.2 c2.4 c3.1 c3.2 c3.3 c3.4 c3.6 c3.7 c3.9 c4.1 c4.2 c4.3 c4.4 c4.5 c4.6 c4.7 c5.1 c5.2 c5.3 c5.4 c5.6 c5.7 c5.8 c6.1 c6.2 c6.3 c6.4 c6.5 c6.6 MANAGE.2 Strategies to maximize benefits and minimize impacts are planned c5.5 MANAGE.3 Third-party risks and benefits are managed c2.6 c2.8 MANAGE.4 Risk treatments, monitoring and response are documented and applied c1.4 c1.6 c1.10 c2.3 c2.7 c2.9 c4.8 c5.5 c5.9 c6.7 c6.8
AWS Security Hub — AI Security Best Practices 29/31 items covered These are the automated Security Hub CSPM checks that validate the matching controls in this model at runtime. Two checks (SageMaker.4, SageMaker.8) are about resilience and platform lifecycle rather than security posture, so they are intentionally not mapped.
Framework item AWS security controls Bedrock.1 Amazon Bedrock data sources should be encrypted with customer managed AWS KMS keys c1.2 c3.1 BedrockAgentCore.1 Bedrock AgentCore runtimes should be configured with VPC network mode c4.6 c5.7 BedrockAgentCore.2 Bedrock AgentCore Gateways should require authorization for inbound requests c4.4 c5.4 BedrockAgentCore.3 Bedrock AgentCore Memory should be encrypted with customer managed AWS KMS keys c5.2 BedrockAgentCore.4 Bedrock AgentCore Gateway should be encrypted with customer managed AWS KMS keys c4.3 BedrockAgentCore.5 Bedrock AgentCore custom browsers should not use public network mode c4.6 BedrockAgentCore.6 Bedrock AgentCore custom browsers should have session recording enabled c4.8 c5.9 BedrockAgentCore.7 Bedrock AgentCore custom code interpreters should use a private network configuration c4.7 SageMaker.1 Amazon SageMaker notebook instances should not have direct internet access c2.4 SageMaker.2 SageMaker notebook instances should be launched in a custom VPC c2.4 SageMaker.3 Users should not have root access to SageMaker notebook instances c2.2 SageMaker.4 SageMaker endpoint production variants should have an initial instance count greater than 1 No control mapped yet SageMaker.5 SageMaker models should have network isolation enabled c2.4 SageMaker.8 SageMaker notebook instances should run on supported platforms No control mapped yet SageMaker.9 SageMaker data quality job definitions should have inter-container traffic encryption enabled c2.4 SageMaker.10 SageMaker model explainability job definitions should have inter-container traffic encryption enabled c2.4 SageMaker.11 SageMaker data quality job definitions should have network isolation enabled c2.4 SageMaker.12 SageMaker model bias job definitions should have network isolation enabled c2.4 SageMaker.13 SageMaker model quality job definitions should have inter-container traffic encryption enabled c2.4 c2.9 SageMaker.14 SageMaker monitoring schedules should have network isolation enabled c2.4 SageMaker.15 SageMaker model bias job definitions should have inter-container traffic encryption enabled c2.4 c2.9 SageMaker.16 SageMaker models should use private registry in VPC for primary containers c2.4 SageMaker.17 SageMaker feature group offline stores should be encrypted with AWS KMS keys c2.1 SageMaker.18 SageMaker feature group online stores with standard storage should be encrypted with AWS KMS keys c2.1 SageMaker.19 SageMaker models should use private registry in VPC for multi-container inference pipelines c2.4 SageMaker.20 SageMaker model explainability job definitions should have network isolation enabled c2.4 SageMaker.21 SageMaker notebook instances should be encrypted with customer managed AWS KMS keys c2.1 SageMaker.22 SageMaker monitoring schedules should have inter-container traffic encryption enabled c2.4 SageMaker.23 SageMaker inference experiments should have instance storage volume encrypted with customer managed AWS KMS keys c2.1 SageMaker.24 SageMaker inference experiments should have data storage encrypted with customer managed AWS KMS keys c2.1 SageMaker.25 SageMaker model quality job definitions should have network isolation enabled c2.4 c2.9
Agentic security dimensions 6/6 items covered