AWS Entity Resolution now supports advanced real-time matching

AWS Entity Resolution now supports real-time matching with advanced matching workflows, enabling customers to match records in milliseconds using complex rulesets through the GenerateMatchId API. Previously, real-time matching was limited to simple rule-based workflows, while advanced rulesets—which support operators like Exact and ExactManyToMany combined with AND/OR logic—could only be used for batch processing that took minutes to hours. This created a critical gap for customers needing real-time entity resolution with sophisticated matching logic.
With this launch, customers performing fraud detection, real-time account lookup, or website personalization can define advanced matching rules and get results in real-time without maintaining separate matching infrastructure or re-architecting applications. To enable advanced real-time matching, customers set the enableRealTimeMatching parameter to true on their matching workflow, then call the existing GenerateMatchId API—no new endpoints or migration required.
Advanced real-time matching is available in all AWS Regions where AWS Entity Resolution is available. 
To get started, see Using GenerateMatchId in the AWS Entity Resolution User Guide.  
For more information about AWS Entity Resolution, visit the product page.
Quelle: aws.amazon.com

Amazon EC2 M8a instances now available in the Asia Pacific (Hyderabad) region

Starting today, the general-purpose Amazon EC2 M8a instances are available in AWS Asia Pacific (Hyderabad) region. M8a instances are powered by 5th Gen AMD EPYC processors (formerly code named Turin) with a maximum frequency of 4.5 GHz, deliver up to 30% higher performance, and up to 19% better price-performance compared to M7a instances. M8a instances deliver 45% more memory bandwidth compared to M7a instances, making these instances ideal for even latency sensitive workloads. M8a instances deliver even higher performance gains for specific workloads. M8a instances are up to 60% faster for GroovyJVM benchmark, and up to 39% faster for Cassandra benchmark compared to Amazon EC2 M7a instances. M8a instances are SAP-certified and offer 12 sizes including 2 bare metal sizes. This range of instance sizes allows customers to precisely match their workload requirements. M8a instances are built using the latest sixth generation AWS Nitro Cards and ideal for applications that benefit from high performance and high throughput such as financial applications, gaming, rendering, application servers, simulation modeling, mid-size data stores, application development environments, and caching fleets. To get started, sign in to the AWS Management Console. Customers can purchase these instances via Savings Plans, On-Demand instances, and Spot instances. For more information visit the Amazon EC2 M8a instance page.
Quelle: aws.amazon.com

Amazon EC2 C7a instances are now available in the US West (N. California) Region

Starting today, the compute optimized Amazon EC2 C7a instances are now available in AWS US West (N. California) Region. C7a instances, powered by 4th Gen AMD EPYC processors (code-named Genoa) with a maximum frequency of 3.7 GHz, deliver up to 50% higher performance compared to C6a instances. C7a instances offer new processor capabilities such as AVX-512, VNNI, and bfloat16. They feature Double Data Rate 5 (DDR5) memory to enable high-speed access to data in memory and 2.25x more memory bandwidth compared to C6a instances, making these instances ideal for even latency sensitive workloads. C7a instances offer 12 sizes from medium to 48xlarge, including a bare-metal size. And with the launch of C7a instances, customers can attach up to 128 EBS volumes to an EC2 instance — by comparison, C6a instances allow up to 28 EBS volume attachments to an EC2 instance. These instances are built on the AWS Nitro System and ideal for high performance, compute-intensive workloads such as batch processing, distributed analytics, high performance computing (HPC), ad serving, highly-scalable multiplayer gaming, and video encoding. C7a instances are available through On-Demand, Spot Instances, and Savings Plans. To get started, visit the AWS Management Console, AWS Command Line Interface (CLI), and AWS SDKs. To learn more, see C7a instances.
Quelle: aws.amazon.com

Runtime Enforcement, Not Runtime Advice

In Part 1, we explored why traditional security models struggle with autonomous agents. As developers begin delegating more work to AI systems, a growing amount of activity happens outside familiar checkpoints such as repositories, CI/CD pipelines, and deployment environments. That naturally raises a new question: If governance needs to exist where agents actually execute work, what does that look like in practice?

