Grok 4.3 from xAI now available in Amazon Bedrock

Today, AWS announces the availability of xAI’s Grok 4.3 model on Amazon Bedrock. With this launch, xAI joins Amazon Bedrock as a model provider, giving you even more choice as you build generative AI applications across reasoning, agentic, and enterprise workflows.
Grok 4.3 is a reasoning-first model that offers always-on and configurable reasoning effort (none, low, medium, high). Because reasoning is always active rather than optional, it behaves more consistently across multi-step agent loops than models that can skip thinking. It also offers strong tool use and instruction-following capabilities for building multi-step agents, and token efficiency to help keep high-volume inference cost-effective. Grok 4.3 is especially well suited to enterprise workloads such as contract review, case law research, credit agreement analysis, and financial document Q&A, while delivering consistent, high-quality results across conversational AI, search, chat, and multi-turn workflows. Grok 4.3 runs on Mantle, a new inference engine in Amazon Bedrock designed for price performance, with support for tool calling, structured output, and response streaming.
See region availability of Grok 4.3 for list of supported regions. To get started, visit the Grok 4.3 model detail page in our documentation.
Quelle: aws.amazon.com

AWS Management Console Private Access now works without internet connectivity

AWS Management Console Private Access now enables customers to access the AWS Console from VPCs without internet connectivity, allowing enterprises to manage their AWS infrastructure through the console while maintaining strict network security controls in air-gapped environments. Previously, AWS Management Console Private Access allowed customers to restrict console access to authorized AWS accounts and corporate networks but still required internet connectivity. With this launch, AWS Console traffic can flow through VPC endpoints for the supported service consoles, eliminating the need for any internet access. This capability is particularly valuable for customers in regulated industries such as financial services, government and defense, and healthcare, and for enterprises with strict security requirements who need to access sensitive data only from controlled environments and use the console in classified or networks without internet connectivity. AWS Management Console Private Access uses AWS PrivateLink to establish secure network paths between customer VPCs and the console. Customers can apply VPC endpoint policies to restrict access to specific AWS accounts and organizations, and use IAM, Service Control, and Resource Control policies to require that employees access resources only from authorized networks.
This capability is available in all AWS commercial regions. You pay only for the underlying AWS PrivateLink VPC endpoint usage and data processing. To get started and learn about the supported services, visit the Management Console Private Access documentation.
Quelle: aws.amazon.com

Docker joins the Athena coalition: a cross-industry collaboration for supply chain security

The obvious takeaway from 2026’s biggest incidents is that attackers are increasingly using AI to move fast. Docker’s CISO, Mark Lechner, wrote about this shift and what every engineering team should do now.

What worries us is that the bar is about to drop further. For most of the last decade, finding a serious vulnerability in widely used open source took time and specialized skill. Frontier models now read code, reason across dependencies, and surface novel, chained vulnerabilities at machine speed, including flaws that survived years of expert review. Anthropic’s Mythos, and the more powerful models that follow it will find more vulnerabilities, faster, and by a wider margin than skilled humans could. The gap between a vulnerability being discovered and exploited has shrunk from years to hours, and a growing share are weaponized before they are ever public.

We believe the durable response in this reality is twofold: build products that are secure and transparent by default, and collaborate deeply across the ecosystem to share signals and intelligence. No single vendor sees the whole picture, and customers are best protected when supply chain technologies work together rather than in isolation.

Secure-by-default tools for devs, as AI embeds into the SDLC

As coding agents take on more of the software lifecycle, secure defaults have to cover more than what you build with. They have to cover where agents run and what they can reach. Today, Docker’s investment spans three areas covering sandboxes for local developers, secure dependencies, and governed access to vetted MCP tools. These capabilities and our upcoming products in the near future collectively help secure the developer environment as AI embeds itself into the SDLC:

Isolated, sandboxed execution for agents: Docker Sandboxes run AI coding agents in isolated microVMs, each with its own kernel, filesystem, and deny-by-default network, so a compromised dependency an agent pulls cannot reach the host, its credentials, or other workloads.

Trusted, open source foundations: Docker Hardened Images Community is free and open source under Apache 2.0. DHI are minimal, low-CVE images rebuilt from source with SLSA Build Level 3 provenance and signed SBOMs, built on Alpine and Debian. The catalog now spans over 3,500 hardened images and tens of thousands of hardened system packages, extending across container images, system packages, Helm charts, and MCP servers. DHI makes secure dependencies the easy, default choice.

