Normal view

Received — 11 May 2026 AWS Security Blog

ICYMI: April 2026 @AWS Security

7 May 2026 at 20:52

Read all about the latest AWS security features, compliance updates, and hands-on resources in our new, monthly digest posts. You’ll find expert blog posts, new service capabilities, code samples, and workshops.

AWS Security Blog posts

This month’s AWS Security Blog posts covered AI security, identity and access management, threat intelligence, data protection, and multicloud operations. Whether you’re securing agentic AI systems, upgrading to post-quantum cryptography, or streamlining forensic collection, these posts offer practical guidance across the security landscape.

Identity

    Access control with IAM Identity Center session tags
    Author: Rashmi Iyer | Published: April 28, 2026
    Learn to combine AWS IAM Identity Center permission sets with session tags from Microsoft Entra ID to implement fine-grained attribute-based access control (ABAC) across multiple AWS accounts.

    Can I do that with policy? Understanding the AWS Service Authorization Reference
    Authors: Anshu Bathla, Prafful Gupta | Published: April 27, 2026
    Learn to use the AWS Service Authorization Reference to determine what’s achievable with IAM policies, recognize scenarios needing alternative solutions, and build more effective security controls.

    AI Security

    Secure AI agent access patterns to AWS resources using Model Context Protocol
    Author: Riggs Goodman III | Published: April 14, 2026
    Learn to secure AI agent access to AWS resources via MCP using three principles: least privilege, organizational role governance, and differentiating AI-driven from human-initiated actions.

    Four security principles for agentic AI systems
    Authors: Mark Ryland, Riggs Goodman III, Todd MacDermid | Published: April 2, 2026
    Learn four security principles from AWS’s NIST response for securing agentic AI: secure development lifecycle, traditional controls, deterministic external enforcement, and earned autonomy through evaluation.

    Designing trust and safety into Amazon Bedrock powered applications
    Author: Victor Lungu | Published: April 29, 2026
    Learn to integrate responsible AI concepts into Amazon Bedrock applications, including abuse detection, Amazon CloudWatch monitoring, Bedrock Guardrails configuration, and the abuse response process.

    Building AI defenses at scale: before the threats emerge
    Author: Amy Herzog | Published: April 7, 2026
    AWS CISO announces Project Glasswing with Anthropic, introducing Claude Mythos Preview for vulnerability research, plus the general availability of AWS Security Agent for autonomous penetration testing.

    Governance and compliance

      Shift-Left Tag Compliance using AWS Organizations and Terraform
      Authors: Welly Siauw, Sourav Kundu, Manu Chandrasekhar | Published: April 27, 2026
      Learn to validate tag compliance during development using AWS Organizations tag policies, a reusable Terraform tagging module, and a test-driven approach that dynamically validates against live organizational policies.

      Detection and incident response

      What the March 2026 Threat Technique Catalog update means for your AWS environment
      Authors: Shannon Brazil, Cydney Stude | Published: April 28, 2026
      The AWS CIRT’s latest Threat Technique Catalog update covers Amazon Cognito refresh token abuse, AMI image deletion targeting recovery, and trust policy modifications for persistence and privilege escalation.

      A framework for securely collecting forensic artifacts into S3 buckets
      Authors: Jason Garman, Vaishnav Murthy | Published: April 8, 2026
      Learn to securely collect forensic artifacts into Amazon S3 using time-limited, least-privilege credentials with AWS STS session policies and automated AWS Step Functions workflows.

      Transform security logs into OCSF format using a configuration-driven ETL solution
      Authors: Vivek Gautam, Arpit Gupta, Ryan Gomes | Published: April 17, 2026
      Learn to transform custom security logs into OCSF format using an AWS ProServe configuration-driven ETL solution with AWS Step Functions, AWS Glue or Amazon EMR Serverless, and Amazon Security Lake integration.

      A technical walkthrough of multicloud full-stack security using AWS Security Hub Extended
      Authors: Matt Meck, Michael Fuller | Published: April 22, 2026
      Learn how AWS Security Hub Extended simplifies multicloud security procurement and operations through curated partner solutions, unified billing, and OCSF-based findings consolidation.

      Data protection

        Protecting your secrets from tomorrow’s quantum risks
        Authors: Stéphanie Mbappe, Tobias Nickl | Published: April 24, 2026
        Learn to upgrade AWS Secrets Manager clients to use hybrid post-quantum TLS with ML-KEM, protecting secrets against harvest-now-decrypt-later attacks, and verify connections via AWS CloudTrail.

        How AWS KMS and AWS Encryption SDK overcome symmetric encryption bounds
        Authors: Panos Kampanakis, Matthew Campagna, Patrick Palmer | Published: April 3, 2026
        Learn how AWS Key Management Service and the AWS Encryption SDK use derived key methods to automatically handle AES-GCM encryption limits, eliminating the need to manually track bounds or rotate keys.

        How to clone an AWS CloudHSM cluster across Regions
        Authors: Desiree Brunner, Rickard Löfström | Published: April 20, 2026
        Learn to clone an AWS CloudHSM cluster to another Region using CopyBackupToRegion, then synchronize keys—including non-exportable keys—across cloned clusters for disaster recovery.

        April Security Bulletins

        Investigations of reported security vulnerabilities affecting Amazon and AWS services, software, and products.

        AWS Samples

        This month brings 16 new AWS samples spanning identity, governance, compliance, detection and incident response, AI Security, data protection, and infrastructure security. From beginner-friendly AI agent development on Amazon Bedrock to automated Control Tower re-registration at scale, these ready-to-deploy repositories help you implement security best practices across your AWS environment.

        Identity

          Amazon Cognito OAuth2 Token Proxy with Caching
          Learn to deploy an Amazon API Gateway proxy for Cognito’s OAuth2 token endpoint with intelligent caching and AWS WAF protection, reducing M2M authentication costs by over 90%.

          Cognito API Gateway Authorization Demo
          Learn to implement user-specific data protection using Amazon Cognito, API Gateway, and an AWS Lambda authorizer that enforces JWT sub claim matching to prevent cross-user data access.

          Securely Connecting On-Premises Data Systems to Amazon Redshift with IAM Roles Anywhere
          Learn to deploy a fully private environment connecting on-premises workloads to Amazon Redshift using X.509 certificate authentication via IAM Roles Anywhere for short-lived credentials.

          AWS IAM Access Key Lifecycle Management with Human Approval
          Learn to automate organization-wide detection, disabling, and deletion of unused IAM access keys using Step Functions, IAM Access Analyzer, and a secure human-in-the-loop approval workflow.

          Secrets Manager Audit
          Learn to resolve and report who can access your AWS Secrets Manager secrets—across accounts, through Identity Center, and down to the human behind the IAM role—in a single command.

          Governance

          Control Tower Organization Re-Registration Automation
          Learn to automate AWS Control Tower OU re-registration and account updates at scale using lifecycle events, Amazon EventBridge, and AWS Lambda to resolve mixed governance after landing zone changes.

          Sample Agent Skills for Builders
          A curated collection of installable agent skills that extend AI coding agents (Claude Code, Cursor, Copilot) with production-ready AWS, CDK, security scanning, and engineering workflows.

          How to Stop AI Agent Hallucinations: 5 Techniques + Production on Amazon Bedrock AgentCore
          Learn to detect, prevent, and self-correct AI agent hallucinations using Graph-RAG, semantic tool selection, multi-agent validation, neurosymbolic guardrails, and agent steering with Strands Agents.

          Compliance

          Compliance Lens
          Learn to deploy a serverless solution that analyzes AWS Config snapshots across an AWS Organization, compares them against conformance pack rule sets, and visualizes compliance posture via Amazon QuickSight dashboards.

          AWS Security Agent Terraform Configuration
          Learn to provision AWS Security Agent resources using the AWSCC Terraform provider, automating agent space creation, IAM roles, target domain registration, and penetration test setup.

          Detection and incident response

          AWS Security Agent Demo Suite
          Learn to use AWS Security Agent across three scenarios: automated design reviews, AI-generated infrastructure code review via GitHub, and penetration testing against intentionally vulnerable applications.

          Agentic SOC Workshop — CDK Infrastructure
          Learn to build an AI-powered Security Operations Center agent that investigates Amazon GuardDuty findings, queries CloudTrail logs, and takes automated containment actions using Amazon Bedrock AgentCore.

          Data Protection

          Implementing Kerberos Authentication for Apache Spark Jobs on Amazon EMR on EKS to Access a Kerberos-Enabled Hive Metastore
          Learn to configure Kerberos authentication for Spark jobs on Amazon EMR on Amazon Elastic Kubernetes Service, connecting to a Kerberos-enabled Hive Metastore using Microsoft Active Directory as the KDC.

          AWS Nitro Enclaves with Kubernetes – Hello World Example
          Learn to deploy a Hello World application inside an AWS Nitro Enclave on Amazon EKS, covering cluster creation, device plugin setup, and enclave image building.

          Infrastructure security

            Multi-Tenant OpenClaw on Firecracker
            Learn to deploy isolated, multi-tenant OpenClaw AI agents on AWS using Firecracker microVMs with per-tenant kernel/network isolation, auto-scaling, backup/restore, and a web management console.

            AI Security

            Amazon Bedrock for Beginners – From First Prompt to AI Agent
            Learn to build AI applications on Amazon Bedrock, from basic API calls to a full agent with RAG, guardrails, tool use, and the Strands Agents SDK.

            Conclusion

            April 2026 reinforces that securing AI workloads now requires the same rigor applied to traditional infrastructure. The posts and samples in this edition provide concrete patterns for enforcing least privilege on agentic systems, automating governance at organizational scale, and preparing cryptographic implementations for post-quantum requirements. The security bulletins address vulnerabilities across compute, networking, and developer tooling, reinforcing the need to apply patches consistently. Each resource includes deployment steps or runnable code so you can validate the approach in your own environment before adopting it. Subscribe to the AWS Security Blog RSS feed to receive updates as they publish, and revisit this digest monthly for a consolidated view of what changed and what to act on.


            If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

            Rodolfo Brenes

            Rodolfo Brenes

            Rodolfo is a Principal Solutions Architect focused on Cloud Governance and Compliance. With over 18 years of experience, he currently leads a technical field community in AWS helping customers scale and improve their security and governance frameworks. Besides work, Rodolfo enjoys video games, playing with his four cats, and won’t say no to a good outdoor adventure.

            Anna Brinkmann

            Anna Brinkmann

            Anna is a project manager and editor with more than 18 years of experience with content management in the technology space. For the past 6 years, she has run the AWS Security Blog. In her free time, Anna gardens, spends time with family and friends, and learns new slang words from her kids.

            AWS achieves SNI 27017, SNI 27018, and SNI 9001 certifications for the AWS Asia Pacific (Jakarta) Region

            7 May 2026 at 18:03

            Amazon Web Services (AWS) achieved three Standar Nasional Indonesia (SNI) certifications for the AWS Asia Pacific (Jakarta) Region: SNI ISO/IEC 27017:2015, SNI ISO/IEC 27018:2019, and SNI ISO 9001:2015. SNI represents Indonesia’s national standards framework, comprising standards that are broadly applicable across industries within the country. These certifications further demonstrate that AWS services meet nationally recognized requirements.

            The certifications were assessed by an independent third-party auditor accredited by the Komite Akreditasi Nasional (KAN), Indonesia’s National Accreditation Committee, in accordance with applicable local regulatory requirements, helping customers rely on trusted, locally recognized validation for their compliance needs.

            All three certifications are based on international ISO standards adapted for Indonesia:

            • SNI 27017 adds cloud-specific security controls that complement ISO/IEC 27001, helping you run workloads securely while reducing security assessment overhead.
            • SNI 27018 focuses on protecting personally identifiable information (PII) in public clouds. This certification confirms that AWS handles your data according to international privacy standards.
            • SNI 9001 establishes quality management systems that ensure consistent service delivery and continuous improvement across AWS operations.

            Together with the existing SNI 27001 certification achieved in 2023, AWS is now the first cloud service provider (CSP) to hold all four SNI certifications—SNI 27001, SNI 27017, SNI 27018, and SNI 9001—demonstrating comprehensive alignment with Indonesia’s national standards for information security, cloud security, privacy, and quality management, and helping customers address a broad range of regulatory and risk management requirements.

            Customers can access the corresponding certificates through AWS Artifact, a self-service portal that provides on-demand access to AWS compliance documentation. For a full list of AWS services covered under the SNI certification, see the Services in Scope compliance page

            AWS continues to expand the scope of its compliance programs to help customers meet their architectural, business, and regulatory requirements. For more information regarding these certifications, contact your AWS Accounts team.

            Ignatius Lee

            Ignatius Lee

            Ignatius is a Security Assurance professional based in Singapore, responsible for third-party audits in Indonesia. He joined Security Assurance in early 2025 and has delivered and contributed to key audit programs across Hong Kong, Singapore, and Australia.

            New compliance guide available: ISO/IEC 42001:2023 on AWS

            6 May 2026 at 21:39

            We have released our latest compliance guide, ISO/IEC 42001:2023 on AWS, which provides practical guidance for organizations designing and operating an Artificial Intelligence Management System (AIMS) using AWS services.

            As organizations deploy AI and generative AI workloads in the cloud, aligning with globally recognized standards such as ISO/IEC 42001:2023 becomes an important step toward strengthening AI governance, risk management, and responsible AI practices. This guide helps cloud architects, AI/ML engineers, security teams, compliance leaders, and DevOps practitioners understand how to implement and operate ISO 42001-aligned controls using AWS services while applying the AWS Shared Responsibility Model for AI.

            The guide explains how organizations can integrate AWS services into their AIMS to support the requirements defined in ISO 42001:2023 clauses 4–10 and the Annex A control specific to AI systems. It also highlights how AWS AI services, security capabilities, monitoring, and automation can help customers maintain visibility over AI systems, improve operational consistency, and prepare audit-ready evidence.

            While AWS provides a secure and compliant cloud infrastructure with built-in responsible AI capabilities, customers remain responsible for defining their AIMS scope, implementing controls, and demonstrating conformity during certification audits.

            Inside the guide:

            • Overview of the ISO/IEC 42001:2023 framework, including understanding ISO 42001 and its Annexes, and how it relates to the broader ISO AI standards family
            • Guidance for integrating with AWS security architecture and applying the AWS Shared Responsibility Model for AI workloads
            • Context and scoping considerations for establishing an AIMS on AWS, including defining AI system boundaries within your environment
            • Mapping of ISO 42001:2023 clauses 4–10 to AWS services and architectural capabilities, covering organizational context, leadership, planning, support, operation, performance evaluation, and improvement
            • Implementation guidance for specific Annex A controls (A.2–A.10), including AI policies, internal organization, resources for AI systems, impact assessments, AI system life cycle management, data governance, transparency for interested parties, use of AI systems, and third-party and customer relationships
            • Recommendations for evidence collection, documentation, and audit readiness using AWS native tooling
            • Best practices for operationalizing AI compliance activities through automation and infrastructure-as-code

            Use this guide to map ISO 42001 clauses and Annex A controls to your AWS environment, automate evidence collection, and reduce the effort involved in preparing for a certification audit.

            Download: ISO/IEC 42001:2023 on AWS Compliance Guide

            For further assistance, contact AWS Security Assurance Services

            If you have feedback about this post, please submit comments in the Comments section below.

            Abdul Javid

            Abdul Javid

            Abdul is a Senior Security Assurance Consultant and a PECB ISO 42001 Lead Auditor, IAPP Certified AI Governance Professional and ISACA Advanced in AI Security Management. He draws on his extensive experience of over 25 years to guide AWS customers on compliance matters. He holds an M.S. in Computer Science from IIT Chicago and numerous certifications from IAPP, AWS, ISO, HITRUST, ISACA, CMMC, PMI, PCI DSS, and ISC2.

            Satish Uppalapati

            Satish is an Associate Assurance Consultant with AWS Security Assurance Services and has more than 8 years of experience in IT risk, governance, and regulatory assurance. He works with AWS customers to help align cloud environments with frameworks such as ISO 27001, SOC 2, and FFIEC. Satish also focuses on advancing governance for AI systems, including emerging standards such as ISO/IEC 42001.

            Amber Welch

            Amber Welch

            Amber is an AWS Security Assurance Services Senior Privacy Consultant, advising AWS customers on their AI and privacy risk management and compliance. She has an M.A. in English and ISO 42001 Lead Auditor, IAPP CIPM, and IAPP CIPP/E certifications. Amber has spoken and written extensively on AI and privacy topics, and is an AWS Privacy Reference Architecture primary author.

            Jonathan-Jenkyn

            Jonathan Jenkyn

            Jonathan (“JJ”) is a Sr Security Assurance Solution Architect with AWS Security Assurance Services. With over 30 years of experience, he is a proven security leader who delivers robust cloud security outcomes. JJ is also an active member of the AWS People with Disabilities affinity group and enjoys running, cycling, and spending time with his family.

            Muhammad Sharief

            Muhammad Sharief

            Muhammad is a Security Assurance Consultant with AWS Security Assurance Services (SAS) and a PECB-certified ISO/IEC 42001 Lead Auditor. He helps enterprise customers across AWS GovCloud (US) and commercial environments achieve and maintain compliance with FedRAMP, CMMC, ISO 27001, ISO 42001, and NIST 800-53. Muhammad works closely with customers, partners, and AWS service teams to design automated evidence collection architectures, advance AI governance, and align cloud security and compliance requirements with business objectives.

            Introducing AI traffic analysis dashboards for AWS WAF

            5 May 2026 at 20:56

            As AI agents, bots, and programmatic access become an increasingly significant portion of web traffic, organizations need better tools to understand, analyze, and manage this activity. Today, we’re excited to announce AI Traffic Analysis dashboards for AWS WAF protection packs—also known as web access control lists (web ACLs)—providing comprehensive visibility into AI bot and agent behavior across your applications.

            The challenge: Understanding AI bot traffic

            The rapid proliferation of AI bots—from search engine crawlers to research agents—has fundamentally changed the nature of web traffic. Organizations across industries are discovering that AI agents now represent 30–60% of their total traffic, driving significant infrastructure costs without always generating business value.

            Traditional bot management tools weren’t designed for the nuances of AI traffic. Teams need to answer critical questions such as: Which AI organizations are accessing our content? What are they trying to accomplish? Which endpoints are most frequently targeted? How has this activity changed over time? Most importantly, how can we turn this visibility into actionable business decisions?

            Introducing the AI Traffic Analysis dashboard

            The new AI Traffic Analysis dashboard provides specialized visibility into AI bot and agent activity, available directly within your AWS WAF protection pack (web ACL) console. With this launch, AWS WAF Bot Control expands its detection coverage to track more than 650 unique bots and agents, offering one of the most comprehensive AI bot detection catalogs available. A detection catalog that will keep growing and be updated to align with the pace of the industry’s changes.

            This dashboard goes beyond standard security metrics to deliver AI-specific insights that help you understand and manage this critical traffic segment.

            Key capabilities

            • Bot identification and verification: See which AI bots are accessing your applications, including bot names, owning organizations, and verification status. Quickly distinguish between legitimate AI agents from known organizations and potentially suspicious activity.
            • Intent classification: Understand the purpose behind AI bot requests. The dashboard categorizes bot behavior patterns—whether crawling for search indexing, conducting research, gathering training data, or other activities—helping you align access policies with business objectives.
            • Access pattern analysis: Identify your most frequently accessed URLs and endpoints by AI agents. This visibility helps you understand which content is most valuable to AI organizations and optimize your infrastructure accordingly.
            • Temporal trends and historical analysis: Track AI bot activity patterns by time of day and analyze historical trends over the past 14 days. Detect anomalies, understand peak usage periods, and identify emerging patterns in AI traffic.
            • Organization breakdown: View traffic volume segmented by bot owner organization, giving you clear visibility into which AI companies are accessing your content and at what scale.

            How it works

            AI Traffic Analysis dashboards integrate seamlessly with AWS WAF Bot Control for common bots using the same traffic evaluation engine while providing specialized analytics for AI-specific patterns. The dashboards display near real-time summaries based on Amazon CloudWatch metrics collected as AWS WAF evaluates your web traffic.

            To access the AI Traffic Analysis dashboard:

            1. Navigate to your protection pack (web ACL) in the AWS Management Console for AWS WAF.
            2. Select the AI Traffic Analysis tab.
            3. Apply filters for bot organization, intent type, or verification status as needed.
            4. Analyze the comprehensive visualizations across bot identity, intent classification, access patterns, and temporal trends.

            The dashboard populates automatically once your protection pack begins receiving AI bot traffic, so you have visibility exactly when you need it.

            From visibility to action

            This new capability addresses a critical need as organizations navigate the evolving landscape of AI-driven web traffic. With detailed insights into AI bot behavior, you can:

            • Make informed access decisions: Understand bot intent before implementing allow or block rules.
            • Optimize infrastructure investment: Identify high-traffic endpoints and plan capacity accordingly. Know whether your infrastructure costs are supporting business value or used without programmatic compensation mechanism.
            • Implement tiered access strategies: Serve different content or pricing based on AI agent verification and intent.
            • Detect anomalies and emerging patterns: Spot unusual patterns that might indicate emerging threats or opportunities. Real-time visibility helps you respond quickly to changes in AI bot behavior.
            • Support cross-organizational strategy: Provide data to stakeholders across security, product, and business teams for informed decisions about AI bot access policies and monetization opportunities.
            • Customize as needed: AI Traffic analyses are emitted as CloudWatch metrics that an organization can use to customize CloudWatch or another supported observability product as needed. Moreover, by using CloudWatch metrics, an organization can build proactive measures such as alerts or business actions such as rate or limit changes.
            • Monetize AI traffic at the edge: For a reference architecture that combines WAF Bot Control AI visibility, traffic control, and content monetization using the x402 payment protocol, see the sample-x402-content-monetization-with-cloudfront-and-waf project on GitHub. It demonstrates how to classify AI bot traffic, enforce per-path pricing policies, and settle payments at the edge using Amazon CloudFront and Lambda@Edge – with zero changes to your existing origins.

              Note: This AWS Samples solution is not a supported product in their own right, but educational examples to help our customers use our products for their applications. As our customer, any applications you integrate this example into should be thoroughly tested, secured, and optimized according to your business’s security standards & policies before deploying to production or handling production workloads. Deploying it will provision resources that incur additional AWS charges, so review costs before deploying and delete the stack when no longer needed.

            Programmatic access: Automate your AI traffic insights

            In addition to the console dashboard, you can programmatically query AI bot traffic data using the GetTopPathStatisticsByTraffic action, available through the AWS WAF API, AWS SDKs, and AWS CLI. This action returns the top URI paths by bot traffic volume for a given web ACL and time window. Each path in the response includes request counts, traffic percentages, and the top bots accessing it. You can filter results by bot category (for example, ai), organization, or specific bot name, and use a URI path prefix (for example, /api/) to drill down into specific areas of your application. The following AWS CLI example shows how to query the top paths accessed by AI bots for a specific web ACL.

            The following AWS CLI example shows how to query the top paths accessed by AI bots for a specific web ACL:

            aws wafv2 get-top-path-statistics-by-traffic \
              --web-acl-arn "arn:aws:wafv2:us-east-1:123456789012:global/webacl/ExampleWebACL/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" \
              --scope "CLOUDFRONT" \
              --time-window StartTime=2026-02-25T00:00:00Z,EndTime=2026-02-26T00:00:00Z \
              --bot-category "ai" \
              --uri-path-prefix "/api/" \
              --limit 5 \
              --number-of-top-traffic-bots-per-path 3

            A sample response:

            {
              "TopPathStatistics": [
                {
                  "Path": "/api/v1/products",
                  "RequestCount": 145320,
                  "TrafficPercentage": 32.4,
                  "TopBots": [
                    { "BotName": "ExampleBotA", "Organization": "ExampleOrgA", "RequestCount": 98210 },
                    { "BotName": "ExampleBotB", "Organization": "ExampleOrgB", "RequestCount": 47110 },
                    { "BotName": "ExampleBotC", "Organization": "ExampleOrgC", "RequestCount": 0 }
                  ]
                },
                {
                  "Path": "/api/v2/search",
                  "RequestCount": 87650,
                  "TrafficPercentage": 19.5,
                  "TopBots": [
                    { "BotName": "ExampleBotA", "Organization": "ExampleOrgA", "RequestCount": 52300 },
                    { "BotName": "ExampleBotC", "Organization": "ExampleOrgC", "RequestCount": 35350 },
                    { "BotName": "ExampleBotB", "Organization": "ExampleOrgB", "RequestCount": 0 }
                  ]
                }
              ],
              "TimeWindow": {
                "StartTime": "2026-02-25T00:00:00Z",
                "EndTime": "2026-02-26T00:00:00Z"
              }
            }

            Programmatic access enables you to:

            • Build custom dashboards or integrate AI traffic data into existing observability platforms.
            • Automate alerting when specific paths see unusual bot traffic spikes.
            • Feed traffic data into business intelligence pipelines for content monetization decisions.
            • Investigate and debug AI bot activity within a specific timeframe to identify the root cause of traffic anomalies or incidents.

            For detailed usage information, see the GetTopPathStatisticsByTraffic API reference and the AWS CLI command reference. This API pairs naturally with the CloudWatch metrics approach described above, giving you both real-time metric streams and on-demand path-level analytics for comprehensive AI traffic management.

            Availability

            For customers on flat-rate pricing plans, the AI Traffic Analysis dashboard is included with all paid plans. Read more about CloudFront flat-rate pricing in the launch blog post. For AWS WAF customers not subscribed to flat-rate plans, the AI traffic analysis dashboard is available at no additional cost. See AWS WAF pricing for details.

            Get started today

            The AI Traffic Analysis dashboard represents a significant step forward in managing the intersection of AI and web security. As AI agents continue to grow as a percentage of overall web traffic, having the right visibility tools becomes essential for both security and business success.

            To learn more about AWS WAF Bot Control and AI Traffic Analysis dashboards, visit the AWS WAF Developer Guide or explore the feature directly in your AWS WAF console.

            If you have feedback about this post, submit comments in the Comments section below.

            Christopher Jen

            Christopher Jen

            Christopher is a go-to-market leader at Amazon Web Services (AWS), specializing in Edge Services, Cyber Security, AI Security, and Agentic Identification. Based in London, he’s a seasoned business development and partnerships executive with a track record of driving growth across cloud, security, and emerging technology domains.

            Eitav Arditti

            Eitav Arditti

            Eitav is an AWS Senior Solutions Architect with over 15 years of experience in the AdTech industry. He specializes in Edge computing, Serverless, Containers, and Platform Engineering. Eitav helps organizations design cost-efficient, large-scale AWS architectures that integrate cloud-focused and Edge services such as CloudFront and WAF to deliver secure, performant, and globally scalable solutions that accelerate business growth.

            Author

            Kaustubh Phatak

            Kaustubh is a product leader specializing in AI/ML systems and enterprise security solutions. He has led cross-functional teams in deploying AI-powered products at scale, working closely with security architects and CISOs to address the intersection of AI innovation and cybersecurity risk. His work focuses on translating complex technical capabilities into business value, particularly in emerging technology domains where traditional frameworks don’t apply.

            Five ways to use Kiro and Amazon Q to strengthen your security posture

            5 May 2026 at 17:00

            A Monday morning security alert flags unauthorized access attempts, security group misconfigurations, and AWS Identity and Access Management (IAM) policy violations. Your team needs answers fast.

            Security teams are using Kiro and Amazon Q Developer to handle repetitive tasks—scanning resources, drafting policies, and researching Common Vulnerabilities and Exposures (CVEs)—so engineers can focus on risk decisions and complex scenarios that require human judgment, resulting in faster threat response and more consistent security coverage.

            This post shows you five ways to use Kiro and Amazon Q Developer to strengthen your AWS security posture based on the AWS Well-Architected Framework Security Pillar. Each technique builds on a common foundation described after the tool overview below.

            About these tools

            Amazon Web Services (AWS) gives customers choices when it comes to AI-assisted development and security automation. Whether you prefer Kiro’s agentic integrated development environment (IDE) experience or the deep integration of Amazon Q Developer into your existing AWS environment, both tools can help you implement the security practices described in this post. The right choice depends on your team’s workflow, and in many cases both tools are complementary and can be used together.

            Kiro is an AI-powered, agentic, IDE designed by AWS for specification-driven development, combining natural language prompting with structured, intentional coding to generate, test, and deploy applications.

            Amazon Q Developer is the generative AI assistant integrated into AWS development and cloud environments, designed to answer questions, generate code, troubleshoot issues, and automate operational tasks across AWS services.

            For setup instructions and to learn more, see the Kiro documentation and Amazon Q Developer documentation.

            1. Embed security best practices with persistent context

            Providing AI assistants with the right context helps them produce more consistent and relevant results. Each of the five techniques in this post becomes significantly more powerful when your AI assistant already understands your organization’s security standards. Setting up persistent context first means every subsequent interaction builds on that foundation, and the results you get from triage, remediation, reviews, and policy development will better reflect your specific environment rather than generic best practices.

            Without persistent context, you need to repeat the same security requirements in every prompt such as "enable encryption, use least privilege IAM settings, and enable logging," which leads to inconsistent results and missed controls. Amazon Q Developer IDE Plugin rules and Kiro steering files (CLI and IDE) solve exactly this problem: you can use them to codify your organization’s security standards so AI automatically builds secure infrastructure consistently, without requiring you to repeat requirements in every prompt. Both tools support this capability independently, so you can configure whichever fits your workflow, or use both together for coverage across your full development environment. The following steps show you how to get started with each.

            For Amazon Q Developer:

            1. Create directory: .amazonq/rules/ in your project root.
            2. Create file: .amazonq/rules/security-standards.md.
            3. Paste your organization’s security standards in natural language (see “Example security standards context file” below).

            For Kiro (steering files):

            In Kiro, persistent context documents are called steering files. They give the agent ongoing awareness of your architecture decisions, coding standards, and security requirements across every interaction and every session.

            1. Create file: security-standards.md in your project root.
            2. Reference it in prompts: Using security-standards.md as context, create....

            Pro tip: You can use Kiro itself to help you create steering files. Describe your security requirements in natural language and ask Kiro to generate a structured steering file for your review before saving and activating it. This means your AI assistant can help you build the very context it will later use, making the setup process faster and more thorough.

            Example security standards context file:

            # AWS Security Standards
            
            ## Identity and Access Management
            - All IAM roles must use least privilege principles
            - Require MFA for console access
            - Enable IAM Access Analyzer for all accounts
            - Rotate access keys every 90 days
            - Use IAM roles for EC2 instances, never embed access keys
            
            ## Data Protection
            - Enable encryption at rest for all storage services (S3, EBS, RDS)
            - Use AWS KMS customer-managed keys for sensitive data
            - Enable encryption in transit with TLS 1.2 minimum
            - Implement S3 bucket policies denying unencrypted uploads
            - Enable versioning and MFA delete for critical S3 buckets
            
            ## Infrastructure Protection
            - Security groups must follow least privilege (no 0.0.0.0/0 on sensitive ports)
            - Deploy resources in private subnets when possible
            - Enable VPC Flow Logs for network monitoring
            - Use AWS WAF for public-facing applications
            - Implement Network ACLs as additional defense layer
            
            ## Detective Controls
            - Enable CloudTrail in all regions with log file validation
            - Configure CloudWatch alarms for security events
            - Enable GuardDuty for threat detection
            - Set up AWS Config rules for compliance monitoring
            - Implement centralized logging with retention policies
            
            ## Incident Response
            - Create SNS topics for security alerts
            - Configure automated responses with AWS Lambda
            - Maintain runbooks for common security incidents
            - Enable AWS Systems Manager for secure instance access
            - Implement automated backup and recovery procedure

            What this unlocks:

            Without persistent context, a prompt like Create a Lambda function to process customer data could produce a basic function with no encryption, logging, or IAM configuration. AI output is non-deterministic, meaning that without guidance it might or might not include those controls. Steering files and rules documents minimize those variables by providing stronger guidance as part of every prompt and inference input.

            With your security standards embedded as in the example above, however, the same prompt generates a function with KMS-encrypted environment variables, a CloudWatch log group with 90-day retention, least-privilege IAM, VPC placement in private subnets, a dead-letter queue, and AWS X-Ray tracing—all automatically.

            Where it works:

            This persistent context approach applies across both tools and all infrastructure generation workflows:

            • Amazon Q Developer IDE Plugin: Rules in .amazonq/rules/ apply automatically to every code generation and review interaction.
            • Kiro: Steering files provide the agent with continuous architectural and security awareness across sessions and projects.

            The shift-left impact:

            This approach isn’t a replacement for your existing continuous integration and delivery (CI/CD) security automation. It’s a powerful complement to it, and that distinction matters. By embedding security standards directly into the development workflow, you shift security validation further left than pipeline checks can reach. Developers across your organization, not just security specialists, can generate infrastructure that meets your security standards from the first line of code. This scales security expertise into non-security roles, empowers development teams to self-serve on compliance requirements, and reduces the volume of findings that ever reach your automated pipeline checks.

            The result is security functioning as an enabler of faster development rather than a gate that slows it down, and security engineers spending their time on policy design and complex risk decisions rather than remediating avoidable misconfigurations.

            Measurable impact:

            Track these metrics to quantify the value of persistent context:

            • Security findings during code review: Establish a 30–60 day baseline before enabling context files, then compare
            • Time from development to deployment: Track average cycle time before and after
            • Remediation cost: Research consistently shows defects fixed in development cost significantly less than those fixed in production. Track your own ratio for 60 days
            • Standards consistency: Audit a random sample of infrastructure pull requests for compliance with your top 10 policies

            Implementation recommendation: Start by codifying your top 10 most frequently violated security policies as context. Measure the reduction in these specific findings over 30–60 days to quantify the impact on your team.

            2. Accelerate security finding triage and investigation

            AWS Security Hub consolidates findings from services such as Amazon GuardDuty, AWS Config, Amazon Inspector, and third-party security tools into a single dashboard, providing centralized security finding visibility and built-in triage capabilities across your AWS environment. AWS Security Hub Extended will bring even more capabilities into this mix, giving customers expanded control and additional opportunities to leverage the AI-assisted workflows described in this post at greater scale and with deeper integration across your security toolchain.

            Kiro can complement Security Hub by helping you correlate findings across accounts, understand CVE context, and develop remediation approaches, including:

            • Query findings using natural language across multiple AWS accounts and AWS Regions
            • Understand specific CVEs and their potential impact on your infrastructure
            • Generate investigation queries for AWS CloudTrail and Amazon Virtual Private Cloud (Amazon VPC) Flow Logs
            • Correlate security events across different time periods and services
            • Access the latest AWS security documentation and best practices

            How it works – Model Context Protocols:

            To enable these capabilities, Kiro uses Model Context Protocols (MCPs)—a standardized way for AI assistants to securely connect with external tools, services, and data sources, enabling them to take actions, retrieve real-time information, and interact with APIs beyond their built-in capabilities.

            Open source MCP servers for AWS are a suite of specialized MCP servers that enable Kiro to interact with AWS security services, providing real-time visibility into your security posture. To get started, configure security-focused MCP servers in your Kiro settings file (as shown in the following example). For full instructions on configuring MCP servers in Kiro, see the Kiro MCP documentation.

            Note on authentication: Before querying Security Hub, verify you have configured valid AWS credentials for the target account. Set the AWS_PROFILE value to a named profile in your ~/.aws/credentials file that has the appropriate permissions, or configure credentials using the AWS Command Line Interface (AWS CLI) (aws configure). Without valid credentials for the target account, Kiro will not be able to retrieve findings.

            {
                "mcpServers": {
                    "awslabs.aws-api-mcp-server": {
                        "command": "uvx",
                        "args": ["awslabs.aws-api-mcp-server@latest"],
                        "env": {
                            "FASTMCP_LOG_LEVEL": "ERROR",
                            "AWS_PROFILE": "<PROFILE>",
                            "AWS_REGION": "us-east-1"
                        },
                        "timeout": 120000,
                        "disabled": false
                    },
                    "awslabs.cloudtrail-mcp-server": {
                        "command": "uvx",
                        "args": ["awslabs.cloudtrail-mcp-server@latest"],
                        "env": {
                            "FASTMCP_LOG_LEVEL": "ERROR",
                            "AWS_PROFILE": "<PROFILE>"
                        },
                        "disabled": false
                    },
                    "awslabs.iam-mcp-server": {
                        "command": "uvx",
                        "args": ["awslabs.iam-mcp-server@latest"],
                        "env": {
                            "FASTMCP_LOG_LEVEL": "ERROR",
                            "AWS_PROFILE": "<PROFILE>"
                        },
                        "disabled": false
                    }
                }
            }

            Configure the following security-focused MCP servers to get started:

            • AWS API MCP Server: Interact with Security Hub, GuardDuty, IAM Access Analyzer, and AWS Config through AWS CLI commands
            • CloudTrail MCP Server: Audit trail analysis and compliance monitoring
            • AWS IAM MCP Server: Manage IAM users, roles, policies, and permissions
            • AWS Knowledge MCP Server: Access up-to-date AWS security documentation and best practices

            For a full list of available MCP servers, see the awslabs/mcp GitHub repository.

            Example: querying Security Hub with Kiro:

            1. Open your terminal or Kiro IDE.
            2. Enter the following command:
            "Show me all critical security findings from Security Hub in my production account ID <ACCOUNT ID>"

            Example output:

            > Found 4 critical security findings in account 123456789012:
            
            ## Configuration Issues (2)
            
            1. SSM.7 - SSM documents block public sharing disabled
            - Status: FAILED (since July 17, 2025)
            - Impact: Systems Manager documents can be publicly shared
            - Remediation: Enable block public sharing setting for SSM documents
            - [Documentation](https://docs.aws.amazon.com/console/securityhub/SSM.7/remediation)
            
            2. Config.1 - AWS Config not properly configured
            - Status: FAILED (since March 4, 2025)
            - Issue: Config isn't recording required IAM resource types (User, Role, Group, Policy)
            - Standards affected: CIS, NIST 800-53, PCI DSS, AWS Foundational Security
            - Remediation: Enable recording for IAM resources in AWS Config
            - [Documentation](https://docs.aws.amazon.com/console/securityhub/Config.1/remediation)
            
            ## Vulnerabilities (2)
            
            3. CVE-2020-36242 in Lambda function: MyLambdaOne
            - Package: cryptography version 3.2.1
            - CVSS Score: 9.1 (Critical)
            - Issue: Integer/buffer overflow in Fernet encryption class
            - Fix: Upgrade to cryptography 3.3.2
            - Function: SPC-1233HH5R-MyLambdaOne-lUh3ESH0MdXF
            
            4. CVE-2020-36242 in Lambda function: AutoUpdateMyLambdaOne
            - Package: cryptography version 3.2.1
            - CVSS Score: 9.1 (Critical)
            - Same vulnerability as above
            - Function: SPC-1233HH5R-AutoUpdateMyLambdaOne-d9HIBfxThbFW

            Real-world impact:
            Security finding triage that previously required navigating multiple consoles, correlating logs manually, and researching CVE databases can be accelerated significantly. Teams that have integrated AI-assisted triage into their Security Hub workflows report reducing mean time to triage for critical findings from hours to minutes, enabling faster containment and more consistent coverage across accounts.

            3. Accelerate remediation of security findings in your infrastructure as code

            AI assistants can scan your infrastructure code and flag security issues with specific fix recommendations. However, implementing these changes requires careful review, testing, and validation before any changes reach production.

            Important: AI-generated remediation suggestions must be reviewed by a qualified security engineer before implementation. Automated application of AI-generated changes without human validation can introduce unintended misconfigurations or service disruptions. Treat AI output as a starting point, not a finished product.

            The workflow:
            You can execute this workflow in either Kiro or Amazon Q Developer, depending on which tool fits your existing development environment:

            1. Ask Kiro or Amazon Q Developer to scan your infrastructure files and identify security gaps.
            2. Review AI-generated remediation suggestions with your security team.
            3. Test changes in non-production environments.
            4. Validate using AWS security services such as IAM Access Analyzer, AWS Config, and Security Hub.
            5. Deploy to production with monitoring and rollback procedures in place.

            Example prompt:

            "Scan my infrastructure at /path/to/templates, identify all S3 buckets without encryption, enable AES-256 encryption, add bucket policies to deny unencrypted uploads, and provide the deployment command"

            What happens:

            The AI assistant analyzes your infrastructure files, whether written in AWS CloudFormation, Terraform , or AWS Cloud Development Kit (AWS CDK), and identifies resources that violate security best practices. It then implements controls such as encryption at rest using AWS Key Management Service (AWS KMS) or Amazon Simple Storage Service (Amazon S3)-managed keys, adds bucket policies enforcing encryption in transit, configures public access blocks, and generates the exact deployment command with a change preview so you can review what will be modified before anything is applied.

            Based on the example security standards context file above, the following controls would be applied across all generated infrastructure: encryption at rest and in transit, least-privilege IAM policies, security group optimizations, VPC configurations, logging enablement, and backup and recovery settings.

            Validation required:
            AI-generated configurations deserve the same thoughtful review as other infrastructure code. Even a policy that looks correct on the surface might need tuning to match your organization’s least-privilege standards, or encryption settings might need adjusting to satisfy specific compliance requirements. Running those changes through a non-production environment and having a human confirm the results before anything reaches production are part of good infrastructure practices, whether the code was written by a person or generated by AI.

            Real-world impact:

            Identifying non-compliant resources across multiple accounts manually can take many hours and generating remediation templates for each resource can add significant time. Security teams that have adopted AI-assisted infrastructure scanning report spending less time on manual identification and template generation, and with AI assistance the same identification and drafting work can be completed in much less time. Customers report that a full remediation cycle that previously occupied their team for the better part of a day can be completed in under an hour when AI handles the scanning and template generation. It is worth noting that manual remediation time grows considerably at scale, as remediating dozens of non-compliant resources is not a linear exercise. Validation time in non-production environments remains essential regardless of how the remediation was generated, and should always be factored into your planning.

            4. Perform in-depth security reviews

            Amazon Q Developer and Kiro can analyze your infrastructure code and identify potential security issues across multiple categories aligned with the AWS Well-Architected Framework Security Pillar.

            Using Amazon Q Developer:

            1. Open your infrastructure file in your IDE.
            2. Select the code you want to review.
            3. Open the context menu and choose Send to Amazon Q, then choose Optimize.
            4. Select Focus on security best practices.

            Using Kiro:

            1. Open your infrastructure file in Kiro.
            2. Enter a natural language prompt such as: Perform a comprehensive security review of this CloudFormation template and identify all deviations from our standards.
            3. Kiro will automatically apply your steering files as additional context when generating its response.
            4. Review the findings and iterate with follow-up prompts.

            Security categories evaluated: For the complete, up-to-date list of security categories and controls, see the AWS Well-Architected Framework Security Pillar documentation. Current categories include but are not limited to:

            • Identity and access management: Overly permissive IAM policies, missing multi-factor authentication (MFA) requirements, unused credentials and access keys, cross-account access risks
            • Detective controls: CloudTrail logging configuration, Amazon CloudWatch alarm coverage, GuardDuty enablement status, and AWS Config rule implementation
            • Infrastructure protection: Security group misconfigurations, public subnet exposure, missing AWS WAF rules, unencrypted network traffic
            • Data protection: Storage encryption status, KMS key rotation policies, backup configurations, S3 bucket access controls
            • Incident response: Amazon Simple Notification Service (Amazon SNS) alerting setup, log retention policies, automated response mechanisms

            Example output:

            Security Recommendations:
            - Enable S3 bucket encryption with KMS: Critical
            - Implement least privilege IAM policies: High
            - Enable GuardDuty threat detection: High
            - Configure VPC Flow Logs: Medium
            - Add WAF rules for API Gateway: Medium
            - Enable CloudTrail in all regions: Critical
            - Implement automated backup policies: High
            
            Total security improvements: 23 findings across 5 Well-Architected pillars

            Keeping your configuration files current:

            A security architect review remains valuable for keeping your steering files and rules documents complete and current. The goal is an AI assistant that already understands your environment, not one that needs correcting after every interaction. Treat your configuration files as living documents and update them when your security standards evolve, when new services are adopted, or when post-incident reviews reveal gaps. As this post notes, project rules reduce architectural drift and help maintain consistency as AI agents operate more autonomously.

            Real-world impact:

            Security reviews that previously required a security engineer to manually inspect infrastructure templates line by line can be completed in significantly less time with AI assistance. Teams using AI-assisted security reviews as a pre-commit gate—before code reaches CI/CD pipeline checks—report catching a meaningful portion of security findings earlier in the development cycle where they are faster and less costly to address. Integrating this review step into pull request workflows means security validation happens continuously rather than only at deployment gates.

            5. Assist with service control policy development

            You can use AWS Organizations Service Control Policies (SCPs) to apply preventive controls consistently across every account in your organization, enforcing security baselines without relying on individual account administrators. Kiro can generate initial SCP drafts from natural language security requirements, speeding up the drafting and iteration process considerably. Because SCPs are preventive controls that can’t be bypassed by administrators, misconfigurations can cause organization-wide service disruptions, making expert validation and staged testing essential before any SCP reaches production.

            Step 1: Generate an SCP draft:

            Describe your security requirements in natural language:

            "Create an SCP with these security controls:
            - Deny creation of S3 buckets without encryption
            - Require MFA for IAM user console access
            - Prevent public RDS snapshots
            - Deny security group rules allowing 0.0.0.0/0 on sensitive ports
            - Enforce encryption for all EBS volumes
            - Require VPC Flow Logs on all VPCs
            - Deny IAM policy creation without approval tags
            - Restrict resource creation to approved regions only"

            Kiro generates a complete SCP policy JSON with proper deny statements, condition keys for MFA and encryption enforcement, resource-level restrictions, and regional compliance requirements.

            Step 2: Validate and lint the SCP:

            Use Kiro or Amazon Q Developer to assist with policy linting and initial testing as a first layer of validation. IAM Policy Autopilot, available as a Kiro Power with one-click installation directly from the Kiro IDE, can analyze your application’s usage and generate necessary permissions based on the SDK calls it discovers. IAM Policy Autopilot also integrates as an MCP server with Kiro, Amazon Q Developer, and other MCP-compatible coding assistants, making it a natural part of your existing workflow rather than a separate tool.

            "Review this SCP JSON for syntax errors, overly broad deny statements, and missing condition keys. Flag any statements that could unintentionally block legitimate operations."

            The IAM Policy Simulator then adds another layer of validation on top of the AI-assisted linting, so you can test policy behavior, verify condition keys are correctly applied, and confirm that no legitimate operations are unintentionally blocked. IAM Policy Autopilot complements existing IAM tools such as IAM Access Analyzer by providing functional policies as a starting point, which you can then validate using IAM Access Analyzer policy validation or refine over time with unused access analysis. Together, these tools form a layered validation approach where each one strengthens the output of the previous step.

            Step 3: Test in a sandbox environment:

            Create a test organizational unit (OU) with non-production accounts and apply the SCP to the test OU. Attempt operations that should be blocked and confirm that no legitimate operations are unintentionally blocked. Use Kiro to pre-validate your infrastructure code against the proposed SCP before sandbox testing:

            "Analyze my current infrastructure against this proposed SCP and identify resources that would be non-compliant"

            This scan covers your infrastructure code files. For live account scanning across your organization, use the following AWS services:

            • AWS Config with the Config Aggregator and Conformance Packs for continuous compliance monitoring across your organization.
            • IAM Access Analyzer for automated reasoning-based analysis of external access, internal access, and unused permissions.
            • Account Assessment for AWS Organizations for bulk scanning of identity-based, resource-based, and service control policies across all accounts.
            • Security Hub for centralized aggregation of compliance findings and security scores across your entire organization.

            Step 4: Security architect review:

            Engage your security architects to identify potential risks and verify the policy aligns with your security framework. Check for conflicts with existing SCPs by reviewing all SCPs attached to parent OUs and the root in the AWS Organizations console. Use the IAM Policy Simulator to test interactions between policies and verify that emergency access procedures ( SEC03-BP03 Establish emergency access process – Security Pillar and SEC10-BP05 Pre-provision access – Security Pillar) remain functional before any production rollout.

            Step 5: Staged rollout:

            Deploy to development accounts first and monitor for policy violations and operational issues. Gradually expand to additional environments and maintain documented rollback procedures throughout the process.

            Important: It’s strongly recommended not to deploy AI-generated SCPs directly to production without thorough expert review and staged testing. A misconfigured SCP can cause organization-wide service disruptions affecting every account in your organization.

            Real-world impact:

            SCP drafting that previously required security architects to write and iterate on complex JSON policy documents manually, often spanning multiple review cycles over several days, can be condensed when AI handles the initial drafting and linting. Your architects can then focus their time on policy design, edge case analysis, and organizational impact assessment rather than JSON syntax and structure.

            Responsible implementation framework

            Adopting AI-assisted security workflows is most effective when introduced gradually, with clear validation gates at each stage. The following two-phase approach gives your team time to build confidence, measure results, and establish the internal practices needed before expanding to production environments.

            • Phase 1: Development and testing (weeks 1–4): Start by testing AI-generated security controls in isolated development accounts. Validate functionality, identify edge cases, and deploy to a dedicated testing environment with thorough security validation. Use IAM Access Analyzer, AWS Config, and Security Hub to verify that generated controls behave as expected. This phase is also the right time to build internal expertise across both your security team and your development teams, so that knowledge of what works and what requires human review is shared broadly from the start.
            • Phase 2: Staging and production (week 5 and later): Apply the validated controls to a staging environment that mirrors production. Conduct penetration testing where appropriate and validate that monitoring and alerting function correctly before expanding further. Gradually roll out to production accounts with continuous monitoring in place. Maintain rollback procedures throughout and establish feedback loops so that lessons learned in production flow back into your steering files, rules documents, and validation processes over time.

            Key takeaways

            What distinguishes the approach in this post from general guidance on AI coding assistants is the specificity of the security integration. There’s no shortage of content about how AI assistants accelerate development. What this post focuses on is how to configure both Kiro and Amazon Q Developer to perform security-specific tasks: triaging findings from Security Hub, remediating infrastructure code vulnerabilities against your organization’s defined standards, conducting Well-Architected security reviews, drafting and validating SCPs, and generating secure-by-default infrastructure through persistent context that reflects your environment rather than generic defaults.

            Kiro is an agentic IDE that helps you go from prototype to production with spec-driven development, and its steering files give the agent persistent awareness of your security standards across every session. Amazon Q Developer complements this by providing deep integration into your existing AWS environment and IDE workflows. Together, these tools extend your security team’s reach into every stage of the development lifecycle, scale security expertise into development teams, and reduce the gap between when vulnerabilities are introduced and when they are caught. As the AWS Well-Architected Framework Security Pillar establishes, embedding security early and consistently across the development process is foundational to a strong security posture.

            These five techniques aren’t about replacing your security controls. They’re about making security a natural part of how your teams build on AWS, regardless of whether they’re security specialists or application developers. In addition to the five techniques covered in this post, the following AWS capabilities complement this approach and are worth exploring for a more complete picture:

            • Amazon Inspector is a vulnerability management service that continually scans AWS workloads for software vulnerabilities, code vulnerabilities, and unintended network exposure. It automatically discovers and scans Amazon EC2 instances, container images in Amazon ECR, AWS Lambda functions, and first-party code repositories. Amazon Inspector integrates directly into CI/CD pipelines through plugins for Jenkins, TeamCity, GitHub Actions, and Amazon CodeCatalyst, which teams can use to catch vulnerabilities before deployment. Its code security capabilities include Static Application Security Testing (SAST), Software Composition Analysis (SCA), and infrastructure as code (IaC) scanning, with native integration to GitHub and GitLab. All findings are surfaced directly in Security Hub for centralized visibility and response across your organization.
            • Amazon Q Developer security scanning provides real-time security issue detection in the IDE, including SAST scanning for security vulnerabilities, secrets detection, IaC security evaluation, and software composition analysis for third-party dependencies. These capabilities are available across JetBrains, Visual Studio Code, and Visual Studio.
            • Kiro Powers are curated and pre-packaged MCP servers, steering files, and hooks validated by Kiro partners to accelerate specialized development and deployment use cases. Security-relevant Kiro Powers include the IAM Policy Autopilot Kiro Power for baseline IAM policy generation and the real-time coding security validation MCP server pattern for Kiro.
            • AWS Security Agent is a frontier AI agent that proactively secures your applications throughout the development lifecycle. Security teams define organizational security requirements once in the AWS Security Agent console, such as approved encryption libraries, authentication frameworks, and logging standards, and AWS Security Agent then automatically validates these requirements throughout development by evaluating architectural documents and code against your defined standards. It provides three core capabilities: design security review for architecture documents, code security review that automatically analyzes pull requests against your defined standards across connected repositories, and on-demand penetration testing that discovers, validates, and reports vulnerabilities through sophisticated multi-step attack scenarios customized for each application. When vulnerabilities are found, AWS Security Agent creates pull requests with ready-to-implement fixes directly in your code repository. Customers report that AWS Security Agent compresses penetration testing timelines from weeks to hours, transforming penetration testing from a periodic bottleneck into an on-demand capability that reduces risk exposure and scales security reviews to match development velocity.
            • AWS Security Hub automated response and remediation provides pre-built playbooks for common findings using AWS Systems Manager Automation, enabling your team to act on findings faster and more consistently.

            Getting started

            If you’re new to AI-assisted security workflows, the following week-by-week approach gives your team a practical path forward without overextending before the foundation is in place.

            • Weeks 1 and 2: Set up your persistent context files with your top 10 security policies as described in the foundational setup section above. Configure MCP servers in Kiro for Security Hub and CloudTrail access and verify that credentials are correctly configured for your target accounts.
            • Weeks 3 and 4: Run your first AI-assisted security review on a non-production infrastructure template. Compare the findings against your last manual review to establish a baseline for measuring impact over time.
            • Weeks 5 and 6: pilot AI-assisted SCP drafting for one new preventive control. Run the full validation workflow including AI-assisted linting, IAM Policy Autopilot, and the IAM Policy Simulator before any production application.
            • From that point forward: Measure the metrics outlined in the foundational setup section, update your steering files and rules documents as your standards evolve, and share findings across your security team, development teams, and platform engineering teams. The knowledge of what works and what requires human judgment is valuable to everyone who touches infrastructure in your organization.

            Conclusion

            Kiro and Amazon Q Developer give security teams practical tools to accelerate threat response and maintain consistent security coverage by handling the tasks that consume the most time with the least strategic value: scanning for known misconfigurations, drafting policy JSON, researching CVEs, and generating secure infrastructure. These AI assistants are most effective when paired with security engineers, as they accelerate assessments and code generation while human review, policy design, and risk judgment remain essential throughout.

            By implementing the five techniques outlined in this post, starting with embedding security best practices through persistent context and then applying that foundation to Security Hub finding triage, infrastructure code remediation, in-depth Well-Architected security reviews, and SCP development, your team can strengthen your AWS security posture while maintaining the standards your organization requires.

            AWS services such as Security Hub, IAM Access Analyzer, AWS Config, and CloudTrail provide the foundation for these AI-assisted workflows, enabling centralized visibility and automated validation of security controls across your environment. Emergency access procedures should be established and validated before deploying any preventive controls such as SCPs, following the break-glass guidance in the AWS Well-Architected Security Pillar and the AWS Prescriptive Guidance for break-glass access.

            Start small with non-production environments, establish clear validation processes, measure results, and gradually expand your use of AI assistants as your team builds expertise and confidence. The result is faster threat response, more consistent security coverage, and security engineers focused on complex decisions rather than repetitive tasks.

            Additional resources

            If you have feedback about this post, submit comments in the Comments section below


            Roger Nem

            Roger Nem

            Roger is an Enterprise Technical Account Manager (TAM) supporting Healthcare & Life Science customers at Amazon Web Services (AWS). As a Security Technical Field community specialist, he helps enterprise customers design secure cloud architectures aligned with industry best practices. Beyond his professional pursuits, Roger finds joy in quality time with family and friends, nurturing his passion for music, and exploring new destinations through travel.

            Securing open proxies in your AWS environment

            4 May 2026 at 20:16

            This article shows you how to identify and secure open proxies in your AWS environment to prevent abuse, protect your IP address reputation, and control costs.

            An open proxy is a server that forwards traffic on behalf of internet users without requiring authentication. While proxies can support legitimate use cases such as load balancing or caching, open proxies allow unrestricted access that threat actors can use to hide harmful activity. In Amazon Web Services (AWS) environments, open proxies often result from misconfigured Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, or compute resources such as AWS Lambda functions. These resources expose proxy functionality without access controls.

            Open proxies come in several forms. Common open proxies can include:

            • HTTP proxies: HTTP proxies forward HTTP requests to web servers, making them useful for web traffic management. These proxies can create potential issues when they’re unsecured.
            • SOCKS proxies: SOCKS proxies support a wider range of traffic types and provide more flexibility. These proxies create a broader potential for misuse.
            • Transparent proxies: Transparent proxies intercept traffic without the client’s knowledge and are often used to filter content. These proxies can become security liabilities when misconfigured.
            • Reverse proxies: Reverse proxies help with internal routing. Unauthorized users can misuse these proxies if they’re exposed.

            Knowing these risks can help you better protect your AWS environment.

            Security risks

            Because of the unrestricted configuration of open proxy servers, threat actors target them to conduct denial of service (DoS) events, intrusion attempts, distribute spam, and other forms of unauthorized activity. These open proxy servers allow threat actors to hide their actual IP address and other forms of identification from the intended targets.

            When your AWS infrastructure hosts an open proxy, several risks emerge that can affect both your operations and customers:

            • Threat actors can misuse your resources, which can result in your IP address being added to security service and reputation system block lists. This can affect your legitimate business operations and customer access. When external parties use your infrastructure for harmful activities, the reputation damage extends beyond immediate technical concerns to affect your ability to reach customers and partners.
            • Unexpected costs from resource consumption occur when threat actors use your bandwidth and compute capacity. The traffic patterns that proxy abuse generate can also alert AWS security monitoring systems and create additional operational overhead as you investigate and respond to these alerts.
            • Service disruptions might affect your legitimate workloads because unauthorized traffic competes for resources with your business-critical applications. This competition for resources can potentially degrade performance or cause availability issues for your customers.

            Implementing security measures

            To prevent the risks associated with open proxies, it’s essential to implement proper security controls for proxy services in AWS environments. The following guidance is a comprehensive approach that you can follow to secure your proxy infrastructure.

            Access control implementation

            An important security step is to use passwords and authentication mechanisms to restrict access to proxy services. Configure your proxies to accept connections only from known, trusted IP address ranges. For Elastic Load Balancing (ELB), limit access based on source IP addresses and add authentication to proxies behind the load balancers. When you create new instances in Amazon Elastic Kubernetes Service (Amazon EKS), limit access to your balancer in each instance. If instances don’t have public IP addresses, then you can limit access to the balancer instead. If instances have public IP addresses, then you must limit access to those IP addresses.

            When possible, use AWS PrivateLink virtual private cloud (VPC) endpoints to provide private connectivity to AWS services without exposing them to the internet. Deploy proxy services in private subnets with controlled outbound access through NAT gateways or other controlled channels. For Amazon EC2 and Amazon Lightsail resources, update the attached security group to prevent public internet access. To secure the proxy, you must either limit access to specific IP addresses or implement authentication on the endpoint.

            Authentication and authorization

            Turn on authentication for the proxy software and use strong credentials, certificates, or integration with AWS Identity and Access Management (IAM) and AWS Directory Service. Apply IAM policies with the principle of least privilege to limit access to only what users need to perform their tasks. This approach reduces the potential effects of credential compromise and helps maintain clear accountability for resource access.

            Monitoring and detection

            To detect unusual proxy activity, configure Amazon Virtual Private Cloud (Amazon VPC) Flow Logs, AWS CloudTrail, and Amazon GuardDuty. Use Amazon CloudWatch alarms to notify you of abnormal traffic patterns that might indicate unauthorized use of your proxy services. These monitoring capabilities provide visibility into your network traffic patterns and help you identify both legitimate usage and potential security concerns.

            Deployment best practices

            Use HTTPS for ELB traffic to protect data in transit, and restrict security groups to necessary ports to minimize the surface area for potential misuse. Integrate AWS WAF with balancers to filter web traffic based on rules that you define. You can also use AWS Network Firewall for advanced traffic filtering capabilities. For APIs, deploy Amazon API Gateway with authentication and authorization controls to manage access to your backend services. This layered approach to security helps protect your infrastructure at multiple points in the traffic flow.

            Regular security assessments

            Run Amazon Inspector to scan for misconfigurations in your infrastructure, and use AWS Security Hub to centralize security findings across your AWS environment. Conduct penetration tests in accordance with AWS policy to identify potential security issues before they can result in unintended access.

            Incident response planning

            Automate remediation with AWS Config rules and Automation, a capability of AWS Systems Manager, to respond rapidly to security events. Maintain incident response runbooks that outline clear steps for addressing proxy-related security incidents, and decommission unused resources that could become security liabilities.

            Documented procedures and automated responses reduce the time between detection and remediation and minimizes the potential effects of security incidents on your operations.

            Benefits of proper proxy security

            When you implement these security measures, you gain the following advantages for your AWS environment:

            • Protection of your IP address reputation helps maintain customer trust and prevents security services from blocking your legitimate traffic. When your infrastructure maintains a positive reputation, your business communications reach their intended recipients without interference.
            • Cost control prevents unauthorized users from consuming your AWS resources and generating unexpected charges on your account. When you restrict access to legitimate users and use cases, you maintain predictable costs that align with your business needs.
            • Operational stability reduces the risk of service disruptions that abuse of your proxy infrastructure can cause. When you dedicate your resources to serving your customers rather than supporting unauthorized activity, you can deliver consistent performance and availability.
            • Enhanced visibility into your network traffic patterns helps you identify both legitimate usage and potential security concerns. This awareness allows you to make informed decisions about capacity planning, security improvements, and operational optimizations.

            Conclusion

            Open proxies present a serious risk in AWS environments, but you can effectively secure proxies with the right measures. By implementing strict access controls and additional security practices such as authentication, monitoring, and regular assessments, you can prevent misuse, protect your infrastructure, and maintain your IP address reputation.

            Taking proactive steps strengthens your own environment and supports the broader security of the internet ecosystem. Under the AWS shared responsibility model, you’re responsible for the configuration and maintenance of these security controls, while AWS provides the underlying secure infrastructure. By following the guidance in this article, you can build a robust security posture that protects your proxy infrastructure while supporting your legitimate business needs.

            If you have feedback about this post, submit comments in the Comments section below.

            Dodd Mitchell

            Dodd Mitchell

            Dodd is a member of the AWS Trust and Safety team in Virginia, supporting customers in navigating abuse, phishing, and content-related risks. He works closely with partners to strengthen response processes and build more resilient, trustworthy platforms.

            Announcing the ISO 31000:2018 Risk Management on AWS Compliance Guide

            1 May 2026 at 22:01

            AWS Security Assurance Services is announcing the release of our latest compliance guide, ISO 31000:2018 Risk Management on AWS, which provides practical guidance for organizations establishing and operating a risk management program in AWS environments using ISO 31000:2018 principles.

            The guide explains how organizations can integrate AWS services into their risk management processes to support the core components of ISO 31000:2018, including establishing context and criteria, conducting risk assessments, implementing risk treatments, and enabling continuous monitoring and review. It also highlights how AWS security, automation, and monitoring capabilities can help customers identify areas for improvement and help enforce controls at large. The guide includes:

            • An overview of the ISO 31000:2018 risk management framework, including context and criteria, risk assessment, risk treatment, and monitoring and review. You will learn how to apply ISO 31000’s core principles within AWS environments and use AWS services for risk identification, detection, treatment, and monitoring.
            • Governance and risk treatment considerations aligned with the AWS Shared Responsibility Model. This includes strategies for risk avoidance, mitigation, transfer, and acceptance.

            By combining ISO 31000 risk management principles with AWS security services, organizations can build scalable, automated environments that help support continuous risk identification, proactive treatment, operational visibility, and ongoing compliance readiness.

            Download Available: ISO 31000:2018 Risk Management on AWS Compliance Guide

            For further assistance, contact AWS Security Assurance Services

            If you have feedback about this post, submit comments in the Comments section below.

            Jesse McMahan

            Jesse McMahan

            Jesse is a Sr. Security Assurance Consultant at AWS with over a decade of experience in information security, risk management, and compliance. He holds multiple industry and AWS certifications and leads security assessment and advisory engagements covering standards such as PCI DSS, NIST, SOC 2, HIPAA, and ISO 27001. A United States Marine Corps veteran, Jesse brings a disciplined, mission-focused approach to helping organizations align their security posture with regulatory and business objectives.

            Juan Rodriguez

            Juan Rodriguez

            Juan is a Security Assurance Consultant at AWS, where he works with Strategic Services and customers to assess and secure cloud environments against frameworks including CMMC, FedRAMP, GovRAMP, and NIST based practices. He holds his CMMC Certified Professional and AWS Certified Security – Specialty certifications. Juan pairs technical expertise with a research-driven mindset to help organizations strengthen and architect their security posture and align with federal and industry standards.

            Akanksha Chaturvedi

            Akanksha Chaturvedi

            Akanksha is a Senior Security Assurance Consultant with over 10 years of specialized experience in risk-based security assessments and regulatory compliance across highly regulated industries. Expert practitioner in HIPAA, PCI-DSS, GDPR, FedRAMP, and IRAP frameworks, with demonstrated success in architecting and deploying enterprise security programs from conception through full implementation. Known for delivering innovative, scalable solutions that strengthen security posture while streamlining operational processes aimed at reducing compliance overhead.

            Sana Rahman

            Sana Rahman

            Sana is a Senior Assurance Consultant with AWS Security Assurance Services, and has been a PCI DSS Qualified Security Assessor (QSA) for over a decade. She has extensive knowledge and experience in information security and governance, and deep compliance knowledge in both cloud and hybrid environments. She uses all of this to remove compliance roadblocks for AWS customers and provide guidance in their cloud journey.

            Mayur Jadhav

            Mayur Jadhav

            Mayur is a Senior Assurance Consultant at AWS with over a decade of experience in cloud security, governance, risk management, and compliance. He holds AWS Certified Solutions Architect and Zero Trust Certified Architect (ZTCA) certifications. His career spans leadership roles across organizations including Amazon, AWS, EY-Parthenon, and PwC, where he has advised senior executives on cybersecurity and compliance initiatives across healthcare, financial services, and technology sectors.

            Designing trust and safety into Amazon Bedrock powered applications

            29 April 2026 at 21:27

            Generative AI brings promising innovation, transforming how individuals and organizations approach everything from customer service to content creation and more. As AI continues to expand its capabilities, organizations are increasingly focused on how they can integrate the responsible AI concepts into the development lifecycle of their AI applications.

            Research from Accenture and Amazon Web Services (AWS) reveals compelling evidence for the business value of responsible AI practices, both internally within their organizations and externally to their users. Organizations that communicate a mature approach to responsible AI see an 82% improvement in employee trust in AI adoption, which directly leads to increased innovation. Additionally, companies that offer responsible AI-enabled products and services experience a 25% increase in customer loyalty and satisfaction.

            Understanding the core dimensions of responsible AI

            AWS identifies these key dimensions that form the backbone of responsible AI implementation:

            • Safety focuses on preventing harmful system output and misuse. This dimension focuses on steering AI systems to prioritize user and system safety.
            • Controllability focuses on mechanisms that monitor and steer AI system behavior. This dimension refers to the ability to manage, guide, and constrain AI systems to operate within specific parameters.
            • Fairness considers the impacts of AI on different groups of users.
            • Explainability focuses on understanding and evaluating system outputs.
            • Security and privacy focuses on making sure that data and models are appropriately obtained, used, and protected.
            • Veracity and robustness focuses on achieving correct system outputs, even with unexpected or adversarial inputs.
            • Governance makes sure that development, deployment, and management of AI systems align with ethical standards, legal requirements, and societal values.
            • Transparency focuses on understanding how AI systems make decisions, why the systems produce specific results, and what data the systems use.

            It’s a best practice to review and apply all these dimensions to your AI implementation. For more information, see Considerations for addressing the core dimensions of responsible AI for Amazon Bedrock applications.

            The responsible AI lifecycle

            When you implement AI systems, you should build safety into every phase of the AWS responsible AI lifecycle. The responsible AI lifecycle consists of the following three phases, each with distinct responsibility considerations for the safety dimension:

            1. In the design and development phases, thoroughly evaluate potential safety risks. Understand what you want your AI application to do, what you don’t want it to do, and what you want to prevent it from doing. You should build safety guardrails into your systems from the beginning and make sure that your development teams understand the capabilities and limits of your AI application.
            2. In the deployment phase, theory meets reality. During this phase, you should implement robust safety measures through multiple layers, from comprehensive user training to proactive monitoring and review processes. Every application, product, and feature must include clear safety protocols and user guidelines. You must think beyond the launch of an application and consider how to launch a holistic safety framework. This framework—which can contain steps such as red team testing—must protect your brand, users, and stakeholders.
            3. In the operations phase, it’s important to maintain vigilance. Safety, like security, isn’t something you set up once and then ignore. Safety requires continuous monitoring and adaptation. To catch potential safety issues early, you can implement real-time feedback mechanisms to conduct regular performance evaluations. You can also continuously monitor for shifts in how your application is used, or functions that could compromise safety. Because safety considerations and risks evolve as technology evolves, it’s crucial to understand that adjustments are necessary over time.

            For more information, see the Responsible use of AI guide.

            Abuse detection

            Foundation models in Amazon Bedrock are inherently designed with safety mechanisms to prevent harmful outputs. However, you can implement additional input safety systems in production environments to provide critical early detection capabilities to identify problematic content, users, or patterns.

            Note: Amazon Bedrock might implement automated abuse detection mechanisms to identify potential violations of the AWS Acceptable Use Policy (AUP) and Service Terms, including the Responsible AI Policy or a third-party model provider’s AUP.

            See the Amazon Bedrock abuse detection document for more information.

            AI abuse prevention tools and techniques

            To maintain trust in your AI services, preventative action is key, while also efficiently planning and managing development resources. Introduce observability and safety guardrails early in development to support long-term scalability and help identify potential issues before they affect your users. To begin this process, thoroughly scope your AI use case with the following actions:

            • Understand your users
            • Anticipate potential misuse scenarios
            • Define your risk tolerance

            This scope guides your development of a precise safety framework that addresses the specific risks of your AI implementation while you maintain expected performance. For this scope, you can use AWS specialized tools designed specifically to monitor and protect Amazon Bedrock applications.

            Using CloudWatch to monitor Amazon Bedrock

            Amazon CloudWatch provides essential visibility into AI system behavior and performance. When you configure comprehensive logging, you can capture important information across user segments and interaction types, such as the following:

            • Request volumes
            • Response latencies
            • Rejection rates
            • Content filtering triggers

            You can use this information to identify potential abuse patterns or unexpected behaviors before they affect operations. CloudWatch dashboards visualize metrics according to monitoring priorities, and automated alerts provide prompt notification when you exceed thresholds. This infrastructure transforms interaction data into actionable insights and supports continuous safety improvement.

            Note: By default, Amazon Bedrock logging is turned off. You must turn on logging for your application. To configure this, contact your account manager.

            Using Amazon Bedrock Guardrails to customize safeguards

            Amazon Bedrock Guardrails offers configurable protection mechanisms tailored to specific risk profiles and content policies. You can customize Bedrock Guardrails to match your application requirements, such as:

            • Define domain-relevant undesirable topics
            • Configure appropriate content filtering thresholds
            • Configure sensitive information detection and redaction parameters aligned with data policies

            Additionally, you can configure controls that prioritize accuracy and prevent hallucinations while maintaining creative flexibility based on your application needs. When you thoughtfully configure Guardrails, you can balance performance and safety according to your specific use case requirements and risk factors.

            The abuse response process

            As AI safety evolves and new risks emerge, abuse might still occur even if you implement safety mechanisms. If you receive an abuse report from the AWS Trust & Safety team, then complete the following steps to help effectively address the issue:

            1. Acknowledge receipt: Acknowledge the receipt of the abuse report within 24 hours. If your team is still conducting their investigation, then inform AWS that the investigation is ongoing. Provide the number of days expected to complete the investigation.
            2. Investigate the issue: Thoroughly investigate the issue, including examining the logs (if enabled), reviewing Amazon Bedrock inputs, and checking for unauthorized access. While AWS abuse reports include a small sample of prompt IDs for you to investigate, investigate usage of your Amazon Bedrock application. Check for patterns to see if there’s a systemic issue that’s leading to abuse.
            3. Take appropriate action: If appropriate, take action to implement fixes, update safeguards, address violating users, or redesign features. Consider if you need systemic or root-cause fixes, rather than addressing one abusive end user. An abuse incident by one user could indicate vulnerabilities in your safety mechanisms that can lead to continuous abuse.
            4. Report back to AWS Trust & Safety: Following your investigation and implementation of fixes, provide an update to AWS Trust & Safety on your findings and remediation steps. Be transparent about what happened and how you addressed the issue. If you think that no violation occurred, then provide context on how you came to this conclusion. Include examples of the prompts and your business use case where possible.

            Conclusion

            To learn more about safety and responsible AI development, explore AWS resources, including the Responsible AI portal and machine learning best practices documentation. These resources provide additional tools and frameworks to build safe, effective AI systems that drive innovation and maintain safety standards.

            Victor Lungu Victor Lungu
            Victor is a Trust & Safety AI Abuse Specialist at AWS, based in Dublin. Victor works across a broad range of AI safety domains including content safety and emerging AI risks

            What the March 2026 Threat Technique Catalog update means for your AWS environment

            28 April 2026 at 21:01

            The AWS Customer Incident Response Team (AWS CIRT) regularly encounters patterns that repeat across their engagements when helping customers respond to security incidents. We’re passionate about making sure that information is widely accessible so that everyone can improve their security posture and their organization’s resilience to disruption. The primary method we use to share this information is the Threat Technique Catalog for AWS (TTC). The latest update to the catalog for March 2026 addresses identity, persistence, infrastructure destruction, and privilege escalation. Each new entry reflects something we’ve encountered in practice, and each provides straightforward mitigations. This post breaks down what changed, why it matters, and what you can do about it today.

            What we’re seeing

            Based on recent observations, we’ve added three new entries to the TTC.

            Cognito refresh token abuse: The quiet persistence mechanism

            Amazon Cognito refresh tokens are designed for convenience. They let applications obtain new access and ID tokens without requiring users to re-authenticate. The default lifetime is 30 days and is configurable up to 10 years. Cognito provides the flexibility to address a wide range of use cases, however the AWS CIRT has seen this lifetime window used by threat actors in an unauthorized way to maintain persistence by refreshing credentials.

            When a threat actor obtains a valid refresh token—through credential theft, compromised client-side storage, or elevated permissions—they can call cognito-idp:GetTokensFromRefreshToken to silently generate fresh tokens. The legitimate user’s session continues normally because their application independently refreshes tokens as needed—the threat actor’s refresh calls don’t invalidate the user’s token. This creates a parallel, persistent foothold that’s invisible to the user. In environments where refresh token rotation isn’t enabled, the same token can be reused indefinitely within its validity window.

            This method of gaining persistent access is often overlooked by response teams who were confident that the initial compromise was contained, only to discover ongoing unauthorized access weeks later through a refresh token they didn’t know existed.

            Enabling refresh token rotation and reducing the lifetime of tokens can help mitigate this risk. Dive deeper in the TTC (T1098.A006).

            AMI image deletion: Targeting recovery capabilities

            Amazon Machine Images (AMI) are a core part of many solutions and foundational to disaster recovery. They often contain the operating system, application configurations, and everything needed to rebuild your infrastructure. Threat actors know this, and we’re seeing ec2:DeregisterImage used to make it more difficult to recover from an incident.

            By default, when an AMI is deregistered, it’s gone. Recycle Bin retention rules can allow the recovery of the AMI, but if you haven’t explicitly enabled that functionality, there’s no way to undo the deregister action. Working with customers, we’ve seen cases where the impact of this action goes beyond the immediate loss because the threat actors have also removed the golden images the teams planned to restore from.

            The TTC has more information about how to detect and mitigate this technique, including how to enable Recycle Bin retention rules for key AMIs (T1485.A002).

            Additional cloud roles: The trust policy blind spot

            We’ve updated T1098.003: Additional Cloud Roles to now include UpdateAssumeRolePolicy as a tracked API call. We’ve seen an increase in the use of this call to avoid detections set to flag new role creation (iam:CreateRole). By modifying the trust policy of an existing role, a threat actor with sufficient permissions can use UpdateAssumeRolePolicy to subtly add an external account or an identity they control. No new roles appear. No new policies are created. The existing role simply trusts a new principal which the threat actor can assume.

            This persistence and privilege escalation technique blends into the volume of normal AWS Identity and Access Management (IAM) operations. It’s especially effective in environments with a large number of roles where trust policy changes aren’t actively monitored.

            The current trend

            A common thread runs through all three of these updates: threat actors are using subtle, default, or unexpected behaviors to sidestep detection. Refresh tokens working as designed. AMI deregistration completing without guardrails. Trust policies being modified through legitimate API calls. These actions might not trigger alarms in most environments because they look like normal operations.

            This is a shift worth paying attention to. Rather than relying on novel exploits or zero-days, the techniques we’re cataloging reflect threat actors who understand how cloud services work and use that knowledge to hide in plain sight. The implication for security teams is clear: prevention and detection strategies need to mature beyond monitoring for obviously malicious actions. Customers need to be watching for legitimate actions happening in illegitimate context—such as the right API call, made by the wrong principal, at the wrong time.

            The Threat Technique Catalogue for AWS is designed to help with exactly this. Each technique entry includes detection guidance and mitigations specific to AWS environments. We encourage teams to review the relevant entries and assess whether their current monitoring would catch these patterns:

            • T1098.A006: Cognito Refresh Token Abuse: Are you monitoring for cognito-idp:GetTokensFromRefreshToken from unexpected sources? Is refresh token rotation enabled?
            • T1485.A002: AMI Image Deletion: Do you have Recycle Bin retention rules protecting your critical AMIs? Would you know if a production AMI was deregistered outside a maintenance window?
            • T1098.003: Additional Cloud Roles: Are trust policy modifications tracked and alerted on? Could an external account be added to an existing role without anyone noticing?

            Each of these techniques leaves traces in AWS CloudTrail, and the TTC provides specific guidance on what to watch for and how to respond.

            Looking ahead

            The Threat Technique Catalog for AWS exists because we believe the patterns we observe during security engagements shouldn’t stay behind closed doors. When we see techniques repeating across customers, the most effective thing we can do is document them and make that knowledge available so you can act on it before you’re in the middle of an incident.

            This March update adds three new entries, and the catalog will continue to evolve. Our team regularly updates it based on what we’re seeing in the real world when helping customers respond to security events. We encourage security teams to review the catalog regularly, incorporate its techniques into threat modeling exercises, and use it as a shared vocabulary for discussing cloud-specific threats.

            Explore the full catalog: Threat Technique Catalog for AWS

            Additional resources

            If you have feedback about this post, submit comments in the Comments section below.


            Shannon Brazil

            Shannon Brazil

            Shannon is a security engineer on the AWS Customer Incident Response Team (CIRT), specializing in digital forensics and cloud security investigations. Known in the community as 4n6lady, she is passionate about security education and mentoring the next generation of defenders.

            Cydney Stude

            Cydney Stude

            Cydney is a security engineer specializing in threat intelligence and incident response at AWS. Cydney works on the ground in incident response and is passionate about turning observables into security outcomes. Cydney is an author and maintainer of the Threat Technique Catalog for AWS.

            Access control with IAM Identity Center session tags

            28 April 2026 at 18:33

            As organizations expand their Amazon Web Services (AWS) footprint, managing secure, scalable, and cost-efficient access across multiple accounts becomes increasingly important. AWS IAM Identity Center offers a centralized, unified solution for managing workforce access to AWS accounts. It simplifies authentication, enhances security, and provides a seamless user sign-in experience to AWS services across diverse environments.

            By combining IAM Identity Center permission sets with session tags, organizations can unlock powerful capabilities for fine-grained access control and resource optimization. You can use session tags to pass dynamic attributes from your external identity provider into AWS, enabling more context-aware permissions and better cost visibility. This integration makes it possible to use advanced AWS features such as AWS Glue usage profiles and AWS Systems Manager Session Manager run as to enforce fine-grained access control, so that administrators can dynamically map permissions and runtime configurations based on user attributes passed during federated access.

            In this post, I demonstrate how session tags derived from directory group attributes in Microsoft Entra ID can deliver functionality equivalent to AWS Identity and Access Management (IAM) role tags. Using role tags, you can implement attribute-based access control (ABAC) using IAM Identity Center, while maintaining centralized and efficient access management. To demonstrate this, you can configure an AWS Glue usage profile, as described in Introducing AWS Glue usage profiles for flexible cost control, where session tags can be passed through Identity Center and an external identity provider like Microsoft Entra ID. This approach is extensible to other AWS services such as AWS Systems Manager Session Manager (run as) and can also be used with other identity providers.

            User authentication and IAM Identity Center Federation flow

            The following figure shows the architecture and workflow of the solution.

            Figure 1 – User authentication and federation flow between Microsoft Entra and AWS

            Figure 1 – User authentication and federation flow between Microsoft Entra and AWS

            The user authentication and federation flow includes the following steps:

            1. User accesses application using a browser.
            2. The enterprise application (configured in Azure) initiates authentication.
            3. Microsoft Entra ID handles sign-in.
            4. Users and groups are managed in Entra ID.
            5. A SAML trust is established between Entra ID and IAM Identity Center.
            6. SCIM provisioning syncs users and groups from Entra ID to AWS.
            7. Synced users and groups appear in Identity Center.
            8. Session tags are passed during SAML authentication.
              • Entra ID can send user attributes (department, role, cost center, project ID, and so on) as SAML attributes.
              • Identity Center consumes these as session tags, which are used for fine-grained access control and attribute-based access control inside AWS.
            9. Admins define permission sets for users and groups in Identity Center.
            10. Users get federated access to AWS using their Entra ID credentials.
            11. Users sign in through AWS Management Console or AWS Command Line Interface (AWS CLI) using those permissions.
            12. Access is granted to specific AWS accounts under AWS Organizations.

            Prerequisites

            To follow the steps in this post, you need the following prerequisites:

            1. An organization instance of IAM Identity Center enabled.
            2. A Microsoft Entra ID tenant. For more information, see Quickstart: Create a new tenant in Microsoft Entra ID.
            3. Access to an external identity provider such as Microsoft Entra ID to federate users into AWS. You can enable federated access between Microsoft Entra ID and IAM Identity Center by completing the steps in Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center. They include configuring SAML and SCIM integration between the two systems, testing the SAML connection to help ensure authentication is functioning correctly, and enabling SCIM synchronization to automate user and group provisioning.

            Solution implementation

            With the prerequisites in place, you’re ready to configure access control through IAM Identity center tags by using the following steps.

            1. Create an AWS Glue usage profile as described in Introducing AWS Glue usage profiles for flexible cost control in Create an AWS Glue usage profile. For the purposes of this post, create a profile named developer.
              1. On the AWS Management Console for AWS Glue, choose Cost management in the navigation pane.
              2. Choose Create usage profile.
              3. For Usage profile name, enter developer.
              4. Under Customize configurations for jobs, for Number of workers, for Default, enter 20.
              5. For Default worker type, select G.1X.
              6. For Allowed worker types, select G.1XG.2XG.4X, and G.8X.
              7. For Customize configurations for sessions, configure the same values.
              8. Choose Create usage profile.

              Figure 2 – Glue usage profile creation on the console

              Figure 2 – Glue usage profile creation on the console

            2. Create a custom permission set instead of using predefined ones. Attach the following AWS Managed Policies to the custom permission set:
              • AWSGlueConsoleFullAccess
              • IAMReadOnlyAccess

              Note: For fine-grained access control, you can create custom permission sets by combining AWS managed, customer managed, and inline policies in IAM. In this post, you use AWS managed policies with intentionally broad permissions for simplicity. In production, always follow the principles of least privilege and scope permissions appropriately.

              By default, when you create a permission set, the permission set isn’t provisioned (used in any AWS accounts). To provision a permission set in an AWS account, you must assign IAM Identity Center access to users or groups in the account and then apply the permission set to those users and groups. For more information, see Assign user or group access to AWS accounts.

            3. Configure user attributes in Microsoft Entra ID for access control in IAM Identity Center as described in Step 5 of Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center to set up ABAC. Add claim conditions for attribute mapping based on Entra ID group membership. Assign the developer value for users in a corresponding group. This enables logic such as Users in this group receive this profile or All users receive this profile. When using an AWS Glue profile and when making API calls to create AWS Glue resources, admins need to tag the user or role with glue:UsageProfile as the key and the profile name as the value.
            4. Next, sign in to the enterprise application that you created in the previous step, which has SCIM and SAML connections set up to IAM Identity Center:
              1. Sign in to Azure.
              2. Choose Enterprise applications.
              3. Select the application that you created
                Figure 3 – An enterprise application created in Microsoft Entra ID

                Figure 3 – An enterprise application created in Microsoft Entra ID

            5. When you’re signed in to your application, select Manage and then Single sign-on in the navigation pane, then select Attributes & Claims.
              Figure 4 – Attributes & Claims section in Microsoft Entra ID

              Figure 4 – Attributes & Claims section in Microsoft Entra ID

            6. Configure the key value pair that will used as session tags by selecting Add new claim.
              Figure 5 – Configuring attributes by adding a new claim

              Figure 5 – Configuring attributes by adding a new claim

            7. For Name, enter AccessControl:<AttributeName>. Replace <AttributeName> with the name of the attribute you are expecting in IAM Identity Center. For this example, use AccessControl:glue:UsageProfile.
            8. In Claim conditions set the following:
              • User type, select Members
              • Source, select Attribute.
              • Value, enter developer (without quotation marks).

              Figure 6 – Attribute claim addition in Microsoft Entra using group membership

              Figure 6 – Attribute claim addition in Microsoft Entra using group membership

            It’s important to note that the tags are being assigned based on group membership in Microsoft Entra ID. This approach lets you manage access and configuration dynamically without needing to set tags individually for each user. By assigning the tag to a Microsoft Entra ID group, anyone signing in to IAM Identity Center and who is in that group will automatically have the tag value applied to their session.

            Test the solution

            Now that the required configuration is complete, test the setup using the developer usage profile created as part of the Solution implementation section. Sign in as your user through Microsoft Entra ID using https://myapps.microsoft.com/ and verify the job creation using the following steps mentioned.

            To verify successful job creation:

            1. Open the AWS Glue console using the developer usage profile.
            2. In the navigation pane, choose ETL jobs.
            3. Select Script editor, then choose Create script.
            4. Create a new job using the values you want to validate.

            The green banner at the top of the screen should say Successfully updated job.

            Figure 7 – Successful AWS Glue job creation with configured parameters for the <em>developer</em> usage profile

            Figure 7 – Successful AWS Glue job creation with configured parameters for the developer usage profile

            Validation using AWS CloudTrail

            Examine the AssumeRoleWithSAML event using AWS Cloudtrail. Use the following steps to verify the sequence of events.

            1. Navigate to the CloudTrail console.
            2. Select Event history.
            3. In the Lookup attributes dropdown, select Event name.
            4. Set the event name to AssumeRoleWithSAML.
            5. Open a relevant event and inspect the requestParameters section.
            6. Confirm that the expected session tags appear under PrincipalTags.
            Figure 8 – ABAC tags passed during the role assumption

            Figure 8 – ABAC tags passed during the role assumption

            Using session tags for other use cases

            The concepts discussed in this post can be extended to configure AWS Systems Manager Session Manager Run As support for federated users using session tags. By default, Session Manager launches sessions using a system-generated ssm-user account. For Linux instances, you can optionally configure sessions to run as a specific OS-level user through Session Manager preferences. You can configure your identity provider to pass the user attribute (AccessControl: SSMSessionRunAs and name of an OS user account for the key value during federation and the session will be tagged using the attribute value.

            Clean up

            To avoid incurring future charges, delete any resources created during this walkthrough if they’re no longer needed:

            1. Remove the IAM Identity Center instance and clean up the associated enterprise application in Microsoft Entra.
            2. Delete the AWS Glue usage profile.
            3. Remove any other AWS resources you provisioned for testing the solution.

            Conclusion

            In this post, you learned how to federate access to AWS using AWS IAM Identity Center and SAML 2.0 identity providers like Microsoft Entra ID, enabling a secure, scalable, and centralized approach to managing user access across multiple AWS accounts. By using permission sets, reserved IAM roles, and session tags, organizations can implement fine-grained ABAC without the complexity of managing individual IAM users or static roles.

            As cloud environments become more complex, adopting modern identity federation and ABAC through IAM Identity Center helps security teams maintain control while providing users with seamless, context-aware access to the resources they need.

            Resources

            If you have feedback about this post, submit comments in the Comments section below.

            Rashmi Iyer

            Rashmi Iyer

            Rashmi is a Senior Solutions Architect at AWS, supporting financial services enterprises in building secure, resilient, and scalable cloud architectures while ensuring compliance with industry best practices. With over 15 years of experience in the private telco cloud, she has designed and architected complex telecom solutions, specializing in the packet core domain, the backbone of mobile data networks.

            Optimize security operations through an AWS Security Hub POC

            27 April 2026 at 20:55

            April 27, 2026: This post was first published in September 2025 when the enhanced AWS Security Hub was in public preview. It has since been updated to reflect the general availability of Security Hub. This revision also provides a more detailed, step-by-step framework for planning your POC.


            AWS Security Hub prioritizes your critical security issues and helps you respond at scale to protect your environment. The service sharpens findings through aggregation, correlation, and enrichment of AWS native security signals into actionable insights, enabling faster and more efficient response times. You can use these capabilities to gain visibility across your cloud environment through centralized management in a unified cloud security solution. Security Hub creates a cloud-native application protection platform (CNAPP) and through the AWS free trial, you can create a comprehensive proof of concept (POC) evaluation without significant upfront investment in time or resources.

            In this blog post, we guide you through planning and implementation POC for Security Hub to assess the implementation, functionality, cost estimate, and value of Security Hub in your environment. We walk you through the following steps:

            1. Understand the value of Security Hub
            2. Determine success criteria for the POC
            3. Define Security Hub configuration
            4. Prepare for deployment
            5. Enable Security Hub
            6. Validate deployment

            Understand the value of Security Hub

            Figure1: AWS Security Hub overview

            Figure 1: AWS Security Hub overview

            Figure 1 provides a visualization of how Security Hub unifies signals from multiple AWS security services, partner solutions capabilities. The signals, which are ingested by Security Hub from multiple AWS security services and curated partner solutions include:

            At its core, Security Hub provides four key capabilities in one unified solution:

            1. Unified security operations: Security Hub delivers a unified security operations experience, bringing your security signals into a single consolidated view and avoiding the need to switch between multiple security tools. This provides comprehensive visibility across your entire estate, including AWS, multi-cloud, and on-premises, so your security teams can efficiently detect, prioritize, and respond to potential security risks.
            2. Intelligent prioritization helps focus on what matters most: Security Hub helps you identify and prioritize critical security risks that might be missed when viewing findings in isolation. Security findings are correlated by analyzing resource relationships and signals from AWS security services and capabilities.
            3. Actionable insights guide security teams on next steps: Gain actionable insights through advanced analytics to transform correlated findings into clear, prioritized insights that highlight the most critical security risks in your environment. You can quickly understand potential impacts, visualize relationships, and identify which security issues pose the greatest risk to critical resources.
            4. Streamlined security response and automation capabilities: Security Hub enhances your security operations by enabling streamlined response capabilities. It seamlessly integrates with your existing ticketing systems to help facilitate efficient incident management.

            With this integrated approach your security team can:

            • Investigate critical risks that need immediate attention from a single pane of glass
            • Monitor security trends and attack surface across your environments
            • Fix what really matters across the entire attack chain and path
            • Automate responses to streamline remediation

            Understand the Open Cybersecurity Schema Framework

            Security Hub uses the Open Cybersecurity Schema Framework (OCSF) to help standardize security data and analysis and enable better integration between security tools. This standardization helps simplify how security findings are structured and analyzed across your environment. This standardized data model enables seamless integration and data exchange across your security tooling, providing normalized and consistent data formats. When implementing your Security Hub POC, make sure that you’re familiar with the OCSF specifications Security Hub uses.

            Additionally, confirm that any analytics or security information and event management (SIEM) tools you plan to integrate with support the OCSF data format to maximize the value of the consolidated security insights provided by Security Hub.

            Determine success criteria

            Establishing success criteria helps benchmark the outcomes of the POC with the goals of the business. Some example criteria and key performance indicators (KPI) include:

            • Alert consolidation metrics: Determine what resources you’re currently using to correlate security events and signals to understand their relationship. Review the process and note if it’s completed outside of AWS or through a SIEM. By setting a benchmark to reduce correlation overhead you can significantly improve efficiency and accelerate security investigations and posture improvement.
            • Response time improvements: Reducing your time to detect, investigate, and resolve security events and improve security posture is essential to streamlined security operations. Security Hub provides visualizations for potential attack paths that adversaries could use to exploit resources and helps assess the potential blast radius.
              • Reduced mean time to detect (MTTD) security incidents.
              • Reduced mean time to response (MTTR) for critical findings.
              • Reduced time to identify potentially affected resources in blast radius.
              • Increased accuracy of attack path analysis.
              • Number of controls implemented based on attack path insights (post investigation).
            • Automation capabilities: Having response playbooks as part of your incident management and response plan helps ensure comprehensive investigations lead to improved security posture. Review your automation capabilities to see if portions of or entire playbooks can be automated.
              • Potentially increased percentage of security findings automatically routed to the correct teams by using Jira Cloud, ServiceNow, or a third-party tool.
              • Reduced average time from detection to ticket creation.
            • Severity and risk classification: Review your organization’s inventory of assets to determine if it’s complete and if you can use telemetry to determine the severity level and associated risks.
              • Reduced time to identify critical resources and service coverage gaps affected by new vulnerabilities, threats, and misconfigurations.
              • Faster and more accurate severity label and risk calculation of findings.
              • Reduced time to identify service gap coverage.

            After establishing your success criteria, it’s essential to evaluate organizational readiness and potential constraints that might impact your POC implementation. Begin by conducting a comprehensive assessment of your current environment: Determine if the foundational security services (GuardDuty, Amazon Inspector, Security Hub CSPM, and Macie) are enabled across your accounts, and identify your critical workloads and if there are any excessive attack surfaces.

            Review your success criteria to make sure that your goals are realistic given your timeframe and potential constraints that are specific to your organization. For example:

            • Do you have full control over the configuration of AWS services that are deployed in an organization?
            • Do you have resources that can dedicate time to implement and test?
            • Is this time convenient for relevant stakeholders to evaluate the service?

            Maximize your POC value through service activation

            To get the most comprehensive evaluation of the capabilities of Security Hub, coordinate the activation of underlying security services to optimize the overlapping trial periods available at no additional cost. The following is a list of the underlying security services, and their free trial length:

            • Security Hub: 30-day trial (essential plan capabilities)
            • GuardDuty: 30-day trial (covers most protection plans except GuardDuty Malware Protection)
            • Security Hub CSPM: 30-day trial
            • Macie: 30-day trial
            • Amazon Inspector: 15-day trial

            Consider enabling these services simultaneously so that you have at least two weeks of overlapping coverage to evaluate the full correlation and risk prioritization capabilities of Security Hub across each service. Optionally, if you want to conduct a POC with minimal configuration because of limitations, you can enable only Security Hub CSPM and Amazon Inspector during the initial POC phase to properly assess the results and data.

            Note: Document your activation dates and trial expiration dates carefully. Create calendar reminders for trial end dates and schedule your key POC evaluation milestones to occur while services are active. This will help make sure that you can thoroughly assess the unified security operations capabilities of Security Hub when services are running at full capacity.

            If you already have one or more of these underlying services enabled, you can proceed to enable the new Security Hub. To fully use the new Security Hub capabilities, particularly the exposure findings feature, specific service dependencies must be met, both Security Hub CSPM and Amazon Inspector are essential because they provide the telemetry needed for the Security Hub correlation engine and exposure findings. The combination enables Security Hub to deliver comprehensive risk analysis and prioritization by correlating configuration risks with runtime vulnerabilities. If you have other security services already enabled (such as GuardDuty or Macie), you can maintain these existing services while enabling Security Hub, and it will automatically begin incorporating their findings into its consolidated view, enhancing your overall security posture visualization.

            Define your Security Hub configuration

            After your success criteria have been established, you’re ready to plan your configuration. Some important decisions include:

            • Select a delegated administrator: From the AWS Organizations management account, you can set a delegated administrator for your organization. As a best practice, we recommend using the same delegated administrator across security services for consistent governance and according to our AWS Security Reference Architecture (AWS SRA).
            • Select accounts in scope: Define accounts you want to have Security Hub enabled for.
            • Define AWS Regions: Determine Regional restrictions or considerations.
            • Determine AWS service integrations: In addition to the core security capabilities of posture management and vulnerability management, Security Hub integrates signals from other AWS security services such as GuardDuty and Macie.
            • Define third-party integrations:
              • For ticketing, Security Hub integrates with popular service management systems such as Atlassian’s Jira Service Management Cloud and ServiceNow.
              • Partners who already support or intend to support the OCSF schema to receive findings from Security Hub include companies such as Arctic Wolf, CrowdStrike, DataBee, Datadog, DTEX Systems, Dynatrace, Fortinet, IBM, Netskope, Orca Security, Palo Alto Neworks, Rapid7, Securonix, SentinelOne, Sophos, Splunk, Sumo Logic, Tines, Trellix, Wiz, and Zscaler.
              • Service partners such as Accenture, Caylent, Deloitte, IBM, and Optiv can help you adopt Security Hub and the OCSF schema.
            • Use the Security Hub cost estimator: Use the Security Hub Cost Estimation Tool for a pre-enablement cost estimate based on your current spend on Amazon Inspector, Security Hub CSPM, and GuardDuty.

            Prepare for deployment

            After determining your success criteria and Security Hub configuration, identify stakeholders, desired state, and timeframe. Prepare for deployment by completing:

            • Project plan and timeline: Develop a project plan with defined success criteria, scope boundaries, key milestones, and realistic implementation timelines. Suggested timeline of events:
              • Before enablement:
                • Validate core security service configuration for GuardDuty, Amazon Inspector, Security Hub CSPM, and Macie
                • Request approvals for free trial from appropriate stakeholders
              • Day 0 – Enable the service, become comfortable with the Security Hub layout and begin training security personnel
              • Week 1 – Validate desired coverage of threat detection, vulnerability management, and posture management across accounts and Regions
              • Week 2 – Connect to IT service management (ITSM) tools and begin creating automations for critical workloads and resources
              • Week 3 – Execute a tabletop exercise in response to a selected exposure finding
              • Week 4 – Analyze trends of threats and exposures from day 1 through week 4
            • Identify stakeholders: Identify CISO, information security teams, SOC personnel, incident response teams, security engineers, finance, legal, compliance, external MSSPs, and business unit representatives.
            • Develop a RACI matric: Create a detailed RACI chart defining roles and responsibilities across the incident response lifecycle, facilitating accountability and proper communication channels.
            • Configure management account access: Secure authorization to delegate administrative access. For more information, see Permissions required to designate a delegated Security Hub administrator account.
            • Set up IAM roles and permissions: Use AWS Identity and Access Management (IAM) roles to implement role-based access controls aligned with the RACI chart, including case management, escalation, and read-only roles using AWS managed policies. For more information, see AWS Managed Policies

            Enable Security Hub

            AWS security services integrate with AWS Organizations to help you centrally manage Security Hub.

            1. If you haven’t already done so, enable Security Hub CSPM and Amazon Inspector at a minimum. Also enable any other AWS security services that you want to integrate with Security Hub.
            2. Enable Security Hub for your organization from the organization management account.
            3. If setting a delegated administrator for Security Hub, see Setting a delegated administrator account in Security Hub from the management account.

              Note: As a best practice, we recommend using the same delegated administrator across security services for consistent governance.

            4. Sign in to the delegated administrator with an IAM policy that gives you permission to enable and disable member accounts. With this policy, you will have granular control to decide what Regions you want enabled.
            5. Configure Security Hub plans for deployment. Security Hub comes with the Essentials, Threat Analytics, and Extended plans.
            6. Configure third-party integrations to create incidents or issues for Security Hub findings.

            Note: After you enable Security Hub, exposure findings in your environment are created and analyzed immediately. However, it can take up to 6 hours to receive an exposure finding for a resource.

            Validate deployment

            The final step is to confirm that Security Hub is configured correctly and to evaluate the solution against your success criteria.

            • Validate policy: Verify that you have the correct permissions to manage member accounts and Regional restrictions are configured correctly.
            • Validate integrations: Verify that tickets with ServiceNow or Jira Cloud are working correctly by signing in to the AWS Management Console for Security hub and choosing Inventory in the navigation pane. Select Findings and verify there is a ticket ID in your finding.
            • Assess success criteria: Determine if you achieved the success criteria that you defined at the beginning of the project.

            Conclusion

            In this post, we showed you how to plan and implement an effective Security Hub POC. You learned how to do so through phases, including defining success criteria, configuring Security Hub, and validating that Security Hub meets your business needs. Take advantage of the trial periods to maximize your testing window without incurring significant costs. Throughout the POC, maintain focus on your predefined success criteria while remaining open to unexpected benefits or challenges that might arise. Maintain open communication with your AWS account team to address any questions or concerns to help you get the most out of your Security Hub POC experience.

            Additional resources

            If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

            Kyle Shields

            Kyle Shields

            Kyle is a Security Specialist Solutions Architect focused on threat detection and incident response at AWS. Today, he’s focused on helping enterprise AWS customers adopt and operationalize AWS Security Incident Response and improve their security posture.

            Ahmed Adekunle

            Ahmed is a Security Specialist Solutions Architect focused on detection and response services at AWS. Before AWS, his background was in business process management and AWS technology consulting, helping customers use cloud technology to transform their business. Outside of work, Ahmed enjoys playing soccer, supporting less privileged activities, traveling, and eating spicy food, specifically African cuisine.

            Author

            Marshall Jones

            Marshall is a Worldwide Security Specialist Solutions Architect at AWS. His background is in AWS consulting and security architecture and focused on a variety of security domains including edge, threat detection, and compliance. Today, he’s focused on helping enterprise AWS customers adopt and operationalize AWS security services to increase security effectiveness and reduce risk.

            Can I do that with policy? Understanding the AWS Service Authorization Reference

            27 April 2026 at 18:01

            Understanding what AWS Identity and Access Management (IAM) policies can control helps you build better security controls and avoid spending time on approaches that won’t work. You’ve likely encountered questions like:

            • Can I use AWS Organizations service control policies (SCPs) to prevent the creation of security groups that allow traffic from 0.0.0.0/0?
            • Can I block uploads unless objects are encrypted?
            • Can I prevent functions with more than 512 MB of memory allocated?

            Some of these are possible with IAM policies. Others are not. The difference is determined by a fundamental principle of AWS authorization: Policies make decisions based on information available in the authorization context at the time of the API call.

            In this blog post, you learn how to use the AWS Service Authorization Reference to determine what’s achievable with IAM policies, recognize scenarios that need alternative solutions, and build more effective security controls in your AWS environment.

            Understanding AWS authorization context

            When you make an AWS API request through the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS SDK, the specific AWS service (such as Amazon S3 or Amazon EC2) receiving the request assembles a request context containing information about that request. This context is used for policy evaluation decisions. Request context is structured using the Principal, Action, Resource, Condition (PARC) model, which has four key components.

            • Principal: Identifies the requester and their attributes (tags, session context)
            • Action: Specifies the AWS API operation being requested (for example, s3:PutObject, ec2:RunInstances)
            • Resource: Defines the target AWS resource using Amazon Resource Names (ARNs)
            • Condition: Provides additional context available at request time, such as IP address, time, encryption parameters, MFA status, and service-specific attributes

            The following example shows the typical request context for an Amazon S3 object upload:

            • Principal: AIDA123456789EXAMPLE
            • Action: s3:PutObject
            • Resource: arn:aws:s3:::my-bucket/documents/samplereport.pdf
            • Condition:
              • aws:PrincipalTag/Department=Finance
              • aws:RequestedRegion=us-east-1
              • aws:SourceIp=x.x.x.x
              • aws:MultiFactorAuthPresent=true
              • s3:x-amz-server-side-encryption=AES256
              • s3:x-amz-storage-class=STANDARD_IA

            IAM policies can evaluate request metadata like encryption method and storage class being specified. However, it cannot evaluate the actual file contents, object size, or specific data patterns. Policy evaluation occurs at the time of the request, using the information present in the authorization context.

            An essential resource: The Service Authorization Reference

            The Service Authorization Reference is the authoritative documentation for understanding what policies can control. For every AWS service, it documents:

            • Actions: Every controllable operation
            • Resources: Resource types that can be targeted
            • Condition keys: The exact context information available for policy decisions

            Condition keys are broadly divided into two categories. Global condition keys, which can be used across AWS services, and service-specific condition keys, which are defined for use with an individual AWS service. Use the Service Authorization Reference to find the global-condition keys or service-specific condition keys for each AWS service.

            How to use the Service Authorization Reference

            Follow these steps to determine if your requirement can be controlled with IAM policies:

            1. Navigate to your service: Go to the page for the specific AWS service you’re working with, such as Actions, resources, and condition keys for Amazon S3.
            2. Find the action you want: Find the API operation you want to control. Be precise, different actions have different available condition keys.
            3. Examine available condition keys: The Condition keys column shows what context information AWS makes available for that action.
            4. Make your feasibility determination: If the information you need isn’t listed as a condition key, you will not be able to control it with IAM policies alone.

            Let’s take an example from the Amazon Elastic Compute Cloud (Amazon EC2) ec2:RunInstances action to see what you can and can’t control. In the Service Authorization Reference under the Amazon EC2 section, examine the RunInstances action and check the Resource types column. The RunInstances action affects multiple resource types, each with its own set of condition keys.

            For the instance* resource type:

            • ec2:InstanceType: Can restrict instance types
            • ec2:EbsOptimized: Can require EBS optimization
            • aws:RequestTag/: Can enforce tagging requirements

            For the network-interface* resource type:

            • ec2:Subnet: Can control subnet placement
            • ec2:Vpc: Can limit to specific virtual private clouds (VPCs)
            • ec2:AssociatePublicIpAddress: Can control public IP assignment

            Note: These are a few examples from the many condition keys available for each resource type under the RunInstances action. The Service Authorization Reference lists dozens of condition keys across resource types (instance, network interface, security group, subnet, volume, and so on) that RunInstances affects. Consult the complete reference to see the available options for your specific use case.

            Access the Service Authorization Reference programmatically

            Beyond the human-readable documentation, AWS provides the Service Authorization Reference in machine-readable JSON format to streamline automation of policy management workflows. Use this programmatic access to incorporate authorization metadata into your development and security workflows.
            For detailed information about the JSON structure and field definitions, see the Simplified AWS service information for programmatic access.
            Developers can use tools like the IAM MCP Server for AWS IAM operations. This server provides AI assistants with the ability to manage IAM users, roles, policies, and permissions while following security best practices.

            Using IAM policies to control specific scenarios

            The following examples show how you can use IAM policies to control specific scenarios.

            Example 1: Enforce AES256 server-side encryption on S3 objects

            In the Amazon S3 Service Authorization Reference, under s3:PutObject action, the s3:x-amz-server-side-encryption condition key is available in the authorization context, which can be used to control the server-side encryption of S3 objects with AES-256. Here is the required policy.

            Policy 1: Deny Amazon S3 object upload if the encryption doesn’t use AES-256

            {
            	"Version": "2012-10-17",
            	"Statement": [
            		{
            			"Sid": "DenyUnencryptedObjectUploads",
            			"Effect": "Deny",
            			"Action": "s3:PutObject",
            			"Resource": "arn:aws:s3:::my-bucket/*",
            			"Condition": {
            				"StringNotEquals": {
            					"s3:x-amz-server-side-encryption": "AES256"
            				}
            			}
            		}
            	]
            }

            Policy 1 is a resource-based policy that can be applied on an S3 bucket to restrict object uploads. It denies a PutObject request when the server-side encryption isn’t using the AES-256 encryption algorithm.

            Example 2: Allow different instance types based on the user’s cost center tag.

            When checking the Amazon EC2 Service Authorization Reference for ec2:RunInstances, the ec2:InstanceType condition key, which is resource specific, is available. To restrict instance types based on who is launching them (rather than just what is being launched), you can either combine this with a global condition key or attach different policies to different principals. By using aws:PrincipalTag/tag-key alongside ec2:InstanceType, you can identify the user’s cost center from their IAM identity tags and then apply different instance type restrictions accordingly. This allows a single policy to dynamically enforce different permissions based on the requester’s identity.

            Policy 2: Restricting EC2 instance types by cost center

            {
            	"Version": "2012-10-17",
            	"Statement": [
            		{
            			"Sid": "AllowDevInstanceTypes",
            			"Effect": "Allow",
            			"Action": "ec2:RunInstances",
            			"Resource": "arn:aws:ec2:*:*:instance/*",
            			"Condition": {
            				"StringEquals": {
            					"aws:PrincipalTag/CostCenter": "Development"
            				},
            				"StringLike": {
            					"ec2:InstanceType": "t3.*"
            				}
            			}
            		},
            		{
            			"Sid": "AllowProdInstanceTypes",
            			"Effect": "Allow",
            			"Action": "ec2:RunInstances",
            			"Resource": "arn:aws:ec2:*:*:instance/*",
            			"Condition": {
            				"StringEquals": {
            					"aws:PrincipalTag/CostCenter": "Production"
            				},
            				"StringLike": {
            					"ec2:InstanceType": [
            						"m5.*",
            						"c5.*",
            						"r5.*"
            					]
            				}
            			}
            		}
            	]
            }

            This is an identity-based policy that you can attach to IAM users, groups, or roles to control EC2 instance launches based on cost allocation. In the first statement, aws:PrincipalTag, which is a global condition key (tags attached to the IAM user or role), is used to determine which instance types are allowed. Users tagged with CostCenter=Development can only launch cost-effective T3 instance types (t3.micro, t3.small, t3.medium, and so on)with the service specific key ec2:InstanceType.

            In the second statement, users tagged with CostCenter=Production can launch more powerful instance types from the M5 (general purpose), C5 (compute optimized), and R5 (memory optimized) families. This approach lets organizations enforce cost controls and allocate resources based on workload requirements. Each cost center maintains flexibility for its specific needs.

            Note: Additional resources are required in the IAM policy to successfully launch EC2 instances. For the complete list, see Launch Instances.

            Example 3: Users can only access and update DynamoDB items where the partition key matches their username.

            You have identified that GetItem, PutItem,and UpdateItem actions are required. Corresponding to these actions, you can use the condition key to expose partition key values in the authorization context as described in the Amazon DynamoDB Service Authorization Reference

            Policy 3: DynamoDB fine-grained access control

            {
            	"Version": "2012-10-17",
            	"Statement": [
            		{
            			"Effect": "Allow",
            			"Action": [
            				"dynamodb:GetItem",
            				"dynamodb:PutItem",
            				"dynamodb:UpdateItem"
            			],
            			"Resource": "arn:aws:dynamodb:us-east-1:111122223333:table/UserProfiles",
            			"Condition": {
            				"ForAllValues:StringEquals": {
            					"dynamodb:LeadingKeys": ["${aws:username}"]
            				}
            			}
            		}
            	]
            }

            The policy allows users to perform read and write actions (GetItem, PutItem, and UpdateItem) on the UserProfiles table, but only for items where the partition key value equals their own username (using the ${aws:username} policy variable). For example, if user alice attempts to access an item with partition key bob, the request will be denied.

            Scenarios that need more than policies alone

            Some requirements can’t be met using IAM policies. Here are three common scenarios that aren’t achievable with IAM policies alone.

            Scenario 1: Block users from creating security group rules that allow traffic from 0.0.0.0/0 on TCP port 22

            Upon checking the Amazon EC2 Service Authorization Reference, you will find that the ec2:AuthorizeSecurityGroupIngress action is required in an IAM policy to add an inbound access rules to a security group.

            To verify this in the Service Authorization Reference, navigate to the Amazon EC2 Service Authorization Reference and search for the AuthorizeSecurityGroupIngress action, which is the action that creates security group rules. After you locate this action, review the Condition keys column and look for condition keys related to CIDR blocks, IP ranges, ports, or protocols. Available condition keys for ec2:AuthorizeSecurityGroupIngress include:

            Notice there are no condition keys for CIDR blocks (such as 0.0.0.0/0), port numbers (such as 22), or protocols (such as TCP). The authorization context doesn’t include information about the specific CIDR blocks, ports, or protocols being added to the security group rule, so IAM policies can’t control these attributes.

            Solution
            Take a reactive approach using the AWS Config managed rule INCOMING_SSH_DISABLED to detect overly permissive rules. You can also use a combination of Amazon EventBridge and Lambda to either send a notification to your security team for the non-compliant configuration or to restrict the security group through an automation. For more information, see How to Automatically Revert and Receive Notifications About Changes to Your Amazon VPC Security Groups.

            Scenario 2: Prevent creation of Lambda functions with more than 512 MB of memory allocated

            Following the same verification methodology described in Scenario 1, navigate to the AWS Lambda Service Authorization Reference and examine the CreateFunction action’s condition keys for the function* resource type.

            Available condition keys for lambda:CreateFunction with the function* resource type include:

            • lambda:CodeSigningConfigArn: Filters access by the ARN of the code signing
            • configuration-lambda:Layer: Filters access by the ARN of a version of an AWS Lambda layer
            • lambda:VpcIds: Filters access by the ID of the VPC configured for the Lambda function

            There is no condition key for memory allocation (MemorySize parameter), timeout settings, storage configuration (EphemeralStorage), or runtime selection. Because memory allocation isn’t exposed in the authorization context, IAM policies can’t restrict this parameter.

            Solution

            Key takeaways

            Keep these principles in mind when working with IAM policies:

            • Policies control what’s in the authorization context, not all elements you see in API documentation
            • The Service Authorization Reference is authoritative; if something isn’t listed as a condition key, you can’t control it with policies
            • Different actions have different available contexts even within the same service
            • Alternative approaches exist. AWS Config, EventBridge, and service-specific controls can be used to achieve your goals when policies alone can’t
            • Layered security is essential; combine preventive, detective, and responsive controls to help ensure that your data is secure

            Conclusion

            In this post, you learned how to use the AWS Service Authorization Reference to determine what’s achievable with IAM policies and recognize scenarios that require alternative solutions. By understanding that policies can only make decisions based on information available in the authorization context, you can build more effective security controls and avoid spending time on approaches that won’t work.

            The Service Authorization Reference is your authoritative source for understanding policy capabilities. When you need to implement a control, start there to see if the required condition keys exist. If they don’t, you will need to layer in detective or responsive controls using services like AWS Config, Amazon EventBridge, or AWS Lambda.

            Remember that effective AWS security isn’t about finding one perfect control, it’s about combining preventive, detective, and responsive measures to create defense in depth. IAM policies are powerful tools for prevention and work as part of a comprehensive security strategy.

            Next steps:

            If you have feedback about this post, submit comments in the Comments section below.


            Author

            Anshu Bathla

            Anshu is a Senior Lead Consultant – SRC at AWS, based in Gurugram, India. He works with customers across diverse verticals to help strengthen their security infrastructure and achieve their security goals. Outside of work, Anshu enjoys reading books and gardening at his home garden.

            Author

            Prafful Gupta

            Prafful is an Associate Delivery Consultant at AWS, based in Gurugram, India. Having started his professional journey with Amazon, he specializes in DevOps and Generative AI solutions, helping customers navigate their cloud transformation journeys. Beyond work, he enjoys networking with fellow professionals and spending quality time with family.

            Received — 26 April 2026 AWS Security Blog

            Protecting your secrets from tomorrow’s quantum risks

            24 April 2026 at 20:53

            As outlined in the AWS post-quantum cryptography (PQC) migration plan, addressing the risk of harvest now, decrypt later (HNDL) attack is an important part of your post-quantum plan. Upgrading the client-side of your workloads to support quantum-resistant confidentiality is an important aspect of your side of the PQC shared responsibility model. Timelines to plan and execute your PQC upgrades vary by region and by industry and will depend on your own business risk profile. To learn more, see the AWS PQC frequently asked questions.

            AWS Secrets Manager uses SSL/TLS to communicate with AWS resources, currently supporting TLS 1.2 and 1.3 in all AWS Regions. The service supports using TLS 1.3 with hybrid post-quantum key exchange for clients that support this capability. The hybrid post-quantum approach establishes TLS connections by combining traditional cryptography (such as X25519) with post-quantum algorithms (ML-KEM), and helps to protect your secrets against both current classical attacks and future quantum computer threats. Regardless of how your workload accesses Secrets Manager, this client-side software upgrade is the only action you need to take to address risk to secrets from HNDL. Your secrets at rest are already encrypted using keys managed by AWS Key Management Service (AWS KMS). Properly implemented symmetric encryption is considered quantum-resistant; asymmetric cryptography faces quantum threats. To learn more, watch AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified.

            To reduce builder effort for client-side upgrades, we’re pleased to announce the following Secrets Manager clients now enable and prefer post-quantum TLS when initiating connections to Secrets Manager: Secrets Manager Agent (v2.0.0 or later), the AWS Lambda extension (v19 or later) and the Secrets Manager CSI Driver (v2.0.0 or later). For SDK-based clients, hybrid post-quantum key exchange is available in supported AWS SDKs. Enablement requirements vary by language, version, and operating system. See the following table for your SDK client.

            This launch is part of the ongoing commitment AWS has made to migrate systems to post-quantum cryptography and making it straightforward for our customers to do the same. See Post-Quantum Cryptography to learn more.

            Client hybrid post-quantum key exchange requirements

            The following table summarizes the behavior for each client. When the client is upgraded to support hybrid post-quantum key exchange, the Secrets Manager service endpoint automatically selects it during the TLS handshake. Upgrading to the versions listed in the table is the only action you need to take for your workload to begin using hybrid post-quantum key exchange when calling Secrets Manager APIs.

            Client Requirements
            Secrets Manager Agent Hybrid PQ key exchange in TLS preferred by default (v2.0.0 and later)
            AWS Lambda extension Hybrid PQ key exchange in TLS preferred by default (Version 19 and later)
            Secrets Manager CSI Driver Hybrid PQ key exchange in TLS preferred by default (v2.0.0 and later)
            AWS SDK for Rust Hybrid PQ key exchange in TLS preferred by default (releases after August 29, 2025)
            AWS SDK for Go Hybrid PQ key exchange in TLS preferred by default (Go v1.24 and later)
            AWS SDK for Node.js Hybrid PQ key exchange in TLS preferred by default (Node.js v22.20 and v24.9.0 and later)
            AWS SDK for Kotlin Hybrid PQ key exchange in TLS preferred by default on Linux (v1.5.78 and later)
            AWS SDK for Python The AWS SDK for Python (boto3) uses the OS-provided OpenSSL for TLS.
            Hybrid PQ key exchange in TLS requires running on a system with OpenSSL 3.5 or later installed.
            AWS SDK for Java v2 AWS SDK for Java v2 requires an AWS CRT HTTP client that supports PQ TLS when configured using postQuantumTlsEnabled.
            Secrets Manager caching clients The Secrets Manager caching libraries are built on the AWS SDKs and inherit their TLS behavior. Note for Java: The JDBC driver flag and Java Caching flag must be set to enable Hybrid PQ key exchange in TLS.

            If you’re using the Secrets Manager Agent, the Lambda extension, or the CSI Driver, upgrade to the listed version to use hybrid post-quantum key exchange in TLS as the default. Customers using the AWS SDK for Rust, Go, or Node.js at the versions listed in the table are already upgraded and no additional action is required. The SDK will select the hybrid post-quantum key exchange for API calls. For customers using the AWS SDK for Python, hybrid post-quantum key exchange in TLS requires OpenSSL 3.5 or later to be present on the host system. Guidance on verifying and enabling this is available in the AWS Secrets Manager documentation. For customers using the AWS SDK for Java v2, hybrid post-quantum key exchange in TLS requires using the AWS CRT HTTP client. The postQuantumTlsEnabled(true) must be set on the CRT client to enable hybrid post-quantum key exchange in TLS.

            After your client versions meet the requirements listed in the table, you can verify that your connections are actively using hybrid post-quantum key exchange.

            How to verify your connection uses hybrid post-quantum key exchange

            With hybrid post-quantum key exchange using ML-KEM now enabled by default for Secrets Manager clients (see the preceding table), most customers will not need ongoing monitoring to verify correct behavior or detect regressions. However, security teams and compliance officers might want to confirm that their Secrets Manager API calls are negotiating the hybrid key exchange. On the server side, you can confirm hybrid post-quantum key exchange in TLS by using AWS CloudTrail. On the client side, you can inspect TLS handshake details using a utility like Wireshark or by using developer tools built into major web browsers.

            Verification is a two-step process: first, fetch a secret using your Secrets Manager client to generate a GetSecretValue API call, then confirm in AWS CloudTrail that the call negotiated hybrid post-quantum key exchange.

            Fetch your secret using your Secrets Manager client

            The following examples show how to retrieve your secret using the Secrets Manager Agent, Lambda extension, and CSI Driver—each of which will automatically negotiate hybrid post-quantum key exchange when calling the GetSecretValue API.

            To verify hybrid post-quantum TLS with Secrets Manager Agent on EC2 instance:
            Install the agent on your Amazon Elastic Compute Cloud (Amazon EC2) instance and use it as a client to fetch your secret.

            1. Follow the instructions for AWS Secrets Manager Agent.
            2. Ensure that your EC2 instance profile has the permission for secretsmanager:GetSecretValue to fetch the secret.
            3. Connect to your private EC2 instance.
            4. Install the agent on your EC2 instance.
            5. Use the agent to fetch your secret.
              curl -H “X-Aws-Parameters-Secrets-Token: $(</tmp/awssmatoken)” localhost:2773/secretsmanager/get?secretId=<YOUR-SECRET-ARN>
            6. Wait for about 5 minutes for CloudTrail to deliver the logs.
            7. Go to the CloudTrail event history and search for the event GetSecretValue.

            To verify hybrid post-quantum TLS with Lambda extension:
            Use the AWS parameters and Secrets Manager Lambda extension to create a Lambda function that will consume your secrets from Secrets Manager using direct API calls.

            1. Follow Using the AWS parameters and secrets Lambda extension to create the Lambda layer and the Lambda function.
            2. Select the latest extension version.
            3. Wait for about 5 minutes for CloudTrail to deliver the logs.
            4. Go to the CloudTrail event history and search for the event GetSecretValue.

            To verify hybrid post-quantum TLS with CSI driver on Amazon EKS:
            On your Amazon Elastic Kubernetes Service (Amazon EKS) cluster, use the AWS Secrets Store CSI Driver provider to fetch secrets from Secrets Manager in Kubernetes pods:

            1. Confirm the installed add-on version is 2.0.0 or later.
              eksctl get addon --cluster <CLUSTER-NAME> --name aws-secrets-store-csi-driver-provider
            2. Trigger a secret retrieval by restarting a pod that mounts a secret, or deploying a new one.
            3. Wait for about 5 minutes for CloudTrail to deliver the logs.
            4. Go to the CloudTrail event history and search for the event GetSecretValue.

            Confirm hybrid post-quantum key exchange using CloudTrail

            CloudTrail logs include a tlsDetails field for Secrets Manager API calls. When hybrid post-quantum key exchange in TLS is active, the keyExchange field in tlsDetails will show X25519MLKEM768. Each CloudTrail record includes a tlsDetails field that contains the cipher suite and, where available, the key exchange group negotiated during the TLS handshake.

            You can work with CloudTrail event history using the AWS Management Console for CloudTrail or the AWS Command Line Interface (AWS CLI).

            To look up CloudTrail events using the console:

            1. Verify you are in the correct AWS Region.
            2. Open the CloudTrail console and select Event History.
            3. Under Lookup attributes filter, select Event name and GetSecretValue.
              Figure 1: Search CloudTrail event history by event name

              Figure 1: Search CloudTrail event history by event name

            4. Select your event.
              Figure 2: Select the event

              Figure 2: Select the event

            5. View the output in the Event Record section of the page.
              Figure 3: CloudTrail - GetSecretValue event

              Figure 3: CloudTrail – GetSecretValue event

            To look up CloudTrail events using AWS CLI :
            Using AWS CLI, select the last events and look at the output.

            aws cloudtrail lookup-events \
            --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
            --max-results 5 \
            --region <YOUR-REGION> \
            --query 'Events[0].CloudTrailEvent' \
            --output text

            Example of CloudTrail Event for GetSecretValue API call:

            In the following example, the userAgent field reflects what it used as a client to connect to Secrets Manager.

            Note: The userAgent value depends on the client you use.

            {
                "eventVersion": "1.11",
                "userIdentity": {
                    "type": "AssumedRole",
                    "principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89",
                    "arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89",
                    "accountId": "111122223333",
                    "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
                    "sessionContext": {
                        "sessionIssuer": {
                            "type": "Role",
                            "principalId": "AROA123456789EXAMPLE",
                            "arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE",
                            "accountId": "111122223333",
                            "userName": "YOUR-EC2-INSTANCE-PROFILE"
                        },
                        "attributes": {
                            "creationDate": "2026-03-27T17:08:37Z",
                            "mfaAuthenticated": "false"
                        },
                        "ec2RoleDelivery": "2.0"
                    },
                    "inScopeOf": {
                        "issuerType": "AWS::EC2::Instance",
                        "credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89"
                    }
                },
                "eventTime": "2026-03-27T17:12:54Z",
                "eventSource": "secretsmanager.amazonaws.com",
                "eventName": "GetSecretValue",
                "awsRegion": "eu-west-2",
                "sourceIPAddress": "1.2.3.4",
                "userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0",
                "requestParameters": {
                    "secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
                },
                "responseElements": null,
                "requestID": "027507ea-f377-43d9-bf2f-646d4dc19223",
                "eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73",
                "readOnly": true,
                "resources": [
                    {
                        "accountId": "111122223333",
                        "type": "AWS::SecretsManager::Secret",
                        "ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
                    }
                ],
                "eventType": "AwsApiCall",
                "managementEvent": true,
                "recipientAccountId": "111122223333",
                "eventCategory": "Management",
                "tlsDetails": {
                    "tlsVersion": "TLSv1.3",
                    "cipherSuite": "TLS_AES_128_GCM_SHA256",
                    "clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com",
                    "keyExchange": "X25519MLKEM768"
                }
            }
            
            

            If the keyExchange field shows X25519MLKEM768, then hybrid post-quantum key exchange in TLS is active. If it shows a traditional algorithm such as X25519, the client is not advertising ML-KEM support, and you should check the client version and configuration.

            Troubleshooting

            If your Secrets Manager API calls aren’t negotiating X25519MLKEM768 after updating your clients, check your SDK version, OpenSSL version (Python), and firewall or proxy configuration as shown in the Client Hybrid Post-Quantum Key Exchange Requirements section near the beginning of this post.

            What’s next

            This launch is one step in a broader migration. AWS is continuing to roll out ML-KEM support across AWS service HTTPS endpoints as part of Workstream 2 of the AWS PQC Migration Plan, with a target of full coverage across public AWS endpoints.

            Support for CRYSTALS-Kyber, the pre-standardization predecessor to ML-KEM, is phasing out across AWS endpoints in 2026. Customers on older SDK versions that advertise only CRYSTALS-Kyber support will fall back gracefully to traditional TLS rather than negotiate the deprecated algorithm. To avoid this fallback, upgrade to the SDK versions listed in this post.

            The journey of PQC migration extends beyond confidentiality of data in transit. To stay informed about the latest developments in the AWS PQC journey and your side of shared responsibility, follow the AWS Post-Quantum Cryptography page.

            Conclusion

            AWS Secrets Manager now enables hybrid post-quantum key exchange using ML-KEM by default to help protect your secrets and support your compliance efforts. This update requires no code changes or configuration updates for customers using the latest client versions.

            This post covered how AWS Secrets Manager uses hybrid post-quantum cryptography to secure TLS connections, which clients support this capability, and how to verify that your connections are protected against harvest now, decrypt later attacks.

            To benefit from this announcement today:

            • Upgrade your Secrets Manager client (Agent, Lambda extension, or CSI Driver) to the latest available versions to enable hybrid post-quantum key exchange using ML-KEM
            • If your workload uses the AWS SDK instead of a caching client, upgrade your AWS SDK and underlying dependencies to the minimum versions listed in this post
            • Verify hybrid post-quantum key exchange in TLS is active by checking the keyExchange field in CloudTrail tlsDetails for your Secrets Manager API calls
            • Test end-to-end hybrid post-quantum key exchange TLS connectivity in your environment, including network paths that traverse corporate firewalls or proxies

            AWS will continue rolling out post-quantum cryptography support. For information about the broader migration effort, see the AWS PQC Migration Plan. Keep an updated cryptographic inventory of your broader environment to identify other uses of traditional public-key cryptography that will require migration. The CISA Quantum-Readiness guidance and the AWS PQC Migration Plan are good starting points.

            Additional resources

            If you have feedback about this post, submit comments in the Comments section below.

            P. Stéphanie Mbappe

            P. Stéphanie Mbappe

            Stéphanie is a Security Consultant with Amazon Web Services. She delights in assisting her customers at any step of their security journey. Stéphanie enjoys learning, designing new solutions, and sharing her knowledge with others.

            Tobias Nickl

            Tobias Nickl

            Tobias is a Security Consultant at Amazon Web Services, specializing in security architecture and cloud transformation. He partners with AWS customers to design and implement security architectures that address both current and emerging threats. Through his work, he helps organizations build security strategies that evolve with their cloud maturity.

            Received — 23 April 2026 AWS Security Blog

            A technical walkthrough of multicloud full-stack security using AWS Security Hub Extended

            22 April 2026 at 18:31

            Building on our recent announcement of AWS Security Hub Extended —our full-stack enterprise security offering — we want to show you how we’re simplifying security procurement and operations for your multicloud environments. Whether you’re a security architect evaluating solutions or a CISO looking to streamline vendor management, this post walks through the streamlined experience that transforms how you acquire, deploy, and manage end-to-end enterprise security solutions across endpoint, identity, email, network, data, browser, cloud, AI, and security operations. Security Hub Extended brings together AWS security services with carefully curated security partners. Delivering better outcomes together through unified procurement, billing, and operations that significantly reduce vendor management overhead so you can focus on what matters most: protecting your organization.

            The challenge we’re addressing

            Security teams today spend too much time on vendor management, evaluating services, negotiating contracts, and managing multiple billing cycles instead of focusing on what matters most: managing risk. But the procurement challenge runs even deeper. Until now, customers really only had one option: sign multi-year agreements based solely on proof-of-concept testing and estimated annual usage. This forces organizations to commit budget before they can validate whether a solution will work for them at scale.

            AWS Security Hub Extended transforms this procurement model. Security Hub Extended offers customers the option to get started with pay-as-you-go pricing and no commitments, so they can move fast and validate solutions in their actual environment. After they’ve confirmed a solution works at scale, they can then align their vendor strategy and sign longer-term commitments for even more favorable pricing.

            Security Hub Extended provides a curated set of carefully chosen partner solutions with competitive pricing, unified billing through your AWS account, and seamless integration. Our initial launch partners, selected by customers for their proven value, include 7AI, Britive, CrowdStrike, Cyera, Island, Noma, Okta, Oligo, Opti, Proofpoint, SailPoint, Splunk, Upwind, and Zscaler.

            Getting started with Security Hub Extended

            AWS Security Hub consolidates threat analytics from Amazon GuardDuty, vulnerability management from Amazon Inspector, and sensitive data discovery from Amazon Macie, correlating these signals with Security Hub Exposure findings to determine overall risk, reachability, and assumability. Security Hub Extended builds on this foundation by adding curated partner solutions, extending these unified security operations across your entire organization including multicloud, on-premises, and endpoint environments. If you’re already using Security Hub, you can navigate directly to the Extended plan section.

            Getting started with Security Hub is straightforward. From the AWS Management Console, search for Security Hub to start the onboarding walkthrough. If you’re not already a Security Hub customer, you can quickly complete onboarding by designating an AWS organization delegated administrator (DA) account. You can then centrally enable and manage Security Hub across your entire organization’s accounts and AWS Regions from a single location (see Introduction to AWS Security Hub). After you’ve onboarded, navigate to the Extended plan section to add curated partner solutions.

            Figure 1- Security Hub centralized configuration

            Figure 1: Security Hub centralized configuration

            From this single interface, you can enable detection and response capabilities across your entire organization, provide granular configurations at the organizational unit or member account level, select specific Regions, and turn individual features on or off as needed.

            Understanding risk through attack paths

            The Security Hub risk correlation engine identifies potential exposures by correlating threats, vulnerabilities, and misconfigurations to reveal how they connect and could lead to compromise of critical resources.

            Figure 2 - Security Hub exposure attack path visualization

            Figure 2: Security Hub exposure attack path visualization

            The attack path visualization in the preceding figure reveals critical insights including upstream root causes and blast radius, showing the potential impact if a threat actor exploits a vulnerability. You can use this visualization to focus on fixing the root cause rather than addressing symptoms. For example, updating one security group configuration can eliminate the entire attack path, cutting off all downstream exposure.

            Accessing Security Hub Extended

            You can find Security Hub Extended, shown in the following figure, in the left navigation pane under Management in your Security Hub delegated administrator (DA) account; Security Hub Extended will only be visible from the delegated administrator account. The Extended plan brings curated third-party security solutions directly into the Security Hub experience. Because Extended is built into Security Hub, there’s no separate console to manage. You discover, subscribe to, and operate curated partner solutions from the same place you manage enterprise security, delivering unified operations across your entire security estate.

            Figure 3- Security Hub Extended partners

            Figure 3: Security Hub Extended partners



            Transparent, competitive pricing consolidated with Security Hub

            Unlike traditional third-party engagements that require lengthy negotiations, private pricing deals, and multi-year commitments, Security Hub Extended offers complete pricing transparency. Every partner solution displays clear, competitive monthly pay-as-you-go rates billed directly with Security Hub requiring no commitments. For example, Cloud Security from Upwind costs $3.75 per resource per month, and Identity Security from Okta costs $20 per user per month.

            All Security Hub Extended offerings are also eligible for AWS Enterprise Discount Program (EDP) discounts that will be applied automatically. If you have an existing AWS enterprise discount agreement, those discounts automatically apply to Security Hub Extended offerings, further reducing your effective costs. All partner solutions you deploy through Security Hub Extended appear on your consolidated AWS bill, no separate invoices or payment processes.

            Streamlined onboarding

            Adopting curated partner solutions through Security Hub Extended is straightforward. Choose View Product to initiate an automated workflow. Depending on the solution, you’ll either be directed to the partner onboarding console or provide information for the partner to guide you through their onboarding process tailored to your environment.

            Billing begins only after you’re fully activated on the partner solution and starts automatically, no additional action is required to benefit from the unified billing. If you’re already using one of the curated partner solutions, transitioning to Security Hub Extended for consolidated billing and flexible pricing won’t disrupt your current services. Now, instead of receiving separate invoices for each partner in addition to Amazon Inspector, GuardDuty, and Security Hub CSPM you get one unified bill through Security Hub. This consolidates visibility to support better understanding of spend and to manage cost.

            Unified operations

            Security Hub Extended unifies security operations by consolidating findings from AWS and curated partner solutions. All findings use the Open Cybersecurity Schema Framework (OCSF) for consistency, without the need for complex data normalization, transformation, and extract, transform, and load (ETL) processes.

            When you deploy solutions such as CrowdStrike, Noma, and Upwind alongside Splunk and 7AI through Security Hub Extended, security findings automatically flow into Security Hub and then seamlessly route to Splunk and 7AI. All in OCSF format so your security team can focus on responding to threats, not managing pipelines, so you can quickly identify and respond to security risks that span boundaries—from endpoint compromises to cloud infrastructure—without spending valuable time on manual integration work.

            The full-stack security vision

            Security Hub Extended represents a shift in how you discover, procure, and build comprehensive security programs. Instead of managing dozens of vendor relationships, negotiating separate contracts, agreeing to multi-year annual commitments, and integrating disparate tools, you now have one procurement process through AWS, one bill with transparent competitive pay-as-you-go pricing, one console for unified security operations, one support channel for AWS Enterprise Support customers, and one schema (OCSF) for all security findings. The result: reduced security risk, improved team productivity, and a more unified approach to security operations across your enterprise.

            Get started

            Try Security Hub Extended today and experience how simplified procurement and unified operations can transform your security program. Security Hub Extended is generally available globally in all AWS commercial Regions where Security Hub is available. We’ve also published a walk through video to further explain how Security Hub Extended works.

            It’s still Day 1, but we’re iterating fast, so share your feedback with us on AWS re:Post for Security Hub or through your AWS Support contacts and watch for future blog posts on our progress.


            Matt Meck

            Matt Meck

            Matt is a Worldwide Security Specialist at Amazon Web Services, based in New York, with 10 years of experience in the tech industry. For the past 4 years at AWS, he’s focused on Detection and Response, helping solve complex security challenges in the rapidly evolving security space. He works closely with product teams, customers, partners, and field teams to deliver effective security solutions.

             

            Michael Fuller

            Michael Fuller

            Michael has been with AWS for 16 years and led product for AWS Security Services for 11 years. Michael has 29 years in the industry and held several roles in product management, business development, and software development for IBM, Cisco, and Amazon. Michael has a Bachelor’s of Science in Computer Engineering from the University of Arizona and an MBA from the University of Washington.

             

            Winter 2025 SOC 1 report is now available with 184 services in scope

            22 April 2026 at 02:12

            Amazon Web Services (AWS) is pleased to announce that the Winter 2025 System and Organization Controls (SOC) 1 report is now available. The report covers 184 services over the 12-month period from January 1, 2025 – December 31, 2025, giving customers a full year of assurance. This report demonstrates our continuous commitment to adhering to the heightened expectations of cloud service providers.

            Customers can download the Winter 2025 SOC 1 report through AWS Artifact, a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.

            AWS strives to continuously bring services into the scope of its compliance programs to help customers meet their architectural and regulatory needs. You can view the current list of services in scope on our Services in Scope page. As an AWS customer, you can reach out to your AWS account team if you have any questions or feedback about SOC compliance.

            To learn more about AWS compliance and security programs, see AWS Compliance Programs. As always, we value feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

            If you have feedback about this post, submit comments in the Comments section below.

            Tushar Jain

            Tushar Jain
            Tushar is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives Tushar holds a Master of Business Administration from Indian Institute of Management Shillong, India and a Bachelor of Technology in electronics and telecommunication engineering from Marathwada University, India. He has over 14 years of experience in information security and holds CISM, CCSK and CSXF certifications.

            Michael Murphy

            Michael Murphy
            Michael is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives. Michael has over 14 years of experience in information security and holds a master’s degree and a bachelor’s degree in computer engineering from Stevens Institute of Technology. He also holds CISSP, CRISC, CISA, and CISM certifications.

            Atulsing Patil

            Atulsing Patil
            Atulsing is a Compliance Program Manager at AWS and has over 28 years of consulting experience in information technology and information security management. Atulsing holds a Master of Science in Electronics degree and professional certifications such as CCSP, CISSP, CISM, CDPSE, ISO 42001 Lead Auditor, ISO 27001 Lead Auditor, HITRUST CSF, Archer Certified Consultant, and AWS CCP.

            Nathan Samuel

            Nathan Samuel
            Nathan is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives. Nathan has a Bachelor of Commerce degree from the University of the Witwatersrand, South Africa, and has over 21 years of experience in security assurance. He holds the CISA, CRISC, CGEIT, CISM, CDPSE, and Certified Internal Auditor certifications.

            Jeff Cheung

            Jeff Cheung
            Jeff is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives across business lines. Jeff has Bachelors degrees in Information Systems, and Economics from SUNY Stony Brook, and has over 20 years of experience in information security and assurance. Jeff has held professional certifications such as CISA, CISM, and PCI-QSA.

            Noah Miller

            Noah Miller
            Noah is a Compliance Program Manager at AWS and leads multiple security and privacy initiatives. Noah has 7 years of experience in information security. He has a master’s degree in Cybersecurity Risk Management and a bachelor’s degree in Informatics from Indiana University.

            Will Black Will Black
            Will is a Compliance Program Manager at Amazon Web Services where he leads multiple security and compliance initiatives. Will has 10 years of experience in compliance and security assurance and holds a degree in Management Information Systems from Temple University. Additionally, he is a PCI Internal Security Assessor (ISA) for AWS and holds the CCSK and ISO 27001 Lead Implementer certifications.
            Allen Beam Allen Beam
            Allen is a Compliance Program Manager at Amazon Web Services supporting third-party security and privacy compliance initiatives. He has over 10 years of experience in external IT security audits, security control design and implementation, and audit readiness and control deficiency remediation. He has a Bachelor’s Degree in Economics and Finance from James Madison University.
            Ziv Wand Ziv Wand
            Ziv is a Compliance Program Manager at AWS and leads multiple security and privacy initiatives. Ziv has over 6 years of experience in information security assurance, external IT security audits, security control design and implementation, and audit readiness. He holds a Bachelor of Science in Management Information Systems from Binghamton University.
            Shalini Mishra Shalini Mishra
            Shalini is a Compliance Program Manager at AWS. She has over 5 years of experience leading end-to-end compliance programs across ISO, SOC, and cloud security frameworks, with deep expertise in third-party risk management and enterprise governance. Shalini holds a Master of Science degree in Information Systems and a CRISC certification.

            Introducing the Landing Zone Accelerator on AWS Universal Configuration and LZA Compliance Workbook

            4 April 2026 at 23:35

            November 20, 2025: Original publication date of this post. This post has been updated to reference the most recent version of the LZA Compliance Workbook published to AWS Artifact in March 2026.


            We’re pleased to announce the availability of the latest sample security baseline from Landing Zone Accelerator on AWS (LZA)—the Universal Configuration. Developed from years of field experience with highly regulated customers including governments across the world, and in consultation with AWS Partners and industry experts, the Universal Configuration was built to help you implement security and compliance at scale for on your regulated workloads. By setting a high bar with the latest AWS security best practices, the Universal Configuration can help address technical control requirements from compliance frameworks across different geographic regions and industry verticals. The Universal Configuration’s multi-account security architecture provides a foundation to host your diverse workload requirements today along with providing the ability to explore the generative AI and agentic AI solutions that will shape your organization in the future. It can also replace months of complex planning and design by deploying a comprehensive security and compliance-driven environment based on AWS Well-Architected principles in a matter of hours.

            As organizations grow, they typically pursue or must adhere to new security compliance certifications. LZA and the Universal Configuration help organizations of all sizes and phases in their security and compliance journey. The speed of deployment, step-by-step documentation, and compliance resources can reduce traditional assessment and authorization timelines by months and result in more predictable and successful audit outcomes. This enables more freedom to invest resources to grow the business instead of choosing between security and compliance tradeoffs.

            The Universal Configuration helps organizations:

            • Automate the deployment of a secure multi-account AWS environment
              • Foundational security controls based on AWS Well-Architected best practices
              • Apply consistent and predictable security controls post-deployment
              • Enable and integrate with native AWS security, identity, and compliance services
            • Implement controls across system layers
              • Organization-wide security architecture
              • Perimeter and resource-specific preventative, proactive, and detective controls
              • Support for multi-AWS Region resilience, disaster recovery, and active failover
            • Establish a foundation for security and compliance readiness
              • Built-in AWS security best practices and technical implementation statements
              • Map LZA capabilities across global and industry-specific compliance frameworks
              • Deploy hundreds of controls hours instead of months

            The LZA Compliance Workbook

            The LZA engine has been a trusted tool for quickly deploying secure multi-account AWS environments for over 4 years. It is also cost effective because you pay only for the AWS services used to operate your environment. The Universal Configuration is the first sample configuration accompanied by the LZA Compliance Workbook available on AWS Artifact. It is a first-of-its-kind resource with detailed control mappings showing how the Universal Configuration can support different industries and regions, helping you address requirements from frameworks listed below.

            • NIST 800-53 Rev5
            • C5: 2020 (Germany)
            • HIPAA
            • SOC 2
            • CMMC Level 2
            • ISO/IEC 27001 Annex A
            • US Dept of War CCI
            • NERC-CIP
            • NIST 800-171
            • NATO D-32 Appendix B
            • NIST CSF 2.0
            • CIS Critical Controls v8

            The LZA Compliance Workbook is regularly maintained to reflect the latest Universal Configuration baseline and will include additional compliance mappings in future releases. The workbook contains detailed security configuration descriptions based on the Universal Configuration deployment files, along with control requirement mappings and implementation statements that translate its security capabilities into a compliance-friendly format. By combining AWS security best practices with global compliance expertise, the Universal Configuration delivers predicable security outcomes while also helping you meet regional and industry requirements.

            Getting started

            To get started with the Landing Zone Accelerator on AWS Universal Configuration, the LZA Implementation Guide walks you through the steps, use cases, and considerations when deploying with LZA. You can download the LZA Compliance Workbook from AWS Artifact today and configure notifications to receive emails when future versions are released. You can view the deployment files and additional technical implementation guidance on the GitHub Universal Configuration sample and documentation page. Additionally, visit the AWS Partner Network (APN) for help with audit and advisory initiatives, cloud migrations, deploying the LZA Universal Configuration, and other services. You can visit the AWS Partner Finder tool and search by solution for Landing Zone Accelerator for the latest LZA Partner offerings.

            If you have feedback about this post, submit comments in the Comments section below.

            Kevin Donohue

            Kevin Donohue

            Kevin is a Senior Security Compliance Engineer at AWS, where he builds solutions and resources to help AWS customers achieve their security and compliance goals. Prior to joining the Landing Zone Accelerator team in AWS Professional Services in 2024, Kevin began his tenure with AWS Security in 2019 specializing in FedRAMP compliance and the shared responsibility model.

            Christine Screnci

            Christine Screnci

            Christine is a Principal Technical Product Manager at AWS, where she specializes in developing and scaling enterprise-level solutions. Christine began her tenure with AWS in 2016 working with Worldwide Public Sector customers to improve the migration and modernization journey through globally scaled solutions. She is passionate about hypothesis-driven development and experimentation to improve customer experiences with AWS technologies.

            Bhavish Khatri

            Bhavish is a Senior Delivery Engineer at AWS, where he builds enterprise-scale solutions to help large organizations achieve their compliance goals. Bhavish started at AWS in 2018, specializing in multi-account AWS deployments and focusing on LZA and the Universal Configuration solution. He helps organizations build secure, scalable cloud environments that align with global compliance frameworks and regulatory requirements across diverse sectors.

            Four security principles for agentic AI systems

            2 April 2026 at 22:45

            Agentic AI represents a qualitative shift in how software operates. Traditional software executes deterministic instructions. Generative AI responds to human prompts with output that humans review and use at their discretion. Agentic AI differs from both. Agents connect to software tools and APIs and uses large language models (LLMs) as reasoning engines to plan and execute sequences of actions autonomously—at machine speed—with real-world consequences. This shift raises new questions for information security. In January 2026, NIST’s Center for AI Standards and Innovation (CAISI) issued a Request for Information (RFI) seeking industry input on how to secure these systems. AWS submitted a response grounded in our experience building and operating agentic AI services. This post summarizes the four security principles at the heart of that response and the architectural building blocks that implement them.

            The NIST agentic AI RFI

            CAISI asked developers, deployers, and security researchers to weigh in on how the industry should secure AI systems that act autonomously. The RFI posed questions across five areas. What unique security considerations do agentic systems introduce, and how do those considerations change as systems gain more autonomy? What practices improve security during development and deployment? How do organizations assess the security of their agentic systems? How can deployment environments be constrained and monitored? And where should the industry focus future research?

            Why this matters

            Even a conservative risk/benefit analysis will conclude that the benefits of agentic AI clearly outweigh the risks in many domains. The rapid adoption of agentic technology across business and government confirms this. But agents are valuable precisely because of their autonomy and adaptability, and these same characteristics create the security challenge. An agentic system that carries out an unintended action can do so at machine speed, before a human can intervene. Unlike human actors who pause or escalate when something seems unusual, agents might not inherently recognize ambiguities that are evident to humans, nor intuitively grasp unstated policy boundaries.

            The good news, however, is that the security response to agentic AI doesn’t need to start from scratch. Existing security frameworks, including the NIST Cybersecurity Framework, NIST AI Risk Management Framework, and the Secure Software Development Framework, remain relevant and should be extended for agent-specific considerations rather than replaced. The most important extension is architectural. Our response to NIST identified four foundational security principles that address how to make that extension.

            Four security principles for agentic AI

            These principles build on the premise that agentic AI doesn’t require a new security paradigm, but it does require existing practices to evolve. The first two principles address what carries forward; the second two address what is genuinely new.

            Principle 1: Secure development lifecycle practices apply across system components. Agentic AI systems combine traditional software components (APIs, databases, orchestration logic) with AI elements such as foundation models, prompt templates, and retrieval pipelines. A secure development lifecycle must cover both sets of components. For traditional components, established practices such as code review, static analysis, dependency scanning, and threat modeling remain essential, keeping in mind that those practices are also in the process of being enhanced with AI-based tooling. For AI components, the challenge is different. Foundation models are probabilistic, which means traditional regression testing is necessary but not sufficient. Organizations must supplement it with behavioral testing, adversarial evaluation, and continuous monitoring to validate that AI components operate within expected parameters.

            Regular re-evaluation is equally important for addressing behavioral drift. Models receive updates that can alter behavior. Prompt templates evolve as teams refine agent capabilities. New tools and data sources expand the agent’s operational surface. Each change can introduce new failure modes or potential security issues. Organizations must treat evaluation as an ongoing operational practice, not a one-time gate. This includes automated testing after model updates, red team exercises against deployed agents, and monitoring that detects behavioral drift over time.

            Principle 2: Traditional security controls remain fully applicable. Agentic AI introduces new considerations, but it doesn’t render existing security risks obsolete. The full complement of traditional security controls still applies. An agentic AI system combines traditional software with the new LLM-plus-tools processing loop. Organizations must secure existing software, tools, and configurations against well-known risks to provide a sound foundation for the agentic elements.

            Privilege escalation, confused deputy issues, session hijacking, code injection, and supply chain risks extend directly into agentic systems. Some of these risks increase in agentic contexts. Agents operate at greater scale and speed than human actors, which means excessive privileges carry more potential for unintended consequences. That means that applying principles of least privilege to access management in an agentic context is as important—if not more so—than in traditional systems. The supply chain surface is also broader. Agentic systems consume not only third-party code dependencies but also foundation models, plugins, tool servers, and data retrieval sources. Agents that invoke APIs, query databases, or generate code create new potential injection surfaces at tool boundaries. AI-specific controls must be additions to this foundational security, not replacements for it.

            Principle 3: Deterministic external controls are the starting point for agentic security. This is the most important architectural principle for agentic AI security. Organizations should enforce security through deterministic, infrastructure-level controls external to the agent’s reasoning loop, not through the agent’s own reasoning, internal guardrails, or prompt-based instructions. The logic is straightforward. LLMs are probabilistic reasoning engines, not security enforcement mechanisms. Developers can instruct an LLM to refuse certain requests, but prompt injection techniques can override those instructions. An LLM can be told to respect access boundaries, but it has no reliable mechanism to enforce them. Attempting to constrain agent behavior only through prompting or alignment runs against the fundamental value proposition of agents, which is their ability to adapt dynamically to novel situations.

            Effective security places fully specified, deterministic controls outside the agent that govern which tools it can access, what operations it can perform, and what data it can reach. Model manipulation cannot bypass these controls. We describe this as the security box. It’s external to the agent, deterministic in its enforcement, and comprehensive in its coverage. Every interaction between the agent and the outside world passes through it. The Agentic AI Security Scoping Matrix helps organizations calibrate the rigor of these controls based on their system’s autonomy level. Scopes range from systems that require explicit human approval before every action to fully autonomous systems that initiate their own activities based on external events.

            The security box isn’t a limitation on the agent’s value. It’s the precondition for achieving that value responsibly. As agentic technology matures, the box itself will likely evolve to include agentic elements. Specialized AI agents designed to control the scope of other agents might replace some deterministic constraints over time, using new information and context to make more appropriate automated decisions than could be achieved by humans managing complex deterministic controls.

            Principle 4: Greater autonomy should be earned through ongoing evaluation. Organizations should expand agent autonomy progressively based on demonstrated performance, not grant it by default. The starting point is human decision-making for high-consequence operations. When an agent encounters an action that could modify high-value production data, initiate financial transactions, or communicate sensitive information externally, a human makes the final decision. The agent recommends, and a human approves or rejects.

            This approach carries a well-known risk. If every agent action requires human approval, the volume of decisions might overwhelm reviewers. Approval becomes reflexive rather than deliberate, shifting liability to humans who have been placed in a position to fail. Organizations must scope human oversight to genuinely high-consequence operations and resist the temptation to require human-in-the-loop designs for routine actions that carry low risk.

            The path from human oversight to expanded autonomy runs through evaluation. As organizations systematically record what the agent recommended, what the human decided, and what actually happened, they build the evidence base for expanding autonomy. When data shows sustained alignment, organizations can shift from prior approval to after-the-fact review, and eventually to full autonomy for specific operation types. This progression should happen at the operation or workflow level, not across a broad range of unrelated tasks.

            This progression isn’t one-way. Organizations should be prepared to reintroduce human oversight when evidence warrants it. Some deterministic boundaries likely remain permanent for the foreseeable future. These boundaries exist not because the agent hasn’t earned trust, but because the consequences of certain actions are unacceptable under a reasonable risk analysis. The overall model is one of earned autonomy through demonstrated competence, governed by evaluation, bounded by permanent constraints, and subject to continuous review. There might come a time with specialized boundary agents can provide better outcomes than purely deterministic controls, but that option can only emerge over time from experience and evaluation.

            From principles to practice

            The four principles define the goals. Achieving them requires specific architectural building blocks that compose the security box and the broader security architecture. Our response to NIST described these building blocks in greater detail. Here we provide a summary. AWS has implemented them in Amazon Bedrock AgentCore, a framework for building, deploying, and operating agentic AI systems with security built in from the ground up.

            Compute isolation. Agent compute environments must isolate execution, prevent cross-agent data leakage, and contain agents within defined boundaries. Amazon Bedrock AgentCore runs agents on Firecracker, an open source virtual machine manager written in Rust. Firecracker provides lightweight micro-VMs backed by Linux KVM and hardware-based virtualization, delivering the speed of containers with the isolation properties of full virtual machines. Key security-critical elements of Firecracker have been formally verified by AWS teams, adding assurance beyond the memory safety that Rust provides.

            Identity and access management. Agents require their own identities, secure credential storage, and least-privilege authorization enforced at the infrastructure level. AgentCore Identity provides machine identities for agents, manages OAuth and secure credential flows, and integrates with AWS Identity and Access Management (IAM) for fine-grained access control. It supports attribute-based access control and maintains traceable delegation chains so that the relationship between agent actions and the invoking user remains auditable.

            Tool access and policy enforcement. Every tool an agent can access expands both its usefulness and its potential risk. Managing tool access individually across agents creates an unmanageable combinatorial explosion. AgentCore Gateway acts as a centralized intermediary between agents and tools, enforcing authentication and authorization at a single control point. It can inspect tool calls down to individual parameters, not just at the API level. AgentCore Policy, built on the open source Cedar authorization language, adds formally verified policy enforcement. Teams can author Cedar policies in natural language and then review them, combining the flexibility of LLMs with the rigor of formal methods.

            Observability. Observability infrastructure must capture sufficient context for real-time monitoring and investigation, and it must be protected from the agents it monitors. Organizations wouldn’t allow employees to edit their own audit logs, and the same principle applies to agents. AgentCore provides observability through the AgentCore Gateway, session-level telemetry, and detailed traces that record internal state changes. These capabilities can extend to agents running outside of AgentCore as well.

            Model execution environment. The security of the model execution environment matters as much as the security of the agent itself. Amazon Bedrock runs models in isolated network environments where neither AWS nor model providers access customer prompts and responses. When customers enable logging, those logs are encrypted at rest and protected by customer-managed encryption keys. This architectural isolation is a key reason government and enterprise customers have adopted Amazon Bedrock.

            Deterministic external controls are complemented by controls within the AI processing loop. Amazon Bedrock Guardrails inspects prompts and responses using small AI models called classifiers that address challenges such as prompt injection. Automated Reasoning checks go further, so that developers can create a formal model of a knowledge domain and verify that LLM output conforms to it, producing results that are deterministic and provably correct.

            Looking ahead

            Agentic AI changes how software operates, but the security response builds on decades of established practice. Existing frameworks provide the right foundation. The task is to extend existing frameworks for agent-specific considerations. Organizations should apply secure development lifecycle practices to AI components and maintain traditional security controls. They should enforce security through deterministic controls external to the agent and earn greater autonomy through systematic evaluation.

            These principles aren’t theoretical. They reflect the operational experience AWS has gained building and operating agentic AI services. They’re embedded in how we design our infrastructure. As NIST develops guidance based on industry input, we will continue to invest in helping customers build and operate agentic AI systems with confidence.

            To learn more about how AWS helps customers secure their AI workloads, visit the AWS AI Security or read the Amazon response to the CAISI Request for Information regarding Security Considerations for Artificial Intelligence Agents.

            Mark Ryland

            Mark Ryland

            Mark is a director of the Office of the CISO for AWS. He has more than 30 years of experience in the technology industry and has served in leadership roles in cybersecurity, software engineering, distributed systems, technology standardization, and public policy. Prior to his current role, he served as the Director of Solution Architecture and Professional Services for the AWS World Public Sector team.

            Riggs Goodman III Riggs Goodman III
            Riggs is a Principal Solution Architect at AWS. His current focus is on AI security, providing technical guidance, architecture patterns, and leadership for customers and partners to build AI workloads on AWS. Internally, Riggs focuses on driving overall technical strategy and innovation across AWS service teams to address customer and partner challenges.
            Todd MacDermid Todd MacDermid
            Todd is a Principal Security Engineer in the Amazon AI Security Group. He has spent over 15 years at Amazon primarily working in AWS Security, and prior to Amazon spent 10 years working in red-team consulting and application and network security.

            New compliance guide available: ISO/IEC 27001:2022 on AWS

            31 March 2026 at 22:36

            We’re excited to announce the release of our latest compliance guide, ISO/IEC 27001:2022 on AWS, which provides practical guidance for organizations designing and operating an Information Security Management System (ISMS) using AWS services.

            As organizations migrate critical workloads to the cloud, aligning with globally recognized standards such as ISO/IEC 27001:2022 becomes an important step toward strengthening governance, risk management, and information security practices. This guide helps cloud architects, security teams, compliance leaders, and DevOps practitioners understand how to implement and operate ISO 27001-aligned controls using AWS services while applying the AWS Shared Responsibility Model.

            The guide explains how organizations can integrate AWS services into their ISMS to support the requirements defined in ISO 27001:2022 clauses 4–10 and selected Annex A controls. It also highlights how AWS security, monitoring, and automation capabilities can help customers maintain visibility, improve operational consistency, and prepare audit-ready evidence.

            While AWS provides a secure and compliant cloud infrastructure, customers remain responsible for defining their ISMS scope, implementing controls, and demonstrating conformity during certification audits.

            Inside the guide:

            • Overview of the ISO/IEC 27001:2022 framework, including ISMS clauses 4–10 and the Annex A control
            • Mapping of selected ISO 27001:2022 Annex A controls to AWS services and architectural capabilities
            • Guidance for implementing complementary customer controls within AWS environments
            • Recommendations for evidence collection, documentation, and audit readiness using AWS native tooling
            • Governance and risk management considerations for organizations establishing an ISMS on AWS
            • Best practices for operationalizing compliance activities through automation and infrastructure-as-code.

            By combining ISO 27001 best practices with AWS security services, organizations can build scalable environments that support continuous security improvement, operational visibility, and certification readiness.

            Download: ISO/IEC 27001:2022 on AWS Compliance Guide
            For further assistance, contact AWS Security Assurance Services

            If you have feedback about this post, please submit comments in the Comments section below.

            Ted Tanner

            Ted Tanner

            Ted is a Principal Assurance Consultant and PCI DSS QSA with AWS Security Assurance Services. He has more than 25 years of IT, security, and compliance experience, which he uses to advise customers on building and optimizing their cloud compliance programs. He is co-author of several PCI DSS–related publications at AWS.

            Satish Uppalapati

            Satish Uppalapati

            Satish is an Associate Assurance Consultant with AWS Security Assurance Services and has more than 8 years of experience in IT risk, governance, and regulatory assurance. He works with AWS customers to help align cloud environments with frameworks such as ISO 27001, SOC 2, and FFIEC. Satish also focuses on advancing governance for AI systems, including emerging standards such as ISO/IEC 42001.

            Viktor Mu

            Viktor Mu

            Viktor is a Senior Assurance Consultant with AWS Security Assurance Services and has more than a decade of experience specializing in security and compliance assessments. Viktor holds several industry-recognized audit and security certifications, including PCI QSA, and CISA. Viktor works with partners and customers handling security and compliance frameworks like SOC 2 in key market verticals and regulated industries.

            Lola Quadri

            Lola Quadri

            With more than ten years of experience across Big 4 consulting, financial services, and technology, Lola is a trusted security consultant specializing in risk and compliance. She leverages deep expertise across leading compliance frameworks to guide AWS customers toward sustainable, audit-ready compliance postures. Lola is a CISA, CISM, and AWS Certified Solutions Architect.

            IAM policy types: How and when to use them

            23 March 2026 at 21:13

            June 3, 2022: Original publication date of this post. This post has been updated to add the additional IAM policy types: Resource control policies.


            You manage access in AWS by creating policies and attaching them to AWS Identity and Access Management (IAM) principals (roles, users, or groups of users) or AWS resources. AWS evaluates these policies when an IAM principal makes a request, such as uploading an object to an Amazon Simple Storage Service (Amazon S3) bucket. Permissions in the policies determine whether the request is allowed or denied. While IAM operates primarily at the individual AWS account level, organizations with multiple AWS accounts can extend these access controls through AWS Organizations, which provides additional policy types that work alongside IAM to enforce governance and security standards across their entire organizational structure. By using AWS Organizations, you can group accounts in the multi-account environment into organizational units (OUs), apply policy-based controls across these groups.

            In this blog post, you will learn how to select the appropriate policy types for your security requirements and determine which team should own and manage each policy. You will explore seven policy types—including identity-based policies, resource-based policies, permissions boundaries, service control policies (SCPs), and resource control policies (RCPs)—through a practical scenario involving multiple AWS accounts and teams.

            Different policy types and when to use them

            AWS has different policy types that provide you with powerful flexibility, and it’s important to know how and when to use each policy type. It’s also important for you to understand how to structure your IAM policy ownership to avoid a centralized team from becoming a bottleneck. Explicit policy ownership can allow your teams to move more quickly, while staying within the secure guardrails that are defined centrally.

            Service control policies overview

            Service control policies (SCPs) are a feature of AWS Organizations. AWS Organizations is a service for grouping and centrally managing the AWS accounts that your business owns. SCPs are policies that specify the maximum permissions for an organization, organizational unit (OU), or an individual account. An SCP can limit permissions for principals in member accounts, including the AWS account root user.

            SCPs are meant to be used as coarse-grained guardrails, and they don’t directly grant access. The primary function of SCPs is to enforce security invariants across AWS accounts and OUs in an organization. Security invariants are control objectives or configurations that you apply to multiple accounts, OUs, or the whole organization managed by AWS Organizations. For example, you can use an SCP to prevent member accounts from leaving your organization or to enforce that AWS resources can only be deployed to certain AWS Regions.

            Resource control policies overview

            Resource control policies (RCPs) are an AWS Organizations feature to manage permissions centrally. RCPs set the maximum available permissions for resources across your organization. RCPs help ensure that resources in your accounts stay within your organization’s access control guidelines.

            RCPs are typically used to enforce data perimeter controls to prevent accidental data sharing outside your organization and to control resource sharing and cross-account access patterns centrally. You can also use RCPs to implement security controls for sensitive resources across your organization’s accounts and to add an additional layer of protection for resources such as S3 buckets that store confidential data.

            Note: SCPs are principal-centric controls that specify which services your IAM users and IAM roles can access, which resources they can access, or the conditions under which they can make requests (for example, from specific Regions or networks). On the other hand, RCPs are resource-centric controls that can restrict access to your resources so that they can be accessed only by identities that belong to your organization or specify the conditions under which identities external to your organization can access your resources. To understand SCPs and RCPs differences and use cases, see General use cases for SCPs and RCPs.

            Permissions boundaries overview

            Permissions boundaries are an advanced IAM feature in which you set the maximum permissions that an identity-based policy can grant to an IAM principal. When you set a permissions boundary for a principal, the principal can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

            A permissions boundary is a type of identity-based policy that doesn’t directly grant access. Instead, like an SCP, a permissions boundary acts as a guardrail for your IAM principals that allows you to set coarse-grained access controls. A permissions boundary is typically used to delegate the creation of IAM principals. Delegation enables other individuals in your accounts to create new IAM principals, but limits the permissions that can be granted to the new IAM principals.

            Identity-based policies overview

            Identity-based policies are policy documents that you attach to a principal (roles, users, and groups of users) to control what actions a principal can perform, on which resources, and under what conditions. Identity-based policies can be further categorized into AWS managed policies, customer managed policies, and inline policies. AWS managed policies are reusable identity-based policies that are created and managed by AWS. You can use AWS managed policies as a starting point for building your own identity-based policies that are specific to your organization. Customer managed policies are reusable identity-based policies that can be attached to multiple identities. Customer managed policies are useful when you have multiple principals with identical access requirements. Inline policies are identity-based policies that are attached to a single principal. Use inline-policies when you want to create least-privilege permissions that are specific to a particular principal.

            You will have many identity-based policies in your AWS account that are used to enable access in scenarios such as human access, application access, machine learning workloads, and deployment pipelines. These policies should be fine-grained. You use these policies to directly apply least privilege permissions to your IAM principals. You should write the policies with permissions for the specific task that the principal needs to accomplish.

            Resource-based policies overview

            Resource-based policies are policy documents that you attach to a resource such as an S3 bucket. These policies grant the specified principal permission to perform specific actions on that resource and define under what conditions this permission applies. Resource-based policies are inline policies. For a list of AWS services that support resource-based policies, see AWS services that work with IAM.

            Resource-based policies are optional for many workloads that don’t span multiple AWS accounts. Fine-grained access within a single AWS account is typically granted with identity-based policies. AWS Key Management Service (AWS KMS) keys and IAM role trust policies are two exceptions, and both of these resources must have a resource-based policy even when the principal and the KMS key or IAM role are in the same account. IAM roles and KMS keys behave this way as an extra layer of protection that requires the owner of the resource (key or role) to explicitly allow or deny principals from using the resource. For other resources that support resource-based policies, here are some examples where they are most commonly used:

            1. Granting cross-account access to your AWS resource.
            2. Granting an AWS service access to your resource when the AWS service uses an AWS service principal. For example, when using AWS CloudTrail, you must explicitly grant the CloudTrail service principal access to write files to an Amazon S3 bucket.
            3. Applying broad access guardrails to your AWS resources. You can see some examples in the blog post IAM makes it easier for you to manage permissions for AWS services accessing your resources.
            4. Applying an additional layer of protection for resources that store sensitive data, such as AWS Secrets Manager secrets or an S3 bucket with sensitive data. You can use a resource-based policy to deny access to IAM principals that shouldn’t have access to sensitive data, even if granted access by an identity-based policy. An explicit deny in an IAM policy always overrides an allow.

            How to implement different policy types

            In this section, we will walk you through an example of a design that includes all four of the policy types explained in this post.

            The example that follows shows an application that runs on an Amazon Elastic Compute Cloud (Amazon EC2) instance and needs to read from and write files to an S3 bucket in the same account. The application also reads (but doesn’t write) files from an S3 bucket in a different account. The company in this example, Example Corp, uses a multi-account strategy, and each application has its own AWS account. The architecture of the application is shown in Figure 1.

            Figure 1: Sample application architecture that needs to access S3 buckets in two different AWS accounts

            Figure 1: Sample application architecture that needs to access S3 buckets in two different AWS accounts

            There are three teams that participate in this example: the Central Cloud Team, the Application Team, and the Data Lake Team. The Central Cloud Team is responsible for the overall security and governance of the AWS environment across all AWS accounts at Example Corp. The Application Team is responsible for building, deploying, and running their application within the application account (111111111111) that they own and manage. Likewise, the Data Lake Team owns and manages the data lake account (222222222222) that hosts a data lake at Example Corp.

            With that background in mind, we will walk you through an implementation for each of the four policy types and include an explanation of which team we recommend own each policy. The policy owner is the team that is responsible for creating and maintaining the policy.

            Service control policies

            The Central Cloud Team owns the implementation of the security controls that should apply broadly to all of Example Corp’s AWS accounts. At Example Corp, the Central Cloud Team has two security requirements that they want to apply to all accounts in their organization:

            1. AWS API calls should be encrypted in transit to maintain security best practices
            2. Accounts can’t leave the organization on their own.

            The Central Cloud Team chooses to implement these security invariants using SCPs and applies the SCPs to the root of the organization. The first statement in Policy 1 denies all requests that are not sent using SSL (TLS). The second statement in Policy 1 prevents an account from leaving the organization.

            This is only a subset of the SCP statements that Example Corp uses. Example Corp uses a deny list strategy, and there must also be an accompanying statement with an Effect of Allow at every level of the organization that isn’t shown in the SCP in Policy 1.

            Policy 1: SCP attached to AWS Organizations organization root

            {
            		"Id": "ServiceControlPolicy",
            		"Version": "2012-10-17",
            		"Statement": [{
            			"Sid": "DenyIfRequestIsNotUsingSSL",
            			"Effect": "Deny",
            			"Action": "*",
            			"Resource": "*",
            			"Condition": {
            				"BoolIfExists": {
            					"aws:SecureTransport": "false"
            				}
            			}
            	},
            	{
            		"Sid": "PreventLeavingTheOrganization",
            		"Effect": "Deny",
            		"Action": "organizations:LeaveOrganization",
            		"Resource": "*"
            	}]
            }
            
            

            Resource control policies

            The Central Cloud Team also has three additional security requirements for Amazon S3 resource deployment to accounts.

            1. Require a minimum TLS version of 1.2 for S3 bucket access
            2. Mandate encryption of S3 objects using AWS Key Management Service (AWS KMS)
            3. Deny S3 access from AWS account outside the organization managed by AWS Organizations

            The Central Cloud Team attaches the RCPs to the root of the organization, following the same approach used for SCPs, so that the policy applies across all accounts.
            Policy 2 enforces three controls across S3 buckets in the organization. The first statement requires TLS 1.2 for data-in-transit. The second statement requires AWS KMS encryption for data-at-rest. The third statement restricts S3 bucket access to principals from accounts within the organization (identified by example-corp-organization-id), blocking access from external accounts.

            Policy 2: RCP attached to the organization root to enforce data perimeter

            {
              "Id": "ResourceControlPolicy",
              "Version": "2012-10-17",
              "Statement": [
                {
                  "Sid": "EnforceS3TLSVersion",
                  "Effect": "Deny",
                  "Principal": "*",
                  "Action": "s3:*",
                  "Resource": "*",
                  "Condition": {
                    "NumericLessThan": {
                      "s3:TlsVersion": [
                        "1.2"
                      ]
                    }
                  }
                },
                {
                  "Sid": "EnforceKMSEncryption",
                  "Effect": "Deny",
                  "Principal": "*",
                  "Action": "s3:PutObject",
                  "Resource": "*",
                  "Condition": {
                    "Null": {
                      "s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
                    }
                  }
                },
                {
                  "Sid": "DenyAllExternalS3Access",
                  "Effect": "Deny",
                  "Principal": "*",
                  "Action": "s3:*",
                  "Resource": "*",
                  "Condition": {
                    "StringNotEquals": {
                      "aws:PrincipalOrgID": "example-corp-organization-id"
                    }
                  }
                }
              ]
            }

            Permissions boundary policies

            The Central Cloud Team wants to make sure that they don’t become a bottleneck for the Application Team. They want to allow the Application Team to deploy their own IAM principals and policies for their applications. The Central Cloud Team also wants to make sure that any principals created by the Application Team can only use AWS APIs that the Central Cloud Team has approved.

            At Example Corp, the Application Team deploys to their production AWS environment through a continuous integration/continuous deployment (CI/CD) pipeline. The pipeline itself has broad access to create AWS resources needed to run applications, including permissions to create additional IAM roles. The Central Cloud Team implements a control that requires that all IAM roles created by the pipeline must have a permissions boundary attached. This allows the pipeline to create additional IAM roles, but limits the permissions that the newly created roles can have to what is allowed by the permissions boundary. This delegation strikes a balance for the Central Cloud Team. They can avoid becoming a bottleneck to the Application Team by allowing the Application Team to create their own IAM roles and policies, while ensuring that those IAM roles and policies are not overly privileged.

            An example of the permissions boundary policy that the Central Cloud Team attaches to IAM roles created by the CI/CD pipeline is shown below. This same permissions boundary policy can be centrally managed and attached to IAM roles created by other pipelines at Example Corp. The policy describes the maximum possible permissions that additional roles created by the Application Team are allowed to have, and it limits those permissions to some Amazon S3 and Amazon Simple Queue Service (Amazon SQS) data access actions. It’s common for a permissions boundary policy to include data access actions when used to delegate role creation. This is because most applications only need permissions to read and write data (for example, writing an object to an S3 bucket or reading a message from an SQS queue) and only sometimes need permission to modify infrastructure (for example, creating an S3 bucket or deleting an SQS queue). As Example Corp adopts additional AWS services, the Central Cloud Team updates this permissions boundary with actions from those services.

            Policy 3: Permissions boundary policy attached to IAM roles created by the CI/CD pipeline

            {
              "Id": "PermissionsBoundaryPolicy",
              "Version": "2012-10-17",
              "Statement": [
                {
                  "Effect": "Allow",
                  "Action": [
                    "s3:PutObject",
                    "s3:GetObject",
                    "sqs:ChangeMessageVisibility",
                    "sqs:DeleteMessage",
                    "sqs:ReceiveMessage",
                    "sqs:SendMessage",
                    "sqs:PurgeQueue",
                    "sqs:GetQueueUrl",
                    "logs:PutLogEvents"
                  ],
                  "Resource": "*"
                }
              ]
            }

            In the next section, you will learn how to enforce that this permissions boundary is attached to IAM roles created by your CI/CD pipeline.

            Identity-based policies

            In this example, teams at Example Corp are only allowed to modify the production AWS environment through their CI/CD pipeline. Write access to the production environment is not allowed otherwise. To support the different personas that need to have access to an application account in Example Corp, three baseline IAM roles with identity-based policies are created in the application accounts:

            • A role for the CI/CD pipeline to use to deploy application resources.
            • A read-only role for the Central Cloud Team, with a process for temporary elevated access.
            • A read-only role for members of the Application Team.

            All three of these baseline roles are owned, managed, and deployed by the Central Cloud Team.

            The Central Cloud Team is given a default read-only role (CentralCloudTeamReadonlyRole) that allows read access to all resources within the account. This is accomplished by attaching the AWS managed ReadOnlyAccess policy to the Central Cloud Team role. You can use the IAM console to attach the ReadOnlyAccess policy, which grants read-only access to all services. When a member of the team needs to perform an action that is not covered by this policy, they follow a temporary elevated access process to make sure that this access is valid and recorded.

            A read-only role is also given to developers in the Application Team (DeveloperReadOnlyRole) for analysis and troubleshooting. At Example Corp, developers are allowed to have read-only access to Amazon EC2, Amazon S3, Amazon SQS, AWS CloudFormation, and Amazon CloudWatch. Your requirements for read-only access might differ. Several AWS services offer their own read-only managed policies, and there is also the previously mentioned AWS managed ReadOnlyAccess policy that grants read only access to all services. To customize read-only access in an identity-based policy, you can use the AWS managed policies as a starting point and limit the actions to the services that your organization uses. The customized identity-based policy for Example Corp’s DeveloperReadOnlyRole role is shown below.

            Policy 4: Identity-based policy attached to a developer read-only role to support human access and troubleshooting

            {
              "Id": "DeveloperRoleBaselinePolicy",
              "Version": "2012-10-17",
              "Statement": [
                {
                  "Effect": "Allow",
                  "Action": [
                    "cloudformation:Describe*",
                    "cloudformation:Get*",
                    "cloudformation:List*",
                    "cloudwatch:Describe*",
                    "cloudwatch:Get*",
                    "cloudwatch:List*",
                    "ec2:Describe*",
                    "ec2:Get*",
                    "ec2:List*",
                    "ec2:Search*",
                    "s3:Describe*",
                    "s3:Get*",
                    "s3:List*",
                    "sqs:Get*",
                    "sqs:List*",
                    "logs:Describe*",
                    "logs:FilterLogEvents",
                    "logs:Get*",
                    "logs:List*",
                    "logs:StartQuery",
                    "logs:StopQuery"
                  ],
                  "Resource": "*"
                }
              ]
            }

            The CI/CD pipeline role has broad access to the account to create resources. Access to deploy through the CI/CD pipeline should be tightly controlled and monitored. The CI/CD pipeline is allowed to create new IAM roles for use with the application, but those roles are limited to only the actions allowed by the previously discussed permissions boundary. The roles, policies, and EC2 instance profiles that the pipeline creates should also be restricted to specific role paths. This enables you to enforce that the pipeline can only modify roles and policies or pass roles that it has created. This helps prevent the pipeline, and roles created by the pipeline, from elevating privileges by modifying or passing a more privileged role. Pay careful attention to the role and policy paths in the Resource element of the following CI/CD pipeline role policy (Policy 5). The CI/CD pipeline role policy also provides some example statements that allow the passing and creation of a limited set of service-linked roles (which are created in the path /aws-service-role/). You can add other service-linked roles to these statements as your organization adopts additional AWS services.

            Policy 5: Identity-based policy attached to CI/CD pipeline role

            {
              "Id": "CICDPipelineBaselinePolicy",
              "Version": "2012-10-17",
              "Statement": [
                {
                  "Effect": "Allow",
                  "Action": [
                    "ec2:*",
                    "sqs:*",
                    "s3:*",
                    "cloudwatch:*",
                    "cloudformation:*",
                    "logs:*",
                    "autoscaling:*"
                  ],
                  "Resource": "*"
                },
                {
                  "Effect": "Allow",
                  "Action": "ssm:GetParameter*",
                  "Resource": "arn:aws:ssm:*::parameter/aws/service/*"
                },
                {
                  "Effect": "Allow",
                  "Action": [
                    "iam:CreateRole",
                    "iam:PutRolePolicy",
                    "iam:DeleteRolePolicy"
                  ],
                  "Resource": "arn:aws:iam::111111111111:role/application-roles/*",
                  "Condition": {
                    "ArnEquals": {
                      "iam:PermissionsBoundary": "arn:aws:iam::111111111111:policy/PermissionsBoundary"
                    }
                  }
                },
                {
                  "Effect": "Allow",
                  "Action": [
                    "iam:AttachRolePolicy",
                    "iam:DetachRolePolicy"
                  ],
                  "Resource": "arn:aws:iam::111111111111:role/application-roles/*",
                  "Condition": {
                    "ArnEquals": {
                      "iam:PermissionsBoundary": "arn:aws:iam::111111111111:policy/PermissionsBoundary"
                    },
                    "ArnLike": {
                      "iam:PolicyARN": "arn:aws:iam::111111111111:policy/application-role-policies/*"
                    }
                  }
                },
                {
                  "Effect": "Allow",
                  "Action": [
                    "iam:DeleteRole",
                    "iam:TagRole",
                    "iam:UntagRole",
                    "iam:GetRole",
                    "iam:GetRolePolicy"
                  ],
                  "Resource": "arn:aws:iam::111111111111:role/application-roles/*"
                },
                {
                  "Effect": "Allow",
                  "Action": [
                    "iam:CreatePolicy",
                    "iam:DeletePolicy",
                    "iam:CreatePolicyVersion",
                    "iam:DeletePolicyVersion",
                    "iam:GetPolicy",
                    "iam:TagPolicy",
                    "iam:UntagPolicy",
                    "iam:SetDefaultPolicyVersion",
                    "iam:ListPolicyVersions"
                  ],
                  "Resource": "arn:aws:iam::111111111111:policy/application-role-policies/*"
                },
                {
                  "Effect": "Allow",
                  "Action": [
                    "iam:CreateInstanceProfile",
                    "iam:AddRoleToInstanceProfile",
                    "iam:RemoveRoleFromInstanceProfile",
                    "iam:DeleteInstanceProfile"
                  ],
                  "Resource": "arn:aws:iam::111111111111:instance-profile/application-instance-profiles/*"
                },
                {
                  "Effect": "Allow",
                  "Action": "iam:PassRole",
                  "Resource": [
                    "arn:aws:iam::111111111111:role/application-roles/*",
                    "arn:aws:iam::111111111111:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling*"
                  ]
                },
                {
                  "Effect": "Allow",
                  "Action": "iam:CreateServiceLinkedRole",
                  "Resource": "arn:aws:iam::111111111111:role/aws-service-role/*",
                  "Condition": {
                    "StringEquals": {
                      "iam:AWSServiceName": "autoscaling.amazonaws.com"
                    }
                  }
                },
                {
                  "Effect": "Allow",
                  "Action": [
                    "iam:DeleteServiceLinkedRole",
                    "iam:GetServiceLinkedRoleDeletionStatus"
                  ],
                  "Resource": "arn:aws:iam::111111111111:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling*"
                },
                {
                  "Effect": "Allow",
                  "Action": "iam:ListRoles",
                  "Resource": "*"
                },
                {
                  "Effect": "Allow",
                  "Action": "iam:GetRole",
                  "Resource": [
                    "arn:aws:iam::111111111111:role/application-roles/*",
                    "arn:aws:iam::111111111111:role/aws-service-role/*"
                  ]
                }
              ]
            }

            In addition to the three baseline roles with identity-based policies in place that you’ve seen so far, there’s one additional IAM role that the Application Team creates using the CI/CD pipeline. This is the role that the application running on the EC2 instance will use to get and put objects from the S3 buckets in Figure 1. Explicit ownership allows the Application Team to create this identity-based policy that fits their needs without having to wait and depend on the Central Cloud Team. Because the CI/CD pipeline can only create roles that have the permissions boundary policy attached, Policy 6 cannot grant more access than the permissions boundary policy allows (Policy 3).

            If you compare the identity-based policy attached to the EC2 instance’s role (Policy 6 on left) with the permissions boundary policy described previously (Policy 3 on the right), you can see that the actions allowed by the EC2 instance’s role are also allowed by the permissions boundary policy. Actions must be allowed by both policies for the EC2 instance to perform the s3:GetObject and s3:PutObject actions. Access to create a bucket would be denied even if the role attached to the EC2 instance was given permission to perform the s3:CreateBucket action because the s3:CreateBucket action exceeds the permissions allowed by the permissions boundary.

            Policy 6: Identity-based policy bound by permissions boundary and attached to the application’s EC2 instance

            {
              "Id": "ApplicationRolePolicy",
              "Version": "2012-10-17",
              "Statement": [
            	{   
                  "Effect": "Allow",    
                  "Action": [
                     "s3:PutObject",
                     "s3:GetObject"
                ],    
                "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*"
              },
            {   
                  "Effect": "Allow",    
                  "Action": [
                     "s3:GetObject"
                  ],    
                  "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET2/*"
                }
              ]
            }

            Policy 3: Permissions boundary policy attached to IAM roles created by the CI/CD pipeline.

            {
              "Id": "PermissionsBoundaryPolicy",
              "Version": "2012-10-17",
              "Statement": [
                {
                  "Effect": "Allow",
                  "Action": [
                    "s3:PutObject",
                    "s3:GetObject",
                    "sqs:ChangeMessageVisibility",
                    "sqs:DeleteMessage",
                    "sqs:ReceiveMessage",
                    "sqs:SendMessage",
                    "sqs:PurgeQueue",
                    "sqs:GetQueueUrl",
                    "logs:PutLogEvents"
                  ],
                  "Resource": "*"
                }
              ]
            }

            Resource-based policies
            The only resource-based policy needed in this example is attached to the bucket in the account external to the application account (DOC-EXAMPLE-BUCKET2 in the data lake account in Figure 1). Both the identity-based policy and resource-based policy must grant access to an action on the S3 bucket for access to be allowed in a cross-account scenario. The bucket policy below only allows the GetObject action to be performed on the bucket, regardless of what permissions the application’s role (ApplicationRole) is granted from its identity-based policy (Policy 6).

            This resource-based policy is owned by the Data Lake Team that owns and manages the data lake account (222222222222) and the policy (Policy 7). This allows the Data Lake Team to have complete control over what teams external to their AWS account can access their S3 bucket.

            Policy 7: Resource-based policy attached to S3 bucket in external data lake account (222222222222)

            {
              "Version": "2012-10-17",
              "Statement": [
                {
                  "Principal": {
                    "AWS": "arn:aws:iam::111111111111:role/application-roles/ApplicationRole"
                  },
                  "Effect": "Allow",
                  "Action": [
                    "s3:GetObject"
                  ],
                  "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET2/*"
                }
              ]
            }

            No resource-based policy is needed on the S3 bucket in the application account (DOC-EXAMPLE-BUCKET1 in Figure 1). Access for the application is granted to the S3 bucket in the application account by the identity-based policy. Access can be granted by either an identity-based policy or a resource-based policy when access is within the same AWS account.

            Putting it all together

            Figure 2 shows the architecture and includes the different policies and the resources they are attached to. The table that follows summarizes the various IAM policies that are deployed to the Example Corp AWS environment, and specifies what team is responsible for each of the policies.

            Figure 2: Sample application architecture with CI/CD pipeline used to deploy infrastructure

            Figure 2: Sample application architecture with CI/CD pipeline used to deploy infrastructure

            The numbered policies in Figure 2 correspond to the policy numbers in the following table.

            Policy number

            Policy description

            Policy type

            Policy owner

            Attached to

            1

            Enforce SSL and prevent member accounts from leaving the organization for all principals in the organization

            Service control policy (SCP)

            Central Cloud Team

            Organization root

            2

            Enforce TLS 1.2 and KMS encryption for S3 buckets across the organization

            Resource control policy (RCP)

            Central Cloud Team

            Organization root

            3

            Restrict maximum permissions for roles created by CI/CD pipeline

            Permissions boundary

            Central Cloud Team

            All roles created by the pipeline (ApplicationRole)

            4

            Scoped read-only policy

            Identity-based policy

            Central Cloud Team

            IAM role

            5

            CI/CD pipeline policy

            Identity-based policy

            Central Cloud Team

            IAM role

            6

            Policy used by running application to read and write to S3 buckets

            Identity-based policy

            Application Team

            on EC2 instance

            7

            Bucket policy in data lake account that grants access to a role in application account

            Resource-based policy

            Data Lake Team

            S3 Bucket in data lake account

            8

            Broad read-only policy

            Identity-based policy

            Central Cloud Team

            IAM role

            Conclusion
            In this blog post, you learned about four different policy types: identity-based policies, resource-based policies, service control policies (SCPs), resource control polices (RCPs), permissions boundary policies, and resource control policies. You saw examples of situations where each policy type is commonly applied. Then, you walked through a real-life example that describes an implementation that uses these policy types.

            By implementing multiple IAM policy types in a layered approach, you can achieve robust access control that follows the principle of least privilege while enabling team autonomy. This defense-in-depth strategy helps prevent unauthorized access through multiple policy evaluation checkpoints.

            You can use this blog post as a starting point for developing your organization’s IAM strategy. You might decide that you don’t need all of the policy types explained in this post, and that’s OK. Not every organization needs to use every policy type. You might need to implement policies differently in a production environment than a sandbox environment. The important concepts to take away from this post are the situations where each policy type is applicable, and the importance of explicit policy ownership. We also recommend taking advantage of policy validation in AWS IAM Access Analyzer when writing IAM policies to validate your policies against IAM policy grammar and best practices.

            For more information, including the policies described in this solution and the sample application, see the how-and-when-to-use-aws-iam-policy-blog-samples GitHub repository. The repository walks through an example implementation using a CI/CD pipeline with AWS CodePipeline.If you have any questions, please post them in the AWS Identity and Access Management re:Post topic or reach out to AWS Support.

            Author

            Matt Luttrell

            Matt is a Sr. Solutions Architect on the AWS Identity Solutions team. When he’s not spending time chasing his kids around, he enjoys skiing, cycling, and the occasional video game.

            Author

            Jay Goradia

            Jay is a Technical Account Manager (TAM) at AWS who works closely with enterprise customers to accelerate their cloud journey through strategic guidance and technical expertise. Using his security background, he helps organizations understand security best practices in AWS.

            Author

            Anshu Bathla

            Anshu is a Lead Consultant – SRC at AWS, based in Gurugram, India. He works with customers across diverse verticals to help strengthen their security infrastructure and achieve their security goals. Outside of work, Anshu enjoys reading books and gardening at his home garden.

            Josh Joy

            Josh is a Senior Identity Security Engineer with AWS Identity helping to ensure the safety and security of AWS Auth integration points. Josh enjoys diving deep and working backwards in order to help customers achieve positive outcomes. 

            Amazon threat intelligence teams identify Interlock ransomware campaign targeting enterprise firewalls

            18 March 2026 at 16:57

            Amazon threat intelligence has identified an active Interlock ransomware campaign exploiting CVE-2026-20131, a critical vulnerability in Cisco Secure Firewall Management Center (FMC) Software that could allow an unauthenticated, remote attacker to execute arbitrary Java code as root on an affected device, which was disclosed by Cisco on March 4, 2026.

            After Cisco’s disclosure, Amazon threat intelligence began research into this vulnerability using Amazon MadPot’s global sensor network—a system of honeypot servers that attract and monitor cybercriminal activity. While looking for any current or past exploits of this vulnerability, our research found that Interlock was exploiting this vulnerability 36 days before its public disclosure, beginning January 26, 2026. This wasn’t just another vulnerability exploit, Interlock had a zero-day in their hands, giving them a week’s head start to compromise organizations before defenders even knew to look. Upon making this discovery, we shared our findings with Cisco to help support their investigation and protect customers.

            A misconfigured infrastructure server—essentially, a poorly secured staging area used by the attackers—exposed Interlock’s complete operational toolkit. This rare mistake provided Amazon’s security teams with visibility into the ransomware group’s multi-stage attack chain, custom remote access trojans (backdoor programs that give attackers control of compromised systems), reconnaissance scripts (automated tools for mapping victim networks), and evasion techniques.

            AWS infrastructure and customer workloads on AWS were not observed to be involved in this campaign. This advisory shares comprehensive technical analysis and indicators of compromise to help organizations identify potential compromise and defend against Interlock’s operations. Organizations running Cisco Secure Firewall Management Center should immediately apply Cisco’s security patches and review the indicators provided below.

            Discovery and investigation timeline

            Amazon threat intelligence identified threat activity potentially related to CVE-2026-20131 beginning January 26, 2026, predating the public disclosure. Observed activity involved HTTP requests to a specific path in the affected software. Request bodies contained Java code execution attempts and two embedded URLs: one used to deliver configuration data supporting the exploit, and another designed to confirm successful exploitation by causing a vulnerable target to perform an HTTP PUT request and upload a generated file. Multiple variations of these URLs were observed across different exploit attempts.

            To advance the investigation and obtain additional threat intelligence, we performed the expected HTTP PUT request with the anticipated file content—essentially, we pretended to be a successfully compromised system. This successfully prompted Interlock to proceed to the next stage, issuing commands to fetch and execute a malicious ELF binary (a Linux executable file) from a remote server.

            When analysts retrieved the binary, they discovered the same host (attacker-controlled server) is used for distributing Interlock’s entire operational toolkit. The exposed infrastructure organized artifacts into separate paths corresponding to individual targets, with the same paths used for both downloading tools to compromised hosts and uploading operational artifacts back to the staging server.

            Attribution to Interlock ransomware

            The ELF binary and associated artifacts are attributable to the Interlock ransomware family based on convergent technical and operational indicators. The embedded ransom note and TOR negotiation portal are consistent with Interlock’s established branding and infrastructure. The ransom note’s invocation of multiple data protection regulations reflects Interlock’s documented practice of citing regulatory exposure to pressure victims, essentially threatening organizations not just with data encryption, but with regulatory fines and compliance violations. The campaign-specific organization identifier embedded in the note aligns with Interlock’s per-victim tracking model.

            Interlock has historically targeted specific sectors where operational disruption creates maximum pressure for payment. Education represents the largest share of their activity, followed by engineering, architecture, and construction firms, manufacturing and industrial organizations, healthcare providers, and government and public sector entities.

            Temporal analysis performed on timestamps from observed threat activities, artifacts stored on the misconfigured infrastructure server, and metadata embedded within recovered threat artifacts indicates the actor most likely operates in UTC+3 with 75–80% confidence. Systematic analysis across all UTC offsets showed UTC+3 produced the best fit: first activity around 08:30, peak activity between 12:00 and 18:00, and a probable sleep window of 00:30–08:30.

            Interlock ransomware negotiation portal where victims enter their organization ID and email address to receive an auth token to begin a negotiation chat session.

            Figure 1: Interlock ransomware negotiation portal where victims enter their organization ID and email address to receive an auth token to begin a negotiation chat session.

            Technical analysis: Interlock’s operational toolkit

            Post-compromise reconnaissance script

            Once Interlock gains initial access, they use a variety of priority tools to complete their attack. Amazon threat intelligence teams recovered a PowerShell script designed for systematic Windows environment enumeration (automated information gathering about the victim’s network). The script collects operating system and hardware details, running services, installed software, storage configuration, Hyper-V virtual machine inventory, user file listings across Desktop, Documents, and Downloads directories, browser artifacts from Chrome, Edge, Firefox, Internet Explorer, and 360 browser (including history, bookmarks, stored credentials, and extensions), active network connections correlated with responsible processes, ARP tables, iSCSI session data, and RDP authentication events from Windows event logs.

            The script stages results to a centralized network share (\JK-DC2\Temp) using each system’s fully qualified hostname to create dedicated directories—essentially creating a folder for each compromised computer. Following collection, it compresses data into ZIP archives named after each hostname and removes original raw data. This structured per-host output format indicates the script operates across multiple machines within a network—a hallmark of ransomware intrusion chains that prepare for organization-wide encryption.

            Custom remote access trojans

            Remote access trojans (RATs) are malicious programs that give attackers persistent control over compromised systems, functioning like unauthorized remote desktop software.

            JavaScript implant: Amazon threat intelligence recovered an obfuscated JavaScript remote access trojan that suppresses debugging output by overriding browser console methods (hiding its activity from basic detection tools). On execution, it profiles the infected host using PowerShell and Windows Management Instrumentation (WMI), collecting system identity, domain membership, username, OS version, and privilege context before transmitting this data during an encrypted initialization handshake.

            Command-and-control communication occurs over persistent WebSocket connections with RC4-encrypted messages using per-message 16-byte random keys embedded in packet headers—essentially, each message uses a different encryption key, making interception more difficult. The implant cycles through multiple operator-controlled hostnames and IP addresses in randomized order with exponential backoff between reconnection attempts.

            The implant provides interactive shell access, arbitrary command execution, bidirectional file transfer, and SOCKS5 proxy capability for tunneling TCP traffic (routing malicious traffic through other systems to hide its origin). Self-update and self-delete capabilities allow operators to replace or remove the implant without reinfection, supporting operational cleanup to hinder forensic investigation.

            Java implant: A functionally equivalent client implemented in Java provides identical command-and-control capabilities. Built on GlassFish ecosystem libraries, it uses Grizzly for non-blocking I/O transport and Tyrus for WebSocket protocol communication. In simpler terms, Interlock built the same backdoor in two different programming languages, ensuring they maintain access even if defenders detect one version.

            Infrastructure laundering script

            Sophisticated threat actors don’t attack from their own infrastructure, they build disposable relay networks to hide their tracks. Amazon threat intelligence teams identified a Bash script that configures Linux servers as HTTP reverse proxies (intermediary servers that forward traffic to hide the attacker’s true location). The script performs system updates, installs fail2ban with SSH brute-force protection, and compiles HAProxy 3.1.2 from source. The HAProxy instance listens on port 80 and forwards all inbound HTTP traffic to a hardcoded target IP, with systemd ensuring persistence across reboots.

            A notable component is a log erasure routine running as a cron job every five minutes. The routine truncates all *.log files under /var/log and suppresses shell history by unsetting the HISTFILE variable. This aggressive evidence destruction, wiping logs every five minutes, combined with the purpose-built HTTP forwarding proxy, indicates the script establishes disposable traffic-laundering relay nodes. These nodes obscure exploit traffic origin, relay command-and-control communications, or proxy data exfiltration, making it nearly impossible to trace attacks back to their source.

            Memory-resident webshell

            Amazon threat intelligence teams observed a Java class file delivered as an alternative to the ELF binary drop. When loaded by the Java Virtual Machine (JVM), its static initializer registers a ServletRequestListener with the server’s StandardContext, essentially installing a persistent memory-resident backdoor that intercepts HTTP requests without writing files to disk. This “fileless” approach evades traditional antivirus scanning that looks for malicious files.

            The listener inspects incoming requests for specially crafted parameters containing encrypted command payloads. Payloads are decrypted using AES-128 with a key derived from the MD5 hash of the hardcoded seed “geckoformboundary99fec155ea301140cbe26faf55ed2f40″ (using the first 16 characters: 09b1a8422e8faed0). Decrypted payloads are treated as compiled Java bytecode, dynamically loaded into the JVM, and executed—a technique designed to evade file-based detection by running malicious code entirely in memory.

            Connectivity verification tool

            Amazon threat intelligence teams recovered Java class files implementing a basic TCP server listening on port 45588 (encoded as Unicode character 넔 to obscure the port number from static analysis). The server accepts connections, logs connecting IP addresses, sends a greeting message, and immediately closes connections. This operational profile is consistent with a lightweight network beacon—essentially a “phone home” tool used to verify successful code execution or confirm network port reachability following initial exploitation.

            Legitimate tool abuse

            Interlock deployed ConnectWise ScreenConnect, a legitimate commercial remote desktop tool, alongside custom implants. When ransomware operators deploy legitimate remote access tools alongside their custom malware, they’re buying insurance—if defenders find and remove one backdoor, they still have another way in. This indicates multiple redundant remote access mechanisms—a pattern consistent with ransomware operators seeking to maintain access even if individual footholds are removed. The tool’s legitimate network footprint helps blend with authorized remote administration traffic, making detection more challenging.

            Amazon threat intelligence teams also recovered Volatility, an open-source memory forensics framework typically used by incident responders (the same tool defenders use to investigate attacks). While no artifacts indicated automated use, its presence alongside custom implants and reconnaissance scripts is consistent with advanced threat operations. Both ransomware groups and nation-state actors have been observed deploying Volatility during intrusions. The tool’s focus on parsing memory dumps provides access to sensitive data such as credentials stored in RAM, which can enable lateral movement (spreading through the network) and deeper environment compromise in support of ransom operations or espionage objectives.

            Interlock also used Certify, an open source offensive security tool designed to exploit misconfigurations in Active Directory Certificate Services (AD CS). For ransomware operators, Certify provides a pathway to identify vulnerable certificate templates and enrollment permissions that allow requesting authentication-capable certificates. These certificates can be used to impersonate users, escalate privileges, or maintain persistent access. These capabilities directly support both initial compromise and long-term persistence objectives in ransomware operations.

            Indicators of compromise (IoCs)

            The following indicators support defensive measures by organizations that may be affected. Due to Interlock’s use of content variation techniques, most file hashes are not included as reliable indicators. The threat actor modified most artifacts like scripts and binaries downloaded to different targets. This resulted in different file hashes for functionally identical tools. The customization allowed each attack to evade signature-based detection that looks for exact file matches.

            206.251.239[.]164

            Exploit source IP

            Active Jan 2026

            199.217.98[.]153

            Exploit source IP

            Active Mar 2026

            89.46.237[.]33

            Exploit source IP

            Active Mar 2026

            Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0

            Exploit HTTP User-Agent

            Observed Jan 2026 and Mar 2026

            b885946e72ad51dca6c70abc2f773506

            Exploit TLS JA3

            Observed Jan 2026 and Mar 2026

            f80d3d09f61892c5846c854dd84ac403

            Exploit TLS JA3

            Observed Mar 2026

            t13i1811h1_85036bcba153_b26ce05bbdd6

            Exploit TLS JA4

            Observed Jan 2026 and Mar 2026

            t13i4311h1_c7886603b240_b26ce05bbdd6

            Exploit TLS JA4

            Observed Mar 2026

            144.172.94[.]59

            C2 Fallback IP

            Active Mar 2026

            199.217.99[.]121

            C2 Fallback IP

            Active Mar 2026

            188.245.41[.]78

            C2 Fallback IP

            Active Mar 2026

            144.172.110[.]106

            Backend C2 IP

            Active Mar 2026

            95.217.22[.]175

            Backend C2 IP

            Active Mar 2026

            37.27.244[.]222

            Staging host IP

            Active Mar 2026

            hxxp://ebhmkoohccl45qesdbvrjqtyro2hmhkmh6vkyfyjjzfllm3ix72aqaid[.]onion/chat.php

            Ransom negotiation portal

            Active Mar 2026

            cherryberry[.]click

            Exploit Support Domain

            Active Jan 2026

            ms-server-default[.]com

            Exploit Support Domain

            Active Mar 2026

            initialize-configs[.]com

            Exploit Support Domain

            Active Mar 2026

            ms-global.first-update-server[.]com

            Exploit Support Domain

            Active Mar 2026

            ms-sql-auth[.]com

            Exploit Support Domain

            Active Mar 2026

            kolonialeru[.]com

            Exploit Support Domain

            Active Mar 2026

            sclair.it[.]com

            Exploit Support Domain

            Active Mar 2026

            browser-updater[.]com

            C2 domain

            Active Mar 2026

            browser-updater[.]live

            C2 domain

            Active Mar 2026

            os-update-server[.]com

            C2 domain

            Active Mar 2026

            os-update-server[.]org

            C2 domain

            Active Mar 2026

            os-update-server[.]live

            C2 domain

            Active Mar 2026

            os-update-server[.]top

            C2 domain

            Active Mar 2026

            d1caa376cb45b6a1eb3a45c5633c5ef75f7466b8601ed72c8022a8b3f6c1f3be

            Offensive security tool (Certify)

            Observed Mar 2026

            6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f

            Screen locker

            Observed Mar 2026

            Defensive recommendations

            Organizations should take the following actions to protect against Interlock ransomware operations.

            Immediate actions:

            • Apply Cisco’s security patches for Cisco Secure Firewall Management Center
            • Review logs for the indicators of compromise listed above
            • Conduct security assessments to identify potential compromise
            • Review ScreenConnect deployments for unauthorized installations

            Detection opportunities:

            • Monitor for PowerShell scripts staging data to network shares with hostname-based directory structures
            • Detect Java ServletRequestListener registrations in web application contexts (unusual modifications to Java web applications)
            • Identify HAProxy installations with aggressive log deletion cron jobs (proxy servers that erase their own logs every five minutes)
            • Watch for TCP connections to unusual high-numbered ports (e.g., 45588)

            Long-term measures:

            • Implement defense-in-depth strategies with multiple layers of security controls
            • Maintain continuous threat monitoring and hunting capabilities
            • Ensure comprehensive logging with secure, centralized log storage (stored separately from systems that could be compromised)
            • Regularly test incident response procedures for ransomware scenarios
            • Educate security teams on Interlock’s tactics, techniques, and procedures

            The real story here isn’t just about one vulnerability or one ransomware group—it’s about the fundamental challenge zero-day exploits pose to every security model. When attackers exploit vulnerabilities before patches exist, even the most diligent patching programs can’t protect you in that critical window. This is precisely why defense in depth is essential—layered security controls provide protection when any single control fails or hasn’t yet been deployed. Rapid patching remains foundational in vulnerability management, but defense in depth helps organizations not to be defenseless during the window between exploit and patch.

            Amazon Threat Intelligence teams continue to monitor Interlock ransomware operations and will provide updates as additional information becomes available. The intelligence gathered from this campaign is being integrated into AWS security services to protect customers proactively.


            If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

            CJ Moses

            CJ Moses

            CJ Moses is the CISO of Amazon Integrated Security. In his role, CJ leads security engineering and operations across Amazon. His mission is to enable Amazon businesses by making the benefits of security the path of least resistance. CJ joined Amazon in December 2007, holding various roles including Consumer CISO, and most recently AWS CISO, before becoming CISO of Amazon Integrated Security September of 2023.

            Prior to joining Amazon, CJ led the technical analysis of computer and network intrusion efforts at the Federal Bureau of Investigation’s Cyber Division. CJ also served as a Special Agent with the Air Force Office of Special Investigations (AFOSI). CJ led several computer intrusion investigations seen as foundational to the security industry today.

            CJ holds degrees in Computer Science and Criminal Justice, and is an active SRO GT America GT2 race car driver.

            ❌