Policies Alone Are Not Enough

Most organizations already have policies.

Don’t expose customer data.

Don’t access production systems without authorization.

Don’t execute untrusted code.

Don’t use credentials outside approved workflows.

The challenge isn’t writing these rules. The challenge is enforcing them when software systems can increasingly take actions on their own. This is where a useful distinction emerges:

A prompt can influence behavior.

A runtime can restrict behavior.

That difference becomes increasingly important as agents gain access to files, terminals, APIs, and external tools.

The Three Boundaries Behind Developer Confidence

When I simplify the problem, most governance challenges fall into three areas. Before looking at those boundaries individually, it’s worth asking why they matter in the first place. When governance discussions focus only on security, it’s easy to miss why developers care about these controls. Most developers aren’t asking for more restrictions. They’re asking for predictability. Before delegating work to an agent, developers want to understand:

• What can it access?

• What can it modify?

• Which tools can it use?

• Which credentials can it act with?

The clearer those answers become, the easier it is to trust the agent with meaningful work. In that sense, boundaries are not just security controls. They are trust-building mechanisms that help transform agents from interesting experiments into everyday development tools. 

1. Execution Boundary

The first boundary is execution.

Agents can:

Read files

Modify code

Execute commands

Install dependencies

Open network connections

Consider a coding agent troubleshooting a failing test suite. It may inspect configuration files, generate temporary scripts, install debugging dependencies, execute diagnostic commands, and repeatedly rerun tests before a human reviews the final result.

Governance determines the boundaries within which those actions occur. More importantly, it gives developers confidence that those boundaries exist. Teams are far more willing to delegate work to agents when they understand where those limits are and how they are enforced.

2. Tool Boundary

Modern agents rarely operate alone.

They interact with:

Source control platforms

Issue trackers

Communication tools

Cloud services

Internal APIs

Databases

A coding agent might create a pull request, update a Jira ticket, or retrieve documentation through an MCP-connected tool. None of these actions require local code execution, but they still affect real systems. This means governance isn’t only about execution. It’s also about access. Controlling one while ignoring the other leaves a significant blind spot.

3. Credential Boundary

Most useful agents eventually need access to something valuable.

That might be:

A GitHub repository

A cloud environment

An internal API

A database

A customer support system

Behind those systems are credentials, permissions, and identity controls. The question is not simply whether an agent can use a credential. The question is how access is controlled, observed, and audited. As agent autonomy increases, credential governance becomes just as important as execution governance.

A Simple Architecture View

At a high level, governance can be understood as enforcing boundaries around execution, tool access, and credentials.

Figure 2. Agent governance requires controls across execution, tool access, and credentials. Runtime enforcement provides the foundation for isolation, policy, and visibility.

The Role of Isolation

One of the oldest security principles in computing is isolation. Containers, Virtual machines, and Sandboxed environments. All exist for the same reason: creating boundaries around what software can access and affect. As agents become more capable, these concepts become increasingly relevant. Rather than allowing autonomous systems to operate with unrestricted access to a developer environment, organizations can introduce controlled execution boundaries. The goal isn’t to make agents less capable. The goal is to make capability predictable. Docker Sandboxes are one example of how isolation concepts are being adapted for agent execution workflows, helping create clearer boundaries around what an agent can access and execute.

Isolation helps answer important questions:

What can the agent access?

What can it modify?

What can it execute?

What can it communicate with?

Without boundaries, these questions become difficult to answer consistently.

Governance Beyond Code Execution

Execution is only part of the story. Modern agents are increasingly connected to external tools and services. A coding agent might update an issue tracker. A support agent might retrieve documentation. A platform agent might interact with cloud infrastructure. This creates a second governance challenge: Not just what an agent can execute, but what an agent can access. As organizations adopt protocols such as MCP to connect agents with tools, visibility and policy become just as important as capability. The goal isn’t to prevent agents from doing useful work. The goal is to ensure that useful work remains observable, controllable, and accountable.

