Cloud Computing Köln - Neues zu Cloud Computing, Internet of Things und Technologien

In July, Docker, Snyk and Keycard published Agent Baseline, an open, vendor-neutral reference architecture that defines security outcomes for running AI agents in the enterprise. It grew out of conversations with industry leaders who want to adopt agents more broadly but need answers to three questions:

What is operating, with what capabilities?

Is it staying inside approved boundaries?

Can you prove what happened and stop it?

Agent Baseline gave the industry a shared frame of reference for secure agent adoption by defining the security outcomes for safely deploying agents in organizations. Last week, we published the Secure Software Factory reference architecture, which applies those outcomes to one of the most common agentic workflows: the AI-powered software factory.

Enter the Secure Software Factory

The Secure Software Factory was written by practitioners from Keycard, Socket, Docker, Tessl, Tracebit, Browserbase and Tailscale and shaped by conversations with security leaders at large enterprises in regulated environments such as finance and insurance.

Over the past year, many engineering teams have started building software factories: systems where agents take a request, change code, run tests and hand the result to a human for review. Teams report faster delivery, but also agents doing things nobody asked for, like escaping sandboxes, dropping databases and pushing to production without approval.

Teams need controls that limit what agents can access and do, and check their work at each step. The Secure Software Factory reference architecture shows how to apply Agent Baseline’s security outcomes across this workflow, covering:

The factory workflow, from inputs through design, assembly, build and verification, with controls at each stage.

Architectural primitives for identity and access, supply chain, network controls, runtime isolation and orchestration.

A maturity model with three levels, so teams can start where they are and improve over time.

The paper’s central idea is that the more autonomy you give an agent, the less you can rely on it to police itself. An agent can be redirected at runtime by a prompt, a poisoned dependency or a malicious tool description. Controls have to work regardless of what the agent decides, which means they need to live in the environment it runs in. That means boundaries around credentials, tools, dependencies and network access, backed by evidence of what happened and a human accountable for the result.

This is the part of the problem Docker solves. Containers isolate applications; sandboxes isolate actors. Docker Sandboxes are isolated MicroVMs that constrain agents, deterministically.

Docker Sandboxes lets coding agents work autonomously in isolated microVM environments, locally or in the cloud, with explicit boundaries around the files, network destinations, and credentials they can access. This supports Agent Baseline’s Constrain outcome by confining agent execution and limiting its reach to what the approved task requires.

Agent Baseline is only useful if the people building the agent stack agree on it. Which is why we are proud to be among leading companies such as Snyk, Keycard, Browserbase, Tessl, Socket and Tracebit, in shaping the baseline and the reference architectures built on it.

More companies are joining Agent Baseline

In a software factory, context is the new code: it’s what actually gets executed. The skills you consume are part of your supply chain, and can be vulnerable, negligent or outright malicious. They need the same security controls software modules do – let’s get it right from the start!

Guy Podjarny, Founder and CEO, Tessl

“We’ve spent decades learning not to give software more access than it needs. We seem to have forgotten much of that now that the software can talk back. Agents need to reach real systems, sometimes even production. The rules haven’t changed: give them the authority to do a particular job, make that authority expire, and keep the policies and audit trail somewhere the agent can’t rewrite them. Agent Baseline gives everyone a common architecture for making that work, without every team having to figure it out from scratch.”

Avery Pennarun, Co-Founder & CEO, Tailscale

“Enterprises are handing AI agents real credentials, and some of those agents will go off-task, whether through prompt injection, a poisoned tool or a simple mistake. Agent Baseline sets the standard for keeping agents in bounds”

Andy Smith, Co-Founder & CEO, Tracebit

“Agents need the right guardrails to complete tasks on behalf of humans. This is an industry wide effort and Browserbase is proud to continue supporting initiatives like Agent Baseline”

Paul Klein, Founder & CEO, Browserbase

“Agents are already building software, and teams want them picking up work on their own. That only works if an agent’s plan can never become its permission. Agent Baseline gives everyone a shared architecture for deciding what each agent may do, task by task and outside the agent’s reach, so teams can add autonomy without starting their security model over.”

Ian Livingstone, Co-Founder & CEO, Keycard

Get involved

Help shape Agent Baseline and the Secure Software Factory reference architecture by putting them to work.

Read the paper, open an issue on GitHub or join the Agent Baseline Slack to tell us where the architecture doesn’t match how you build. Implementation feedback is the most useful kind.
Quelle: https://blog.docker.com/feed/

22. Oktober 2026

da Agency

Your Agent Runs in a Docker Sandbox. Now It Can Join a Team.

