NVIDIA Spectrum-X MRC is the Custom RDMA Transport Protocol for Gigascale AI

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/nvidia-spectrum-x-mrc-is-the-custom-rdma-transport-protocol-for-gigascale-ai/

NVIDIA is talking about is Spectrum-X MRC, a custom RDMA transport protocol already powering frontier gigascale AI deployments

The post NVIDIA Spectrum-X MRC is the Custom RDMA Transport Protocol for Gigascale AI appeared first on ServeTheHome.

Rowhammer Attack Against NVIDIA Chips

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/05/rowhammer-attack-against-nvidia-chips.html

A new rowhammer attack gives complete control of NVIDIA CPUs.

On Thursday, two research teams, working independently of each other, demonstrated attacks against two cards from Nvidia’s Ampere generation that take GPU rowhammering into new—­and potentially much more consequential—­territory: GDDR bitflips that give adversaries full control of CPU memory, resulting in full system compromise of the host machine. For the attack to work, IOMMU memory management must be disabled, as is the default in BIOS settings.

“Our work shows that Rowhammer, which is well-studied on CPUs, is a serious threat on GPUs as well,” said Andrew Kwong, co-author of one of the papers. “GDDRHammer: Greatly Disturbing DRAM Rows­Cross-Component Rowhammer Attacks from Modern GPUs.” “With our work, we… show how an attacker can induce bit flips on the GPU to gain arbitrary read/write access to all of the CPU’s memory, resulting in complete compromise of the machine.”

Update Friday, April 3: On Friday, researchers unveiled a third Rowhammer attack that also demonstrates Rowhammer attacks on the RTX A6000 that achieves privilege escalation to a root shell. Unlike the previous two, the researchers said, it works even when IOMMU is enabled.

The second paper is GeForge: Hammering GDDR Memory to Forge GPU Page Tables for Fun and Profit:

…does largely the same thing, except that instead of exploiting the last-level page table, as GDDRHammer does, it manipulates the last-level page directory. It was able to induce 1,171 bitflips against the RTX 3060 and 202 bitflips against the RTX 6000.

GeForge, too, uses novel hammering patterns and memory massaging to corrupt GPU page table mappings in GDDR6 memory to acquire read and write access to the GPU memory space. From there, it acquires the same privileges over host CPU memory. The GeForge proof-of-concept exploit against the RTX 3060 concludes by opening a root shell window that allows the attacker to issue commands that run unfettered privileges on the host machine. The researchers said that both GDDRHammer and GeForge could do the same thing against the RTC 6000.

Zabbix and the Docker API, Part 3: Control

Post Syndicated from Janis Eidaks original https://blog.zabbix.com/zabbix-and-the-docker-api-part-3-control/32961/

In this blog post, you will learn how to add a simple container remote control capability to Zabbix in order to start, stop, or restart containers from within the discovered host.

You might be wondering, why spend the effort to create a host for each template? Well, that’s because we define a manual script to control the container from within the Zabbix frontend. That’s neat, right?  And why stop there? We can also implement a trigger action that automatically restarts the container if it crashes for any reason.

Zabbix server configuration changes

First, we will require global script execution in your Zabbix server configuration:

# nano /etc/zabbix/zabbix_server.conf
EnableGlobalScripts=1
# systemctl restart zabbix-server

Script configuration in frontend

We can create a script in the section Alerts > Scripts. In the script, fill out the specified parameters shown below – the scope, type, and command. Then specify to which hosts this command will apply, as well as the user group that will be able to execute this. This script will take advantage of the user macros and built-in macros to fill the required info in the command to make a correct post request.

● Script
▪ Name: Container action
▪ Scope : Manual host action
▪ Type: Script
▪ Execute on: Zabbix server
▪ Commands: curl -sS -X POST https://{$DOCKER.IP}:{$DOCKER.PORT}/containers{HOST.NAME}/{MANUALINPUT} --cert /etc/zabbix/ssl/certs/client-cert.pem --key /etc/zabbix/ssl/keys/client-key.pem --cacert /etc/zabbix/ssl/ca/ca.pem
▪ Description: Manual action to restart,stop,start container
▪ Host group: Selected: Docker
▪ User group: Zabbix administrators 
▪ Req host perm: Write