Building Trust Through Boundaries

AI governance is sometimes framed as a limitation on autonomy. In practice, it serves a different purpose. Organizations are more likely to trust agents when clear boundaries exist around what those agents can see, access, and execute. Trust doesn’t emerge from capability alone. It emerges from capability combined with visibility, control, and accountability. That’s why governance is ultimately more than an infrastructure problem. Clear boundaries create predictability. Predictability creates confidence. And confidence is what allows developers to delegate more work to increasingly capable agents. As agent adoption grows, the organizations that establish that confidence early may be able to move faster, not slower.

In Part 3, we’ll explore why governance is ultimately as much a developer experience challenge as it is a security challenge and why the teams that get this balance right may be able to adopt AI agents faster, not slower.

Learn More

Read about why AI Agents need isolation

Read Part 1 of this AI Governance series

Find out how Docker’s AI Governance solutions work across all tools

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

Agentic AI Needs Guardrails, Not Guesswork

What does it take to secure AI agents without slowing developers down? A recent panel explored the answer 

I recently joined Zach Lloyd, founder and CEO of Warp; Gavriel Cohen, co-founder and CEO of NanoCo and creator of NanoClaw; and moderator Moriah Hara, founder of a community of more than 3,000 CISOs and a three-time Fortune 500 CISO, for a discussion on one of the biggest challenges facing enterprise security teams today: how to safely unlock the productivity of agentic AI.

The rapid rise of agentic AI in the enterprise is putting CISOs in a tough spot. On one hand, business leaders are clamoring to run with the new technology, which promises a productivity revolution like no other. On the other, setting AI agents loose without rigorous guardrails creates severe vulnerabilities. 

Moriah put the dilemma facing CISOs like this: “The business wants AI agents everywhere, developers are already using them, sometimes without approval, oftentimes without security. …CISOs are left in this uncomfortable middle where we’re tolerating some tools, we’re praying that nothing breaks, we’re buying some time until we can get some governance beyond policy in place to have better visibility.”

The panel explored the role of the CISO in balancing this tension between productivity and security. Here are some highlights.

Isolate, control, observe

They came at it from different angles, but the panelists agreed on one imperative: running AI agents safely requires an isolated environment with trusted control boundaries. For Zach, Warp’s Oz platform provides that isolation. It’s a cloud agent infrastructure for secure and automated deployment of coding agents that allows centralized management, access controls, and visibility into what agents are doing across the organization.

Zach said you can “literally pull up the Oz web app and see what every agent across your company is doing at all times—which is a way better situation than the world we’re in right now, where someone on your marketing team is running Cloud Code, someone on your sales team is running Codex, and you just have no idea what’s going on, what tools they’re installing.”

NanoClaw—a personal AI agent

At Docker, our answer to the challenge of running AI agents safely is to run them in disposable, isolated, local sandboxes. Docker Sandboxes give agents the freedom and autonomy they need to do their best work, safely. Call it YOLO mode with guardrails. As Moriah noted in our discussion, agentic speed should be encouraged— “it’s the ungoverned speed that is the problem.” When agents are allowed to run fast without running wild, speed and safety are no longer a tradeoff. 

Of note here: In March, we announced the integration of NanoClaw with Docker Sandboxes to deliver secure-by-design agent execution. The integration allows every NanoClaw agent to run inside a disposable, MicroVM-based Docker Sandbox that enforces strong operating system-level isolation. The stack takes advantage of NanoClaw’s minimal attack surface and fully auditable open-source codebase to meet enterprise security standards. 

Laptops as the new prod

A key focus of the discussion was where to run agents safely. With vibe coding exploding, and agents and Claws (a new class of agents) already in production, the laptop today is the most powerful node in the enterprise. It’s also the most exposed. As a colleague of mine recently put it, laptop and agent environments are the new prod, and they need to be governed like prod.