Your sandboxed agents just got a team. The official BAND AI kit for Docker Sandboxes is now available at docker.io/bandhq/band-python-kit:latest.

Docker Sandbox kits package everything an agent needs to run in a Docker Sandbox, so a single sbx create command gives you a ready-to-use agent environment. But an isolated agent is only half the story: real work means talking to people and to other agents. The BAND AI kit connects a sandboxed agent to the world. The agent runs on your machine with access to your repository, and joins a BAND room where it collaborates with humans and with agents running anywhere: locally, in the cloud, or on your own infrastructure. The same kit also connects sandboxes to each other, so multiple agents can work together in one room while each keeps its own isolated environment. In this post, we’ll show how a sandboxed agent connects to the world through BAND, using a local agent called Repo Doctor.

BAND provides the collaboration layer for these agents. With BAND, developers can give agents persistent identities, bring them together in shared rooms, route work through @mentions, maintain message history, and surface tool execution events in the room. Each agent brings its own model, framework, tools, workspace, and infrastructure, and joins the room as a participant, wherever it runs.

Docker Sandboxes give that agent an isolated microVM with its own kernel, filesystem, Docker daemon, and network. Inside it, the agent works with local source files, runs commands and tests, and makes changes to a mounted workspace. The BAND kit connects the two with one sbx create command.

All connectivity is outbound. The agent opens a WebSocket to BAND and posts its replies through the BAND API, so nothing needs to reach into the sandbox. From the room’s point of view, it behaves like any other participant.

Repo Doctor in a BAND room

Here’s a neat example of how it all works together. Repo Doctor is a small agent that repairs a deliberately broken Python project. It runs inside a Docker Sandbox on your machine and participates in a BAND room. Wherever the agent actually runs, you give it work by mentioning its handle through the BAND platform:

This example repo includes a band.yaml file that tells the BAND sbx kit which agent to launch. In this example, it points to main.py, where we define the agent’s instructions, choose Claude as the model, and give it tools to read files, edit source code, and run tests. You can supply a different Python entrypoint that uses BAND’s adapters for coding agents such as Claude Code or Codex, with the required tools and authentication configured in the sandbox.

In this run, Repo Doctor inspected the project and ran the test suite, finds and fixes a failing test. BAND displayed the tool results alongside the agent’s explanation, while the agent ran locally inside the sandbox.

Connect agents to BAND from your machine

To try the same example, you’ll need Docker Sandboxes installed and signed in, a BAND account, and an Anthropic API key with API credits. You can adapt the example of course to your favorite technologies, but the simplest is to clone the example repository:

git clone https://github.com/dockersamples/band-ai-sbx-demo.git
cd band-ai-sbx-demo

In BAND, create a remote agent or use an existing one. Note its handle, which you’ll use to mention it in a BAND room. Set agent.id in band.yaml to its agent UUID, and have its BAND API key ready for the next step.

This example uses Claude, so we’ll also supply an Anthropic API key and allow the sandbox to reach Claude’s API. These settings follow from the agent implementation in main.py in the repo; the BAND kit itself does not require a particular model provider. The BAND agent key authenticates the connection to the platform.

Store both keys before creating the sandbox. Each command prompts for a secret: enter the BAND agent key first, then your Anthropic API key.

sbx secret set-custom
–sandbox band-repo-doctor
–host '**.band.ai'
–env BAND_API_KEY
–placeholder proxy-managed

sbx secret set-custom
–sandbox band-repo-doctor
–host api.anthropic.com
–env ANTHROPIC_PROXY_KEY
–placeholder sk-ant-proxy-managed

Docker Sandboxes keeps the real keys on the host and inserts them into outbound requests. The agent sees only placeholder values, and both credentials are scoped to this sandbox.

Now create the sandbox with the BAND kit, allow the Claude API connection, and start the agent:

sbx create –name band-repo-doctor
docker.io/bandhq/band-python-kit:6.0.0 "$PWD"

The kit already permits access to BAND and the Python package hosts. Add access to Claude’s API for this example:

sbx policy allow network –sandbox band-repo-doctor api.anthropic.com

Then start the agent in the prepared sandbox. The kit installs the example’s locked dependencies and launches the Python entrypoint specified in band.yaml. The agent connects to BAND, where you or other agents can communicate with it.

sbx run –name band-repo-doctor

Keep the terminal open while the agent runs. Once the log shows Connected to platform, add Repo Doctor to a BAND room and mention its handle like we did above.

Create a room and add its participants:

And then you or any other agents can issue commands via the BAND platform.

A local agent in a larger BAND team