● Advanced configuration
▪ Enable user input Check
▪ Input prompt Specify action for container {HOST.NAME}:
▪ Input type: Dropdown 
▪ Dropdown options: restart,stop,start
▪ Enable Confirmation: Check
▪ Confirmation text: Confirm to {MANUALINPUT} container: {HOST.NAME}

Fig 1. The script configuration

Manual host script execution

We can go the Menu section Monitoring > Hosts, select the host, and click on it. In the menu, you will have an additional script available for the Docker hosts group Container action. This manual action is also available in some other frontend sections.

Fig 2. The available scripts for manual execution on the host

Once you click on the Container action, you will have several options available. You can start, restart, or stop the container.

Fig 3. Drop-down menu options for the script

You will have a confirmation window asking if this is the right action you want to perform.

Fig 4. Execution Confirmation window
Fig 5. Script output on successful execution.

The status can also be checked in the host’s latest data menu, once the metric is collected (1 minute for the master item). The item Container /zabbix-agent2: Running shows that this container is not running, and another item displays the exit code 0, which means the process stopped normally with no issue whatsoever.

Fig 6. The latest data for the Zabbix agent 2 container

Some items report the status in numerical format, e.g., 0 , 1 , 2, and so on. To make it human-readable, we use value maps, which display the value in a meaningful, human-friendly way. The screenshot below shows the value map for container health status. So, instead of looking at value 3 for container health (which is meaningless for us and will require reading the documentation) we will be shown value healthy (3).

Fig 7. Predefined value mapping on the template

Automating the container crash recovery

What if your container crashes for some reason? Well, you will get a problem event, which you can use to receive notifications about issues with containers. You can also automate the container recovery process. For example, create a trigger action that will restart the container 3 times with an interval of 2 minutes.

If it does not resolve the issue, only then send a message to the admin. There is no reason to repeatedly restart the service until the end of time – if a few attempts did not work, most likely it will require human intervention to solve the issue.

So here are the script parameters for the action operation:

● Script
▪ Name: Restart container
▪ Scope: Action operation
▪ Type: Script
▪ Execute on: Zabbix server
▪ Commands: curl -sS -X POST https://{$DOCKER.IP}:{$DOCKER.PORT}/containers{HOST.NAME}/restart --cert /etc/zabbix/ssl/certs/client-cert.pem --key /etc/zabbix/ssl/keys/client-key.pem --cacert /etc/zabbix/ssl/ca/ca.pem
▪ Description: Restart container
▪ Host group: Selected: Docker
Fig 8. Script action parameters

Now we have to define a trigger action in order to make use of this script and send a notification to admin if that fails.

Let’s create a new trigger action:

● Action tab
▪ Name: Automatic container restart
▪ Type of calc: And (A and B)
▪ condition: Host group equals Docker
▪ condition: Event name contains Container has been stopped with error code
▪ Enabled: Check

● Operations tab
▪ Default operation step duration: 2m

Add operation
▪ Operation: Current host: Check
▪ Steps: 1 -3
Add operation
▪ Operation: Send message
▪ Steps: 4 – 4
▪ Custom message: Check
▪ Subject: Automated restart failed to bring container up: {HOST.NAME}
▪ Message: <b>Host: {HOST.NAME}<br>
           <b>Problem started at {EVENT.TIME} on {EVENT.DATE}<br>
           <b>Operational data: {EVENT.OPDATA}<br>
           <b>Original problem ID: {EVENT.ID}<br>
Fig 9. New action tab
Fig 10. Action operation tab: new Operation step 1-3
Fig 11. Action operation tab: new step 4-4

The action should look like the screenshot below. Save it.

Fig 12. Defined action operations

Testing container crash automatic recovery

I will stop the container with the command docker kill zabbix-agent2. The container has been stopped with an exit code different from 0, so when the item receives the data (in my case, after 1 minute) I get a problem event. The trigger action executes the script Container restart immediately, after 2 minutes, and after 4 minutes if the problem event has not been resolved.

Fig 13. Problem event about stopped container exit code 137

This script successfully restarted the container. The container is running again, and the problem event is resolved.

Fig 14. Resolved event with remote script execution

