Zahlungsdienstleister: Zwei Firmen wollen Paypal für über 53 Milliarden US-Dollar kaufen
Das Übernahmeangebot für Paypal durch Stripe und Advent liegt knapp 30 Prozent über dem Börsenwert des Unternehmens. (Paypal, Onlineshop)
Quelle: Golem
Das Übernahmeangebot für Paypal durch Stripe und Advent liegt knapp 30 Prozent über dem Börsenwert des Unternehmens. (Paypal, Onlineshop)
Quelle: Golem
26 Meta-Angestellte haben nach Krankheit oder Geburten nur eingeschränkt gearbeitet und wurden trotzdem gekündigt – dank KI? (Meta, KI)
Quelle: Golem
Ein akkubetriebener Smartspeaker soll OpenAIs Hardware für das KI-Zeitalter sein. Eine Klage von Apple könnte die Pläne durchkreuzen. (OpenAI, Apple)
Quelle: Golem
Der Fanttik T1 Max bietet kabellosen Betrieb, kurze Aufheizzeit, sechs Stufen und war dieses Jahr bei Amazon noch nicht günstiger. (Technik/Hardware, Computer)
Quelle: Golem
We spent the week at AI Engineer World’s Fair in San Francisco, on stage and on the floor. Here’s what we heard, and where we think it lands for anyone building with agents.
The SDLC is being rebuilt in public
This week at AIE felt like a synthesis of what’s been playing out in developer tools for the last few years, for anyone who’s been watching. The software development lifecycle is reshaping itself into an AI-native SDLC, and the industry is naming the new jobs and developer concerns that come with this rapid transformation.
The proof was in the track list: Evals, Context Engineering, Harness Engineering, Memory, Sandbox & Platform Engineering, Inference, plus a whole thread on “software factories.” Two years ago most of these phrases were far from being thought of as categories. Now each one is a discipline with its own sessions, its own vocabulary, and its own crop of companies on the expo floor built to solve that single problem.
So what were most talks about? A little bit less of “can agents and AI do this,” and more of “given this way of building, what decisions and trade offs do we need to think about?” Evals, loops, harnesses, context, memory, isolation, cost. None of this is brand-new, but it’s all getting a whole new level of mindshare, as developers work out the new shape of creating software with AI. Even the model labs spent much of their stage time on how you build with the model: the integration API, the harnesses, the ergonomics, rather than the model itself.
The job we care most about: securing where agents run
Of all those emerging disciplines, sandboxing is the one that hit critical mass this year. There was a full track dedicated to sandbox and platform engineering, and the sessions inside it were still working out what a sandbox should even be: full VM, lightweight runtime, Kubernetes, something purpose-built. Talks focused on concerns such as running agentic sandboxes at scale and comparing isolation technologies head to head.
This is the job Docker showed up to talk about, across three sessions.
Give agents more freedom by giving them less surface
Our EVP of engineering, Tushar Jain, gave the mainstage talk: “Unlock Agent Autonomy: The Runtime for AI-Native Systems.” The actors have changed – agents read and write whole codebases, spawn subagents, install dependencies, and call APIs across laptops, CI, cloud, and org boundaries, often unsupervised. Teams leaning into this shift are moving fast, but most organizations still won’t let agents run autonomously, not because the model isn’t capable, but because trust isn’t there yet. This thinking draws on a concept security researcher Simon Willison has written about, the “lethal trifecta”: any useful agent tends to end up with access to private data, exposure to untrusted content, and the ability to act in the outside world, all three, by design. No prompt or policy doc gets rid of that. The durable fix lives one layer down, at the runtime, which is where we spent the last decade: isolation, network policy, trusted images, credentials. Agents are just the next workload.
An agent doesn’t have to be malicious to be dangerous
Rowan Christmas, a staff product manager at Docker, made the risk concrete. In “YOLO Mode, Safely: microVM Sandboxes for Any Agent,” he ran a coding agent on his own laptop with nothing but read access, and no sandbox or unusual permissions. Within a few minutes it had pieced together a surprising amount about his online banking activity from what it could passively see. A destructive command like rm -rf is the obvious fear, but the mundane can bring risk: read access, plus untrusted content, plus the ability to act, is already enough to do damage. An agent doesn’t have to be malicious to expose you. It just has to be able to see. The alternative Rowan showed puts each session in its own Docker sandbox based on a microVM, with a boundary you define across filesystem, network, and tools. It can run Claude Code, Cursor, Codex, or whatever you’re driving.
Once an agent can install packages, run Docker, and reach the network, which describes most genuinely useful agents, a hardware boundary buys you something you can’t easily bolt on later. And where much of the scale conversation is cloud-first, built for fleets of agents running server-side, Docker’s approach starts first on the laptop the developer already uses, because that’s where most people actually run agents today. (We go deeper on the reasoning in “Why microVMs” and our comparison of sandboxing approaches, including what the isolation costs you, because it isn’t free.)
Nobody’s reviewing what your agents just installed
The third talk covered the tool layer. Jim Clark, a principal software engineer on our MCP team, spoke about “Who Approved That MCP Server? Governing the Tool Layer,” and opened with a line that got knowing laughs: “shadow MCP”. Developers install MCP servers faster than security can review them, and an unvetted server is a direct line to your data. That worry was all over the event, not just our session. Jim’s demo put every server behind one org-managed catalog, vetted, signed, default-deny on anything unapproved, with the policy enforced live on stage.
Where this leaves us
So how does it come together? An agent is only as trustworthy as the boundaries around it, and those boundaries live in three places: what it builds on, where it runs, and what it can reach. Miss any one of them and the other two won’t cover for you. A hardened image dependency is no help if the agent can still read your whole filesystem unsandboxed, and a locked-down sandbox is no help if the agent can call an unvetted MCP server straight out of it.
That was the case Docker made all week: harden what agents build on, isolate where they run, control what they can reach, and govern all three from one place. We think this is the part that has to be solved first, because it’s where AI-native developers will start building the apps of the future.
Further reading:
Docker Sandboxes run standalone (brew install docker/tap/sbx)
Docker AI Governance ties sandbox and MCP policy into one console.
MCP Catalog, Toolkit, and Gateway are in Docker Desktop today
Docker Hardened Images are a drop-in change to your FROM line
Quelle: https://blog.docker.com/feed/
AWS Storage Gateway now allows you to copy file shares across gateways directly from the Storage Gateway console. When you initiate a copy, the console reads the configuration of your source share and creates a new file share on the destination gateway with compatible settings preserved.
Previously, you had to manually recreate each file share on the destination gateway and re-enter configuration details one by one. Now you can copy a file share and have its configuration automatically applied to a destination gateway, significantly reducing the time and effort required for migrations such as upgrading to AL2023. A guided experience surfaces any configurations that require your attention before the new share is created, helping ensure a smooth transition without missing critical settings.
To get started, navigate to your file shares in the Storage Gateway console, select a share, and choose Copy to gateway. This capability is available in commercial AWS Regions. To check regional availability, see AWS Capabilities. For more information, visit the AWS Storage Gateway User Guide.
Quelle: aws.amazon.com
Today, AWS announces that AWS Security Hub now provides an AI inventory, giving central security teams a continuously updated, organization-wide view of AI assets and their security posture. As organizations rapidly deploy AI agents, models, and pipelines, security teams may lack visibility into what AI assets exist across their organization. Without centralized visibility connecting AI assets to active threats and misconfigurations, organizations cannot secure what they don’t know exists.
Security Hub AI inventory automatically discovers and catalogs AI workloads across your AWS environment through three discovery methods. For managed AI services, Security Hub inventories AWS Config resources from Amazon Bedrock, Bedrock AgentCore and Amazon SageMaker, with no additional configuration. For self-hosted AI workloads, Security Hub leverages the software bill of materials (SBOM) analysis from Amazon Inspector, which has been enhanced to identify inference endpoints, models and AI agents installed on Amazon EC2 instances and Amazon ECR container images, including frameworks such as Ollama, vLLM, Hugging Face TGI, and others. Security Hub also leverages Amazon GuardDuty DNS telemetry to discover external AI API endpoints (such as calls to third-party model providers) being accessed from your EC2 instances, revealing third-party AI dependencies that may not have been previously identified.
Each discovered AI asset is mapped to its underlying infrastructure and correlated with security findings from across the AWS security stack, including threat findings from Amazon GuardDuty. Teams can filter, group, and query their AI inventory by account, resource type, discovery method, and specific model identity, enabling them to prioritize remediation based on which AI workloads are actively under threat and carry the highest organizational risk.
AI Inventory is included with Security Hub Essentials at no additional cost and requires no new enablement. It is available in all AWS commercial Regions where Security Hub is offered. To learn more, see the AWS Security Hub User Guide and the AWS Security Hub product page.
Quelle: aws.amazon.com
Starting today, Amazon Aurora DSQL is available for single-Region clusters in the Europe (Spain) Region. Aurora DSQL is the fastest serverless, distributed SQL database, with active-active high availability and multi-Region strong consistency. It enables you to build always-available applications with virtually unlimited scalability, the highest availability, and zero infrastructure management, making scaling and resilience effortless for your applications.
With this launch, Aurora DSQL is available in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Canada West (Calgary), South America (São Paulo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Spain), Europe (Stockholm), Asia Pacific (Hong Kong), Asia Pacific (Melbourne), Asia Pacific (Mumbai), Asia Pacific (Osaka), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo). Get started with Aurora DSQL for free with the AWS Free Tier. To learn more, visit the Aurora DSQL webpage and documentation.
Quelle: aws.amazon.com
Amazon WorkSpaces Personal now provides automated rollback and support for PCoIP to DCV protocol migration of stopped WorkSpaces, building on the recently launched console-based migration workflow and checkpoint snapshot support. These new capabilities enable administrators to migrate WorkSpaces at scale with minimal manual intervention. Amazon DCV is a high-performance streaming protocol built by AWS that powers Amazon WorkSpaces services. By migrating to DCV, customers gain access to broader operating system support including Windows 11 and Windows Server 2025, enhanced security features such as certificate-based authentication and WebAuthN redirection, and improved streaming performance. With this launch, if a protocol modification fails, the WorkSpace automatically rolls back to the pre-migration snapshot, ensuring it returns to a known healthy state without manual intervention. Additionally, administrators can now initiate migration for WorkSpaces in a stopped state, removing the need to manually start each stopped WorkSpace before modifying its protocol. This helps customers significantly speed up large scale migrations. These enhancements are available in all AWS commercial and AWS GovCloud (US) Regions where Amazon WorkSpaces Personal is supported. To get started, sign in to the Amazon WorkSpaces console. For more information, see Modify protocols section in the Amazon WorkSpaces Administration Guide. To learn more about Amazon WorkSpaces, visit the Amazon WorkSpaces product page.
Quelle: aws.amazon.com
Amazon GuardDuty now offers AI Protection, expanding threat detection to AWS AI services including Amazon Bedrock and Amazon SageMaker. As organizations rapidly adopt AI, security teams may lack visibility into threats specifically targeting AI workloads, such as anomalous model invocations, cost harvesting attacks, and prompt injection attempts. GuardDuty AI Protection continuously monitors these workloads so security teams can detect and respond to AI-specific threats without manual configuration or custom tooling.
GuardDuty AI Protection analyzes both CloudTrail management and data events from AWS AI services to identify suspicious activity, including unusual invocation patterns, cost harvesting attacks where threat actors force AI resources to consume excessive GPU time and tokens, and prompt injection attempts through integration with Amazon Bedrock Guardrails. Threat findings flow directly into AWS Security Hub, giving teams a single view of AI assets and threats for prioritized response. GuardDuty AI Protection can be enabled with a few steps in the GuardDuty or Security Hub console, and using AWS Organizations, can be centrally enabled for all accounts in an organization.
GuardDuty AI Protection is available to GuardDuty customers with a 30-day free trial. For pricing details, visit the Amazon GuardDuty pricing page. To learn more, see the Amazon GuardDuty User Guide and the Amazon GuardDuty product page. For the full list of supported Regions, see the AWS Regional Services List.
Quelle: aws.amazon.com