As someone who has spent decades running infrastructure, I have learned that the most dangerous assumptions are the ones that used to be reasonable. "Nobody can reach this internal service" was a fine assumption when your office had a perimeter. "Localhost traffic is trusted" was fine when the only code running locally was code you wrote yourself.
On June 18, 2026, Microsoft's security researchers published a detailed disclosure of something they named AutoJack. It is a three-vulnerability exploit chain targeting AutoGen Studio—Microsoft Research's open-source prototyping interface for multi-agent AI workflows. The chain is elegant in the way that the best bugs always are: three individually unremarkable weaknesses, each defensible in isolation, that stack into something genuinely alarming. One malicious webpage. One running AI agent. One shell on your developer machine.
What AutoJack Actually Is
AutoGen Studio is a local web UI that sits on top of Microsoft's AutoGen multi-agent framework. You run it on your development machine to design, test, and iterate on multi-agent workflows—think of it as a workbench for assembling AI agents. In its pre-release builds (specifically 0.4.3.dev1 and 0.4.3.dev2), Studio added support for MCP (Model Context Protocol), which lets external tools connect to agents via a WebSocket endpoint at ws://localhost:8081/api/mcp/ws/.
Here is the chain Microsoft's researchers built:
Weakness 1 — Localhost origin bypass
The MCP WebSocket checked the Origin header against an allowlist: http://127.0.0.1 and http://localhost. The assumption was that only local, trusted traffic would carry those origins. But a browsing agent—an AI agent with a web browser tool—runs locally. When it visits a webpage and that page's JavaScript opens a WebSocket connection, the connection originates from localhost. The attacker's page passes the check as cleanly as Studio's own front end.
Weakness 2 — Missing authentication on MCP routes
AutoGen Studio supports multiple authentication modes: GitHub OAuth, Microsoft's MSAL, Firebase. The auth middleware was correctly wired up—except it explicitly skipped /api/mcp/* paths, under the assumption that the MCP handler would enforce its own token verification. The handler never did. Every MCP WebSocket connection was accepted unauthenticated, regardless of which auth mode was configured.
Weakness 3 — Unrestricted command execution
The WebSocket endpoint accepted a server_params URL query parameter containing base64-encoded JSON with command and args fields. Those fields were passed directly to stdio_client()—a function that spawns a subprocess. No allowlist. No sanitization. You could send {"command": "powershell.exe", "args": ["-Command", "..."]} and Studio would execute it under the developer's local account.
The attack flow, laid out plainly:
- Attacker hosts a webpage containing a WebSocket call to
ws://localhost:8081/api/mcp/ws/?server_params=<base64_payload> - A developer's AI browsing agent navigates to that page—via a planted link, a document the agent was asked to summarize, or direct prompt injection
- The page's JavaScript opens the WebSocket; the localhost origin check passes
- Studio spawns whatever binary the payload specified, under the developer's account
No user clicks required. No user interaction beyond the agent doing exactly what it was built to do. As the researchers put it: "Chain these together with a webpage on the open internet, rendered by an AutoGen agent running on the same machine, and you have a remote code execution primitive."
Who Is Actually Affected
Scope matters, and the scope here is narrower than the headlines suggest—but the pattern is far wider, and that distinction is the whole point.
The vulnerable code never shipped in a stable PyPI release. autogenstudio 0.4.2.2—the current production package—does not contain the MCP WebSocket route at all. Only the two pre-release builds (0.4.3.dev1 and 0.4.3.dev2) carried the vulnerable handler. As of the disclosure, both remain on PyPI unyanked, so developers who installed dev or pre-release versions should act now.
Microsoft's fix landed in commit b047730 on the upstream GitHub main branch. The patch makes two structural changes: command parameters are no longer read from URL query strings (they are now stored server-side behind one-time session tokens), and the MCP paths are removed from the authentication middleware skip-list. If you are tracking the pre-release builds, pull from main at or after that commit.
Localhost Is No Longer a Trust Boundary
Here is where I want to spend some time, because "one vulnerable pre-release dev tool" is not the actual story.
The assumption that localhost is a trust boundary is deeply embedded in how developer tooling is built. It was reasonable for most of software history. The only code running locally was the code you installed. The only things that could open connections to localhost services were browsers you controlled and applications you trusted.
AI agents with browsing capability break this model completely. A browsing agent that processes untrusted web content is, by definition, bringing attacker-controlled code inside the perimeter. The agent's browsing context runs locally. When that content executes JavaScript, that JavaScript has the same origin relationship to localhost services that a local browser tab would have.
MCP amplifies the exposure. Model Context Protocol was designed to let AI agents talk to external tools through a standardized interface—and it is a genuinely useful abstraction, one I use extensively in my own work. But the protocol, and the tooling ecosystem built around it, was largely designed with the assumption that MCP servers are either remote (and secured at the network layer) or local (and therefore trusted). When the client consuming those tools is an agent that browses arbitrary web content, an unauthenticated local MCP WebSocket is not a convenience. It is an attack surface.
And local MCP servers with open WebSocket endpoints are everywhere now. Any developer who has set up Claude Desktop integrations, Cursor's MCP tooling, or their own agent framework has local MCP processes running. Most were built with the implicit assumption that only trusted code would reach them. Microsoft's researchers said it directly: "This vulnerability pattern likely exists in other agent frameworks: local services with excessive privilege, localhost treated as security boundary, and agents accessing untrusted web content."
I would go further. This is not a vulnerability in AutoGen Studio. This is a vulnerability class, and the AI tooling ecosystem has barely started auditing for it.
What to Do Right Now
I run a fairly extensive local AI development environment. After reading the AutoJack disclosure, I spent time auditing what was listening on my localhost. The results were not comfortable. Multiple MCP servers, several running with no authentication, all under the assumption that only my editor and my own agent runtimes would ever connect.
Here is what I am doing, and what I would recommend:
- Isolate browsing agents from privileged local services. If you are running agents with web browsing capability—anything that renders external URLs and executes JavaScript—those agents should not share a host with local services that have broad execution rights. Separate containers or VMs for web-browsing workloads are the right answer. Yes, it adds friction. Less friction than a shell on your dev machine.
- Audit your localhost surface. On macOS or Linux:
lsof -i -P -n | grep LISTEN. On Windows:netstat -ano | findstr LISTEN. For anything you recognize as an MCP server, ask: does it require authentication? Does it allowlist the commands it will execute? Does it restrict origins beyond the localhost check? - Treat MCP authentication as non-optional from day one. The "we'll add auth later" assumption is exactly what created this hole. If you are building agent infrastructure that exposes local MCP endpoints, require authentication in the first version.
- Stop tracking pre-release AI tool builds for production-adjacent work. Stable
0.4.2.2was unaffected. The two pre-release builds that carried the vulnerability were explicitly marked as development versions. Chasing new features in fast-moving AI tooling repositories is understandable—I do it too—but it means you are carrying surface area that stable releases do not have.
The Pattern We Are Going to Keep Seeing
We are in a period where AI tooling is being built faster than the security threat model for that tooling is being developed. AutoJack is one example. Earlier this year, Microsoft's researchers published a broader survey of RCE vulnerabilities in AI agent frameworks—the attack surface is wide and the mitigations are still catching up.
The agentic model is powerful precisely because agents can take actions in the world: browse websites, execute code, call APIs, read files. That action-taking capability is also, obviously, an attack surface. When we design systems that act autonomously on behalf of users, we need to think carefully about what those systems can be induced to do when they encounter adversarial content.
The localhost trust assumption is one piece of this. Prompt injection—where malicious content in the agent's environment instructs it to take harmful actions—is another. Supply chain attacks on the MCP servers agents connect to are a third. The common thread is that agentic AI systems inherit the threat model of any autonomous actor that processes untrusted input, and we need to design for that from the start.
AutoJack is a clean, well-documented example of what happens when we do not. I am glad Microsoft's researchers found it and wrote it up in detail. Now the work is making sure the rest of the ecosystem absorbs the lesson before someone else finds the next one the hard way.