Let’s see if I am quick enough to kill the west proxy container repeatedly, before the item collects the data with the container running state. Well, I managed to be faster, so now you will see what happens when it “fails” to bring the container back to running state. Here in the Actions, we can see that Zabbix executed the script three times (I also stopped the container 3 times fast enough!) after which the action sent a notification to the admin about a failure to bring the container up with restarts.

Fig 15. Problem event about stopped container exit code 137

I have received the message that the container restart was unable to bring the container to a running state and requires human interaction to fix this.

Fig 16. Problem event notification in email

Summary

Now you know how to plan ahead and make use of the built-in capabilities of Zabbix to solve the issue without human intervention (where possible) and only get notifications when the automatic remediation attempt fails.

 

The post Zabbix and the Docker API, Part 3: Control appeared first on Zabbix Blog.

SPEC Consortium Releases SPEC CPU 2026 Benchmark Suite: The Next Decade of CPU Benchmarking

Post Syndicated from Ryan Smith original https://www.servethehome.com/spec-consortium-releases-spec-cpu-2026-benchmark-suite-the-next-decade-of-cpu-benchmarking/

After nearly a decade, SPEC has released a new version of its industry-defining CPU benchmark, SPEC CPU 2026. We take a look at what’s new, as well as the new benchmark’s performance on a modern AMD, Intel, and NVIDIA CPU trio

The post SPEC Consortium Releases SPEC CPU 2026 Benchmark Suite: The Next Decade of CPU Benchmarking appeared first on ServeTheHome.

Introducing AI traffic analysis dashboards for AWS WAF

Post Syndicated from Christopher Jen original https://aws.amazon.com/blogs/security/introducing-ai-traffic-analysis-dashboards-for-aws-waf/

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.

Modernize your workflows: Amazon WorkSpaces now gives AI agents their own desktop (preview)

Post Syndicated from Micah Walter original https://aws.amazon.com/blogs/aws/modernize-your-workflows-amazon-workspaces-now-gives-ai-agents-their-own-desktop-preview/

Enterprises face a significant challenge when deploying AI agents: the desktop and legacy applications that power most business workflows are simply inaccessible to modern AI systems. According to a 2024 Gartner report, 75% of organizations run legacy applications that lack modern APIs, and 71% of Fortune 500 companies operate critical processes on mainframe systems without adequate programmatic access. For many organizations, this has meant choosing between delaying AI adoption or undertaking expensive and risky modernization projects.

Today, we are announcing that Amazon WorkSpaces now enables AI agents to securely operate desktop applications without requiring application modernization. The same managed virtual desktops that millions of employees use and trust can now also serve AI agents, turning WorkSpaces into infrastructure for scaling enterprise productivity, not just delivering it. Because agents operate within your existing WorkSpaces environment, there are no APIs to build, no application migrations to plan, and no new infrastructure to manage.

Some of our customers had an early opportunity to give their agents a WorkSpace. Chris Noon, Director, Nuvens Consulting shared with us, “WorkSpaces lets our clients give AI agents the same secure, governed desktop environment their employees already use — no custom API integrations, full audit trails, and enterprise-grade isolation out of the box. For regulated industries, that’s not a nice-to-have — it’s the baseline.”

Secure cloud desktop access for AI agents
With WorkSpaces, AI agents can securely access and operate desktop applications running inside managed WorkSpaces environments to complete complex business workflows. Agents authenticate through AWS Identity and Access Management (IAM) and connect via Workspaces with complete audit trails available through AWS CloudTrail and Amazon CloudWatch. Because agents operate within secure WorkSpaces environments rather than on local machines, your existing security controls and compliance policies remain fully intact.

Amazon Workspaces supports the industry-standard Model Context Protocol (MCP), which means WorkSpaces works with any agent framework, such as LangChain, CrewAI and Strands Agents.

Let’s try it out
To set up a WorkSpaces environment for AI agents, I started in the AWS Management Console by creating a new WorkSpaces Applications stack—the environment definition that controls how agents connect and what they’re allowed to do.

From the Amazon WorkSpaces console, I chose Create stack and configured the basics: name, fleet association, and VPC endpoints. In Step 3 of the stack creation workflow, I noticed the new AI agents section with two options. The first, No AI agent access, is the default configuration for standard WorkSpaces designed for people. The second, Add AI Agents, allows AI agents to securely access and operate applications using their own identity and permissions. I selected Add AI Agents to enable agent connections on this stack.

