Microsoft found a way for one web page to hijack an AI agent and run code on your machine
In June 2026, Microsoft's own researchers disclosed AutoJack, a vulnerability chain in AutoGen Studio, the open-source prototyping interface for Microsoft Research's AutoGen multi-agent framework. When an AI web-browsing agent loaded an attacker-controlled page, the page's JavaScript could reach a privileged local service the agent relied on and spawn arbitrary processes on the host, full code execution under the account running the agent, with no login and no further user interaction once the agent opened the page. The flaw was found by research, not exploited in the wild, and per Microsoft the affected code was never shipped in a released package; only developers who built the tool from its main source branch were exposed, and the project was patched. It is a clean illustration of why an agent that browses untrusted content while holding local power is a hazard by design.
Incident Details
Tech Stack
References
Here is the nightmare in one sentence: you point your helpful AI agent at the web, it opens a page somebody built to trap it, and a few seconds later a stranger is running commands on your computer. No password prompt, no "allow this" dialog, no second click. That is AutoJack, and the people who found it work at Microsoft, which is also the company that ships the software it affects.
Setup
The target is AutoGen Studio, the open-source, point-and-click interface for AutoGen, Microsoft Research's framework for building multi-agent AI systems. It is the kind of tool a developer uses to prototype agents quickly: wire up a model, give it some abilities, let it loose. One common ability is web browsing, where the agent fetches and reads pages on your behalf so it can answer questions or gather information.
Browsing is exactly the capability that turns an agent from a sealed box into something exposed to the outside world. The moment your agent reads a page you did not write, it is processing untrusted content, and untrusted content is where attacks live.
The chain, in plain terms
AutoJack stitches together three weaknesses into one smooth ride from "agent visits a web page" to "attacker runs code on the host."
First, the browsing agent runs locally, on your machine, which means traffic it generates looks like it is coming from your own computer. A lot of software trusts requests that originate locally, on the assumption that anything running on your machine is already you. The agent inherits that trust. So when the malicious page's JavaScript fires off requests, they arrive wearing the agent's local identity and sail past the origin checks that are supposed to keep outside web pages from talking to local services.
Second, the local service the agent depends on, a privileged channel built on the Model Context Protocol that lets agents call tools, had no authentication on it. It answered to whoever could reach it. Combine that with the first flaw, and a web page can now reach a powerful local endpoint that assumed only trusted callers would ever find it.
Third, that endpoint passed attacker-supplied values into shell commands without safely handling them, so an attacker who could talk to it could get the host to execute commands of their choosing. End to end: the page reaches the local service because it looks local, the service answers because it checks nobody, and the service runs the attacker's commands because it sanitizes nothing. Full code execution under the account running the agent, and crucially, no further interaction is needed once the agent has loaded the page. The victim's only mistake is having an agent that browsed somewhere it should not have.
Reasons not to panic
This is a hazard, and an honest writeup says so clearly rather than dressing a near-miss up as a catastrophe. Several facts keep AutoJack on the right side of the line.
It was found by Microsoft's own security researchers, not by attackers, and there is no evidence anyone exploited it in the wild. Per Microsoft, the affected service was never included in a released package; the exposure was limited to developers who built AutoGen Studio from its main source branch, which was hardened once the issue was identified. So the realistic blast radius was the relatively small population of people running a from-source build and pointing an agent at arbitrary web pages, not the entire user base.
In other words, the system mostly worked the way responsible disclosure is supposed to: the people who build the thing found the hole, the dangerous code never reached most users, and it got fixed. Reported here as what it is, a documented near-miss with a fully described attack path, not a breach.
Why it still matters
The reason AutoJack is worth filing is that it is a textbook demonstration of the structural problem with agents, not a freak bug. Strip away the specifics and the lesson is general: an AI agent that can browse untrusted content while also holding local power is a prompt-injection and code-execution risk by its very architecture. The browsing capability hands attackers an input channel. The local privileges hand them a payoff. The agent's habit of looking trustworthy to local services hands them the bridge between the two.
This is the same lethal-trifecta logic that security researchers keep warning about, made concrete. Untrusted input, plus access to something powerful, plus a path to act on it, equals exploitable, and "it is just reading a web page" is precisely the assumption that gets people hurt. The agent does not have to be tricked into wanting to harm you. It only has to faithfully process a page whose content was written to abuse the plumbing around it.
The fix in this specific case was the usual security hygiene: authenticate the local endpoint, do not let web origins masquerade as local callers, and never pass untrusted values into a shell. The broader fix is to stop treating "my agent can browse the web" as a free convenience. It is a doorway, and AutoJack is a reminder that someone is always going to build a room on the other side of it.
Discussion