Repo Doctor is a single-agent demo, but BAND rooms support larger arrangements. A room can contain agents running locally, in the cloud, or on your own infrastructure. They can mention each other, add specialists to a room, work sequentially or in parallel, and return the result to a human participant.

For example, a planner agent can plan a change and ask a research agent to check the relevant API. When the work needs your repository, it mentions Repo Doctor. Only Repo Doctor needs access to the local workspace, so only that agent runs in the Docker Sandbox on your machine. After running the tests, Repo Doctor can @mention a reviewer with the result; the full execution events remain visible to the human in the room. The same pattern works across sandboxes: agents that each need their own isolated environment can run in separate sandboxes and still collaborate in the same room.

BAND room
|– Planner agent (hosted)
|– Research agent (hosted)
`– @<your-user>/repo-doctor
|
v
local Docker Sandbox
|
your workspace

Humans can see the whole conversation. An agent’s context stays narrower because BAND delivers only messages that mention it. Hosted agents can collaborate broadly, with local execution attached to the one participant that actually needs it.

BAND is particularly good at this composition. The local agent is one participant in a larger room, and its peers address it by handle. That saves you from building agent identity, routing, a worker connection back to the laptop, credential handling, and an audit trail before getting to the actual task. The seam between BAND and the sandbox is a WebSocket connection and a room mention, which is about as much integration code as I would like this problem to have.

Getting started with BAND’s SBX Kit

The BAND Python SDK repository contains the SDK and kit sources. The complete Repo Doctor example in the Docker Samples repository includes the agent, fixture, and scripts used to reproduce the screenshots.

Create a sandbox from the published kit, connect the remote agent to a BAND room, and check sbx policy log to confirm its network requests match the policy you intended.

For sandbox kit configuration, credentials, and network rules, see the Docker Sandboxes kit documentation.

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

21. Oktober 2026

da Agency

Advancing digital sovereignty with greater control and choice

Across my conversations with leaders in government, critical infrastructure and regulated industries, one priority consistently rises to the top: putting technology to work on their most important systems while maintaining the control those systems require.

This challenge is becoming more important as advanced cloud and AI capabilities move into public services, regulated processes and essential operations. Organizations are considering more than where data resides. They also seek to understand who can access and operate their systems, how sensitive digital assets remain protected, which technology dependencies matter most and whether critical services can continue as regulatory, geopolitical, security or network conditions change. Digital sovereignty should give organizations greater control and security over the technology they depend on, while continuing to innovate.

Last year, we introduced Microsoft Sovereign Cloud to give customers more choice in how they address these requirements. Since then, we have continued to turn our commitments into practical capabilities across public cloud and customer-operated environments, while expanding how we enable partners to address sovereignty requirements in their local markets. Today, we are sharing the next stage of that work.

A continuum of control, built around the workloadMicrosoft Sovereign Cloud diagram showing a continuum of sovereignty solutions across three areas: Sovereign Public Cloud for control, data protection and regional requirements; Sovereign Private Cloud for critical workloads across connected and disconnected environments; and the Sovereign Partner Ecosystem for trusted, locally operated and specialized solutions.

Our approach to digital sovereignty starts with the workload. Each workload carries different requirements for data, operations, technology dependencies, continuity and risk. Microsoft Sovereign Cloud is designed to make it easier for organizations to apply the appropriate level of control to each workload without forcing every application into the same deployment model.

Those needs can vary widely across organizations. A public-facing digital service may benefit from the scale and pace of innovation in the public cloud. A system supporting essential operations may need to continue running locally if connectivity is disrupted. An AI workload handling highly sensitive data may require models, data and processing to remain within a customer-controlled environment.

Microsoft Sovereign Cloud is designed around this workload-based approach, providing a continuum of management, control and options across Sovereign Public Cloud, Sovereign Private Cloud and the Sovereign Partner Ecosystem. Organizations can apply the level of control appropriate to each workload while maintaining a consistent approach to governance and operations across their digital estate. Sovereign Public Cloud adds capabilities for workloads that require greater control and transparency while continuing to benefit from the scale and innovation of Azure.

Sovereign Private Cloud extends cloud capabilities into customer-operated environments, including connected and disconnected operations. The Sovereign Partner Ecosystem broadens the continuum through independently operated environments, specialized partners, locally relevant expertise and technologies that support customers’ sovereignty requirements.

These are not isolated destinations. Customers can combine public cloud, private cloud and partner capabilities across their digital estate, applying different levels of control to different workloads as their operating needs evolve.

Making control more visible in Sovereign Public CloudFor many workloads, the public cloud provides a combination of scale, innovation, integrated security and compliance. Organizations can benefit from these capabilities while applying additional sovereignty controls for residency, confidentiality, operator access, policy and continuity. Our work in Sovereign Public Cloud makes these controls easier to understand, apply and demonstrate.

Sovereign Control Panel, entering public preview at Microsoft Ignite, brings these signals together in a unified Azure portal experience. It helps organizations understand their sovereignty posture, apply and manage controls, identify gaps and risks and take action to address them. It also supports business continuity readiness by helping customers understand workload dependencies and assess portability across operating environments when required.

This visibility complements controls across the operator-access lifecycle. Just-in-time Access and Customer Lockbox give customers additional control over access to their environments. For customers in the European Union (EU) and the European Free Trade Association (EFTA), we are rolling out Data Guardian, which adds European-resident oversight by a trusted EU partner for qualifying Microsoft engineer remote access to in-scope production systems. Production Touch Ledger, also launched with phased rollout in the EU and EFTA, creates tamper-evident records of that access and the actions performed.

Azure Key Vault Managed Hardware Security Module (HSM) already gives customers dedicated, single-tenant protection and control over the encryption keys used by supported Azure services. Last year, we committed to extending that control beyond Microsoft infrastructure. External key management with Azure Managed HSM is now generally available, allowing customers to keep the root encryption key in hardware they own and operate on-premises or through a trusted third party. This gives organizations another option for workloads that require physical control of key hardware outside Microsoft infrastructure.

Azure confidential computing helps protect supported data while it is processed in a hardware-based and attested trusted execution environment. We are also increasing transparency into the technologies that underpin that trust. Azure Confidential Clean Rooms, now in limited preview, applies confidential computing to approved multiparty collaboration, allowing participants to analyze shared sensitive data while limiting broader exposure of the underlying information.

Together, these capabilities provide additional technical and operational controls that can support a broader digital sovereignty strategy aligned to an organization’s legal, policy, security, resilience and business requirements.

Designing for resilience and operational independenceFor some workloads, digital sovereignty also means maintaining critical operations as connectivity, geopolitical and operating conditions change. Resilience must be designed from the start so essential workloads can continue operating through disruption.

To help customers prepare for these scenarios, we are publishing new sovereign business continuity guidance and architecture patterns. These resources help organizations translate resilience requirements into architectures they can plan, implement and test before they are needed.

For many workloads, the scale and geographic reach of the public cloud provide a strong foundation for resilience across locations and operating conditions. For workloads that require greater operational independence, Sovereign Private Cloud extends that continuum into customer-operated environments. It supports connected and disconnected operating models. The ability to transition workloads from connected to disconnected operations is entering public preview, giving organizations greater flexibility to sustain critical services as connectivity and operating requirements change.

Bringing more of the application lifecycle under local controlOperational independence requires more than infrastructure. Increasingly, organizations need data, development tools, model capabilities and productivity services their applications depend on to operate within the same customer-controlled environment.

Sovereign Private Cloud, built on Azure Local, extends Microsoft cloud capabilities into environments that customers operate and control. SQL Server on Azure Local is already generally available for connected and disconnected deployments. DocumentDB and Blob Storage on Azure Local are both entering public preview, giving organizations more choice in how they run and manage critical data within customer-controlled environments.

GitHub Enterprise Local will become generally available at Microsoft Ignite as a validated GitHub Enterprise Server appliance on Azure Local, helping organizations keep repositories, code and development artifacts under local control. Developers can also use GitHub Copilot with locally hosted models for inference, bringing AI-assisted development closer to their code and data within the environments they control.

The local application environment is expanding with Foundry Local. At Ignite, Foundry Local will become generally available for connected and disconnected operations on Azure Local, with an expanded model catalog that includes Microsoft, partner, open-weight and open-source models. Local inference and agentic retrieval will also enable users to interact with local enterprise data using natural language and receive responses grounded in that data. Integration with Microsoft 365 Local, available in preview for approved customers, extends this functionality to locally operated Microsoft SharePoint and Exchange servers.

Confidential virtual machines on Azure Local are generally available, extending confidential computing capabilities to customer-controlled infrastructure. Hardware-encrypted memory and hardware-based isolation help protect sensitive data while it is being processed. Workload attestation adds assurance before sensitive data or keys are released. For regulated, sensitive and mission-critical workloads, these safeguards provide another layer of protection while giving organizations greater control over where their data and applications run.

Azure Local will support multitenancy, allowing organizations to separate resources, governance and management across multiple tenants while sharing the underlying infrastructure. This significantly expands what customers with distinct business units or security boundaries can achieve with Sovereign Private Cloud. Multitenancy also creates new opportunities for local operators and service providers to deliver differentiated sovereign cloud services on Azure Local infrastructure.

These additions bring more of the application lifecycle under local control, spanning data, development, productivity, AI and operations. Organizations can determine what runs locally based on the requirements of each workload.

Extending the continuum through partnersGraphic titled “Sovereign Partner Ecosystem” with the subtitle “National clouds · Software · Services · Platform co-innovation,” showing 31 partner logos: Accenture, AMD, Armada, Avanade, base-it, Bleu, Capgemini, Cirrus Data, CloudCasa by Catalogic, Cronos Groep, cTelecoms, DataON, Delos Cloud, Dell Technologies, F5, Felo, Fortinet, HPE, Inspark, Intel, Mattermost, Mistral, NVIDIA, Qualidev, Qumulo, RiverMeadow, Rubrik, Supermicro, Tata Consultancy Services (TCS), Veeam and WSO2.

Navigating sovereignty is increasingly complex. Regulatory, security, operational and business requirements vary across countries, industries and workloads. Organizations must translate these needs into technology and operating models that work in their local context. Meeting these needs often requires a combination of technology, local operating authority, sector expertise and specialized solutions.

The Sovereign Partner Ecosystem broadens the ways customers can address these requirements. National Partner Clouds, including Bleu Cloud in France and Delos Cloud in Germany, provide independently operated environments for customers that require a different ownership and operating model. Software partners can enhance Azure Local environments with capabilities across security, identity, observability, backup and recovery, migration, data, networking and applications. Digital sovereignty specialized partners combine Microsoft technologies with local knowledge and implementation expertise. Platform co-innovation partners expand infrastructure choice from datacenter to the edge.

This ecosystem gives customers the flexibility to combine technology, operating models and trusted expertise based on the requirements of each workload.

The next chapter of digital sovereigntyAI is amplifying both the opportunity and the impact of technology choices. As AI systems and agents interact with sensitive data, business processes and essential infrastructure, they also expand the security considerations organizations need to manage. Organizations need clear control over where these systems run, who can operate them, what actions they can take and how critical services continue when conditions change.

Microsoft Sovereign Cloud brings these choices together as a continuum of control across the public cloud, customer-operated environments and our partner ecosystem. It gives organizations the flexibility to apply the appropriate level of control to each workload while continuing to benefit from cloud capabilities and ongoing innovation.

We will continue to expand this continuum so organizations can innovate with cloud and AI while maintaining the control, confidentiality, resilience and operational authority their most important workloads require.

Douglas Phillips leads global engineering efforts for Microsoft’s specialized, sovereign and private clouds. He is responsible for Microsoft’s global strategy, products and operations that bring Microsoft’s industry-leading solutions, including Azure, our adaptive cloud portfolio and Microsoft 365 collaboration suite, to customers with additional sovereignty, security, edge and compliance requirements.

Learn more

Microsoft Sovereign CloudSovereign Landing Zone architecture guidanceSovereign Public Cloud Tech Community blogSovereign Private Cloud Tech Community blog
The post Advancing digital sovereignty with greater control and choice appeared first on Microsoft Azure Blog.
Quelle: Azure

21. Oktober 2026

da Agency

Announcing Amazon ECS Gateway, a managed ingress solution for your ECS services

AWS announces Amazon Elastic Container Service (Amazon ECS) Gateway, a new resource that simplifies ingress networking for containerized applications by dynamically provisioning and managing Application Load Balancers (ALBs) and their supporting resources directly in your account.
With ECS Gateway, platform teams define organizational networking standards once on a gateway and associate it with one or more clusters, giving organizations a centralized way to govern how traffic reaches their ECS services. Application teams simply opt in to inherit those standards without requiring networking expertise. ECS Gateway offers host-based routing, allows up to 25 services to share an ALB to optimize infrastructure costs, and gives each service a unique Domain Name System (DNS) hostname. ECS manages the full lifecycle of the underlying infrastructure, provisioning the first ALB when your first service connects, adding more ALBs when capacity is reached, and removing them when no longer needed. You can inspect these resources and the gateway route to each service to see exactly how requests reach your applications. For traffic and health monitoring, you can use standard ALB metrics in Amazon CloudWatch and target health information from Elastic Load Balancing.
To get started, create an ECS Gateway, associate it with a cluster, and opt in your ECS service by adding the gateway connector parameter using the AWS Management Console, AWS CLI, API, AWS SDKs, or AWS CloudFormation. ECS Gateway is available for ECS services using the awsvpc network mode across all launch types. It is available now in all commercial AWS Regions at no additional charge. You pay only for the underlying infrastructure provisioned in your account when your services connect to the gateway. To learn more, refer to the AWS News blog and our documentation page.
Quelle: aws.amazon.com