Workspaces Screenshot

Next, I will enable storage before configuring the agent access settings to define how agents interact with the desktop.

Workspaces screenshot

Under Agent features, I enabled three capabilities. Computer input allows the agent to click, type, and scroll within the desktop. Computer vision allows the agent to capture screenshots of the desktop, which is how it “sees” the application. Finally, screenshot storage configures where session screenshots are stored for audit and debugging.

Workspaces Screenshot

Under Desktop screen layout, I set the screen resolution to 1280×720 and image format to PNG. The resolution determines the fidelity of what the agent sees during a session—a complex application with dense UI elements might benefit from higher resolution, while a terminal-style interface works well at 720p.

Workspaces Screenshot

With my stack configured, WorkSpaces exposes a managed MCP endpoint. I pointed my agent framework to this endpoint, provided IAM credentials for authentication, and my agent began interacting with the desktop applications installed on the fleet’s image.

To see this in action, here’s an agent built with the Strands Agent SDK and Amazon Bedrock handling a prescription refill, looking up the patient record, searching for the medication, placing the order, and confirming a successful refill, all inside a sample pharmacy system with no API.

The application doesn’t know an agent is driving it. Nothing about the software was modified, rebuilt, or integrated. The agent worked with it exactly as it exists today.

Now available
This feature is available today in public preview at no additional cost in US East (N. Virginia, Ohio), US West (Oregon), Canada (Central), Europe (Frankfurt, Ireland, Paris), and Asia (Tokyo, Mumbai, Sydney, Seoul, Singapore) Regions.

Get started building today using our GitHub repo, or visit the WorkSpaces page for more details.

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

Post Syndicated from Roger Nem original https://aws.amazon.com/blogs/security/five-ways-to-use-kiro-and-amazon-q-to-strengthen-your-security-posture/

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.

[$] Hardware-assisted Arm VMs for s390

Post Syndicated from daroc original https://lwn.net/Articles/1069954/

A recent

patch set
from Steffen Eiden and others has set the groundwork for allowing
hardware-assisted emulation of Arm CPUs on s390 CPUs.

Version two
of the posting fixes a handful of smaller problems, but does not
differ much.
The patches were welcomed
by the Arm maintainers, pending some discussion of how the collaboration between the
architectures could be structured to prevent maintainability problems on the Arm
side. When those details are resolved, the patches could pave the way for
transparently running Arm-based virtual machines (VMs) on s390 hosts at native or
near-native speeds.

Security updates for Tuesday

Post Syndicated from jzb original https://lwn.net/Articles/1071324/

Security updates have been issued by AlmaLinux (kernel, kernel-rt, libcap, LibRaw, openssh, thunderbird, and tigervnc), Debian (libarchive and lxd), Fedora (chromium, insight, nodejs20, rust-sequoia-git, and uriparser), Mageia (kernel, kmod-virtualbox), Oracle (kernel, libcap, thunderbird, and uek-kernel), Red Hat (.NET 10.0, .NET 8.0, .NET 9.0, fence-agents, sudo, and systemd), Slackware (httpd), SUSE (freerdp, hauler, helm, himmelblau, kernel, libspectre, thunderbird, trivy, and xen), and Ubuntu (curl, exim4, and sed).

Micron 6600 ION 245TB SSD Announced

Post Syndicated from Cliff Robinson original https://www.servethehome.com/micron-6600-ion-245tb-ssd-announced/

Micron has a new capacity point for its 6600 ION NVMe SSD family, and this one is the eye-catcher. The company now has a 245.76TB version of the Micron 6600 ION, giving data center platforms a way to put almost a quarter petabyte of flash i

The post Micron 6600 ION 245TB SSD Announced appeared first on ServeTheHome.

A Walkthrough of the 2026 Global Cybersecurity Summit Agenda

Post Syndicated from Emma Burdett original https://www.rapid7.com/blog/post/it-walkthrough-2026-global-cybersecurity-summit-agenda

The full agenda for the Rapid7 2026 Global Cybersecurity Summit is now live, and it gives a clearer sense of how the conversation around security operations is evolving.

