Microsoft security researchers have detailed an exploit chain that turned a malicious webpage into a remote-code-execution path on a machine running an AI browsing agent and an AutoGen Studio development build. The technique, which Microsoft calls AutoJack, does not affect the current PyPI release of AutoGen Studio, but it gives agent builders a concrete warning: localhost is no longer a safe trust boundary when an agent can browse untrusted pages and talk to local control services.
The research published June 18 by Microsoft Defender Security Research centers on AutoGen Studio, the prototype UI for Microsoft Research’s AutoGen multi-agent framework. In the vulnerable development branch, a browser-equipped agent could be steered to an attacker-controlled page, the page could open a WebSocket connection to a local Model Context Protocol endpoint, and AutoGen Studio could be made to spawn an attacker-supplied command under the developer’s account.
Microsoft reported the behavior through the Microsoft Security Response Center, and AutoGen maintainers hardened the upstream main branch in commit b047730. The most important caveat is exposure: Microsoft says the affected MCP WebSocket route never shipped in a Python Package Index release. Developers who install autogenstudio from PyPI, currently version 0.4.2.2, are not exposed to this specific chain. The narrower risk was for developers who built AutoGen Studio from the main GitHub branch during the window after MCP support landed and before the hardening commit.
How AutoJack crossed the local boundary
The chain matters because each piece reflects a common shortcut in developer tools. AutoGen Studio’s MCP WebSocket accepted only origins such as http://127.0.0.1 and http://localhost, which would normally block a human user’s browser tab opened to a malicious site. But an AI agent running a headless browser on the same workstation changes the assumption. If the agent loads hostile JavaScript, the browser is already local, and the request can satisfy localhost-based checks even though the content came from outside.
The second issue was authentication coverage. AutoGen Studio’s middleware supported modes such as GitHub, Microsoft Authentication Library, and Firebase, but WebSocket-style paths including /api/mcp/* were skipped so those routes could handle their own checks. Microsoft found that the MCP WebSocket handler did not add the missing enforcement, leaving the route reachable regardless of the broader authentication mode.
The third step made the chain executable. The WebSocket route accepted a server_params query parameter, decoded it into MCP StdioServerParams, and passed the resulting command and arguments to an MCP stdio client. Without an executable allowlist, the same mechanism meant for launching MCP servers could launch ordinary system commands. In Microsoft’s local proof of concept, a webpage rendered by a browsing agent opened the local WebSocket URL and caused AutoGen Studio to start calc.exe. On a real workstation, the process would run with the privileges of the AutoGen Studio process.
Why this is bigger than AutoGen Studio
Microsoft’s post is careful not to frame AutoJack as an emergency patch story for typical AutoGen Studio users. The more durable lesson is about the pattern. Agentic applications often combine a browser, model output, local tools, credentials, file access, debug ports, code execution, MCP servers, and prototype dashboards on the same developer machine. Controls that were adequate for a human-operated browser can fail when a local agent becomes the thing navigating, rendering, clicking, and calling APIs.
That makes localhost a meaningful attack surface. A service bound to 127.0.0.1 may be unreachable from the wider internet, but it can still be reachable from an agent process that renders untrusted web content on the same host. The attacker does not need a browser memory-corruption bug if the agent can be induced to load a page whose script talks to a privileged local control plane.
The issue also lands at an awkward time for teams experimenting with MCP. The protocol is becoming a common way to connect agents to tools and data sources, but MCP servers frequently sit close to sensitive developer capabilities: shells, databases, file systems, ticketing systems, cloud APIs, and internal services. That does not make MCP unsafe by default. It does mean the surrounding control plane needs ordinary security engineering: authentication on every route, explicit authorization, command allowlists, isolated execution, and telemetry that treats agent-driven actions as potentially attacker-influenced.
What maintainers changed
The upstream fix moved MCP connection parameters out of the WebSocket URL. In the hardened branch, a separate POST route stores parameters server-side and ties them to a UUID, while the WebSocket handler rejects unknown session IDs. The middleware skip list was also tightened so MCP routes go through the normal authentication path instead of bypassing it. Those changes remove the most direct AutoJack path: an arbitrary page can no longer hand AutoGen Studio a base64-encoded command line through the WebSocket query string.
For teams running AutoGen Studio from PyPI, Microsoft’s guidance is mostly about avoiding the class of failure rather than rushing a version upgrade. AutoGen Studio should be treated as a developer prototype, not an internet-facing service. Experimental builds should run in an isolated development environment, under a low-privilege account, preferably in a container, VM, cloud dev box, or disposable sandbox when browsing untrusted pages or testing code-execution tools.
Practical checks for agent builders
Teams building agent apps on AutoGen or similar frameworks should start by listing every local service an agent can reach from the host where it runs. That includes WebSocket routes, REST endpoints, MCP servers, debug dashboards, local databases, browser automation ports, code interpreters, and any service that assumes loopback equals trusted. Each of those endpoints should require authentication and should authorize the specific action being requested, not merely accept traffic because it came from the same machine.
High-risk primitives deserve extra friction. If an agent can launch a process, write files, read secrets, reach internal URLs, or call a cloud admin API, those actions should be allowlisted and logged. MCP server launchers should accept known server definitions rather than raw command and argument strings from a caller. Browsing agents should not share an operating-system identity with a developer’s daily account if they are expected to read arbitrary webpages.
Security teams can also hunt for the behavior AutoJack demonstrates. Microsoft suggests looking for suspicious child processes spawned by AutoGen Studio or related Python and Node processes, local WebSocket requests to MCP routes carrying command-like parameters, and browser-automation sessions that navigate to unfamiliar domains while an agent framework is running. If those signals appear during an agent experiment, the safer assumption is that the developer environment may have been compromised and that local credentials, API tokens, and source repositories need review.
AutoJack’s specific AutoGen Studio bug was caught before a packaged release. That is a good outcome. The more important result is that Microsoft has put a concrete shape around a new class of AI-agent risk: the model does not have to exploit the browser if it can be tricked into carrying the attacker’s page to a powerful local tool.