Governed access to tools: Docker MCP Catalog and Gateway give agents a trusted, hardened set of MCP servers, plus centralized policy, secret blocking, and audit logging, so the connections agents make are verified rather than assumed.

Together these tools give developers a secure default from the first docker build through to the agent running in their environment. 

Working with the ecosystem on behalf of every developer

The second part of our approach is how we work with the ecosystem. For example, with the axios compromise earlier this year and the TeamPCP campaign, Docker worked with partners including Socket, the Trivy team, Checkmarx, and others to analyze the attacks and contain the blast radius (recap). The damage potential with these attacks could have been very large, however sharing signals across company lines, in real time, is what kept the blast radius relatively small. We have said it before, this is a posture we believe the ecosystem needs more of.

Docker is joining the Athena alliance

Athena is the next step in our journey of collaboration. Announced today, it is an industry coalition for the coordinated defense of open source software in the era of AI-accelerated vulnerability discovery, and Docker is a founding participant. Athena brings together organizations from across the software ecosystem to share findings and coordinate responses before vulnerabilities become public. Docker sits at a distinctive point in the supply chain, with millions of developers relying on us to build, distribute, and run software built on open source, so helping make that ecosystem more resilient is consistent with our mission. We look forward to working with the coalition on key ways in which Docker is uniquely placed to provide expertise and scale to this important cross-industry effort.

Further reading

Docker Sandboxes

Docker Hardened Images

Defending your software supply chain (Docker CISO Mark Lechner)

Quelle: https://blog.docker.com/feed/

AWS DevOps Agent expands with custom SRE agents and MCP/A2A protocols

AWS DevOps Agent now supports custom SRE agents, bring-your-own sub-agents, and headless access via MCP and A2A protocols. These capabilities enable teams to automate recurring SRE workflows, extend DevOps Agent by connecting it to other agents, and access its capabilities from the tools they already use, including Kiro, Claude, and other coding assistants. With custom SRE agents, teams can create and schedule agents within Agent Spaces that run on a cadence. For example, create a daily database health report that checks for slow queries and parameters that need tuning, or build an agent that reviews logs from the past 24 hours and flags anomalies. In headless mode, developers can invoke DevOps Agent from the tools and agents they already use via A2A or MCP protocols. For example, the Kiro power for AWS DevOps Agent lets developers check production health and investigate issues without leaving their IDE. Teams can also connect their own sub-agents built with Amazon Bedrock or third-party frameworks via A2A to extend DevOps Agent capabilities. AWS DevOps Agent also introduces chat enhancements, incident-skip support based on customer-defined rules, enhanced knowledge with memories and Git-managed skills, human labeling and customer-created dashboards for tracking task quality, and is available in five new Regions. See all the latest AWS DevOps Agent features on the recent improvements page. For the list of AWS Regions where AWS DevOps Agent is available, see the supported Regions table.
Quelle: aws.amazon.com

AWS Lambda Managed Instances now supports Tag Propagation for Managed Resources

AWS Lambda Managed Instances (LMI) now supports tag propagation, enabling you to automatically apply tags to managed resources such as Amazon EC2 instances, Amazon EBS volumes, and Amazon ENIs. This helps you enforce cost allocation, service control policies (SCPs), and compliance requirements across all resources provisioned by your capacity providers.
LMI lets you run Lambda functions on managed EC2 instances with built-in routing, load balancing, and auto scaling, giving you access to specialized compute configurations including the latest-generation processors and high-bandwidth networking, with no operational overhead. Organizations that use resource tagging for cost tracking, governance, or security previously had no way to propagate tags to the underlying managed resources that LMI provisions on their behalf. This made it difficult to track costs accurately, enforce SCPs, or meet compliance standards that require approved tags on all resources. Now, with tag propagation, you can specify a set of tags on your capacity provider configuration, and LMI automatically applies those tags to all managed resources it creates. This ensures consistent tagging across your EC2 instances, EBS volumes, and ENIs without requiring manual intervention or custom automation.
This feature is available in all AWS commercial Regions where LMI is generally available. To get started, configure the PropagateTags setting on your capacity provider using the CreateCapacityProvider or UpdateCapacityProvider APIs. Set the mode to Explicit and provide your desired tags as key-value pairs. Tag propagation applies to all new managed resources provisioned after the configuration is applied. You can configure these settings using the AWS Management Console, AWS CLI, AWS CloudFormation, AWS CDK, or AWS SAM. To learn more, visit the AWS Lambda Managed Instances product page and documentation.
Quelle: aws.amazon.com