Across two days, the sessions progress from a shared understanding of how threats are changing into a more detailed look at how teams detect, respond, and make decisions in practice.

Day 1: How threats evolve and how teams respond

The day opens with a keynote, Defense Starts Earlier Than You Think, where Brian Castagna is joined by Craig Robinson, Research Vice President at IDC, to examine why complexity has become the main barrier to effective security and what changes when teams start acting earlier.

That context carries into The Reality of Running a SOC in 2026, featuring Raj Samani alongside Rachel Tobac, CEO of SocialProof Security, and Graham Cluley, cybersecurity speaker and podcast host. The discussion focuses on how attacks actually begin, from identity misuse to cloud misconfigurations, and why defenders often fall behind as those attacks evolve.

In Customer Panel: How Clarity Beats Complexity, leaders including Debby Briggs, CISO at Netscout Systems, Raheem Daya, Chief Technology Officer at Target RWE, and Will Lambert from Culligan International share how they are simplifying their environments and focusing on outcomes rather than activity.

From there, Inside the Modern SOC: Who Carries You Through an Incident walks through a real investigation step by step, showing how alerts are triaged, decisions are made, and outcomes are shaped under pressure.

The conversation then turns to AI in The AI Dilemma: Automating Defense Without Surrendering Judgment, where the role of AI in the SOC is examined through the lens of trust, transparency, and how it supports analyst decision-making in practice.

In Beyond the Vulnerability List, the focus shifts to exposure management, looking at how organizations are moving beyond static vulnerability tracking and using exposure as an early signal to guide detection and response.

That idea of validation continues in Using Red Teaming to Power Preemptive MDR, where continuous adversary testing is used to prove detection coverage and refine response workflows before an incident occurs.

The day also includes a short look at Rapid7: What’s New and What’s Next, connecting recent innovations across exposure management, MDR, and AI to how teams operate in practice.

The closing session, Persistence Under Pressure, introduces a different perspective. Former Special Forces operator Jason Fox draws on real-world experience to explore preparation, understanding the adversary, and how teams make decisions when conditions are less predictable.

Day 2: Strategy for leaders, execution for practitioners

The second day builds on that foundation, with two dedicated tracks designed around how security teams actually work.

For security leaders, The CISO’s Role in Enterprise Transformation brings together perspectives from Craig Robinson and Horst Moll, CISO at Miltenyi Biotec, to explore how the role of the CISO is evolving beyond technical leadership into broader organizational influence.

That is followed by How Exposure Insights Reframe Risk and Security Decisions, which looks at how leaders define priorities and align teams when exposure data is tied more closely to real-world risk.

In A CISO’s Guide to MDR Accountability and Outcomes, the focus moves to how effectiveness is measured, shifting from activity-based metrics toward outcomes that reflect business impact.

The leader track closes with Customer Panel: What CISOs Would Do Differently If Starting Today, featuring CISOs including Jonathan Chow of Genesys and Tony Arnold of TSB Bank, reflecting on what they would change or simplify based on experience.

For practitioners, Hunt or Be Hunted: Frontline Tales of Detection walks through a real incident, showing how analysts decide what to investigate and how signals are correlated across environments.

The New Rules of Detection Engineering builds on that with insights from Steve Edwards, Director of Threat Intelligence Detection Engineering, focusing on detection-as-code and how teams prioritize signals in practice.

In From Cloud Exposure to Runtime Attack, Shauli Rozen, CEO and Co-founder of ARMO, and Ben Hirschberg, CTO and Co-founder, walk through a cloud attack scenario to show how risks escalate and how they can be interrupted earlier.

The practitioner track closes with IR in Practice: Tools, Tradecraft, and Adversary-Informed Investigation, where Shanna Battaglia and Michael Cohen demonstrate how open-source tools and real-world workflows come together during incident response.

Register and join the conversations

Taken together, the agenda reflects a shift that runs through every session. Security operations are moving toward earlier decisions, better prioritization, and a clearer understanding of what matters in the moment.

If you want to see how that shift is playing out across strategy, detection, and response, this is where those conversations come together.

Join us May 12–13 and explore the full agenda in practice.

Register now.

The collective thoughts of the interwebz