Zach stressed the need to get agents off people’s laptops and desktops and into a controlled, cloud-based environment where CISOs can see what every agent across the company is doing at all times.

Portability—from laptop to cloud

My position is that, if you run agents in a sandbox, it doesn’t matter where the box sits. It could sit on a marketing or finance person’s laptop, or on a DevOps engineer or cloud admin’s machine. As long as the trust boundary is established and you know what’s getting piped in and out of it, you’re locked and loaded for rapid prototyping, experimentation, and innovation.

By the way, this view syncs with Docker’s vision, which has always been about portability. Our vision was never everything is local. We start in the local environment, then lift off into distributed environments, Kubernetes clusters, public clouds, whatever. It’s the same with agents. Eventually they’ll lift off, be decoupled from human operators, and be able to run fully autonomously wherever needed—always in the same portable environment.

When agents build the supply chain

The supply chain today is a revolving door for opportunistic attackers like TeamPCP and ShinyHunters who exploit transient dependencies and other vulnerabilities, often needing only a short window of time to filch credentials and information.

How are CISOs to combat these risks when AI agents themselves are pulling base images, choosing dependencies, and assembling code—autonomously and without human oversight? After all, in an autonomous supply chain, traditional methods of scanning and patching after building are no longer feasible. 

Keeping humans in the loop

The panelists shared several best practices. Zach urged keeping humans in the loop for picking clean, secure dependencies, especially upstream libraries, and setting up blessed images for agents to choose from. Gavriel recommended setting a minimum release age of seven days for images and minimizing dependencies—even safe ones.

A training-wheels approach

Gavriel also suggested a training-wheels approach to experimenting with agents, starting out using unpermissioned data to build skills and avoid sensitive data issues. “Unlocking the value today is important,” he said, “but even more important is having people build the skills of working with agents, because what’s going to be coming in the coming months and years is going to totally exceed anything that we have today. So, it’s really about building the muscle memory, building the skills.”

Layer security to limit the blast radius

My take? Opportunistic attackers are simply exploiting an ecosystem that’s inherently flawed and broken and that unfortunately won’t get fixed within the next six to 12 months. Until then, developers should assume these attacks will continue and prepare for them by layering security to limit the blast radius. That means reducing privilege, reducing third-party access to their environment, and using immutable tags, digests, and SBOMs (Software Bill of Materials) to lock manifests and enable rapid detection of poisoned images. And, yes, outsourcing the risk to a trusted build environment like Docker that provides clean, hardened images so you’re starting from a clean foundation. 

MCP—the new shadow IT?

The panelists rounded out the discussion with a focus on the security implications of using MCP in developer environments. MCP (Model Context Protocol) is a standard that allows LLMs to access external data and use tools, potentially making AI more powerful and reliable.

The consensus was that centralized, secure governance is crucial for productivity and risk management. Gavriel stressed the importance of proper version control, credential management, and a “golden repository” of verified tools. Zach advocated for centralized management to avoid individual tool dependencies and ensure minimal access. 

Making it safe and easy to run MCP servers

And Docker? About a year ago, we introduced an open source MCP Gateway that serves as a chokepoint between agents and external tools. Routing every tool call through this enforcement point, where it can be authenticated, authorized, and logged before it reaches the external system, enables a wide range of agents to access trusted catalogs of MCP servers. While it’s not clear to me how long MCPs will remain useful, given the exponential speed with which AI is evolving, Docker MCP Gateway solves an important challenge today. Like Docker Sandboxes, it makes enforcement strict instead of advisory.

A once-in-a-generation opportunity—and challenge

Enabling dev environments to take advantage of agentic AI is a once-in-a-generation opportunity, and CISOs are accountable for making sure the rush to do so doesn’t devolve into the Wild West.

Moriah closed the panel with a provocative thought: “Six months from now, enterprises are all going to be running agents at scale. The one key success factor will be whether governance was present from day one or got bolted on after the first major incident.”

In the choose-your-own-adventure reality of agentic AI today, what kind of security leader will you be? 

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