Microsoft Showed How One Web Page Can Turn an AI Agent Into Code Running on Your Laptop

An AI agent read one web page, and code launched on the machine it was running on

Microsoft's security researchers built a small AI agent with one ordinary job: visit a web page and write a summary of it. They pointed it at a page they had quietly booby-trapped. Instead of a summary, the agent triggered a calculator to pop open on the computer it was running on. The calculator was a stand-in. In a real attack it would have been any command the attacker chose, running under the developer's own account.

The technique, published on June 18, 2026 and named AutoJack, matters less for the calculator than for the line it crossed. For decades, software has treated localhost, a machine's own internal address, as inherently safe. AutoJack shows that once an AI agent on that machine can browse the open web, that safety quietly falls apart.

What Microsoft found

Microsoft's Defender Security Research Team disclosed AutoJack as a chain of three flaws in AutoGen Studio, the open-source prototyping interface for AutoGen, which is Microsoft Research's framework for building systems out of several cooperating AI agents. Developers use it to connect AI models to tools and run quick experiments. The team reported the chain through Microsoft's own disclosure process, the maintainers closed it before it ever reached a public release, and Microsoft says it found no sign of the attack being used in the wild. Exposure was limited to developers who built the tool straight from its latest source code during a short window. That is the reassuring part, and it deserves to be said plainly. You can read the full write-up on the Microsoft Security Blog.

The chain works because three reasonable shortcuts line up. First, a local control channel called an MCP WebSocket (the always-on connection that lets an AI assistant talk to outside tools) accepted connections only from the machine itself. That stops a stranger's browser, but an AI agent running on the same laptop is the machine, so anything it loads sails through the check. Second, the part of the software meant to demand a login skipped that channel completely, assuming something else would guard it. Nothing did. Third, the channel took a command straight from its own web address and ran it, with no list of which programs were even allowed. Line those three up and a page the agent merely visits can hand the agent's machine a command and watch it execute. The industry's name for an outsider running their code on your computer is remote code execution, or RCE, and that is exactly what this produces.

• The trigger needs no password and no click. A planted link, a poisoned comment on a legitimate site, or a hidden instruction buried in a page the agent reads can all set it off.
• The command runs with the developer's own privileges, putting source code, saved credentials, and access tokens within reach.
• AutoJack is the second agent-framework flaw of this shape Microsoft has detailed since May, after a similar weakness in its Semantic Kernel toolkit.

Why it lands on your developers, not your servers

Because this was caught in research, no company lost data to it, and that is the honest frame: what Microsoft showed is a proof of concept, not a breach. What should still reach your planning is where this kind of risk lives. The machines most exposed to the pattern are not hardened servers in a data center but the laptops of your own developers, the people most likely to be running an experimental AI agent and most likely to point one at an unfamiliar URL. If your engineering team is prototyping with agent frameworks this year, and a great many are, those workstations now hold both the keys to your code and an agent that will read whatever the open web feeds it. The deeper shift is the one Microsoft names directly. Localhost has stopped being a trust boundary. A whole generation of developer tools left debug ports, local databases, and control sockets open on the quiet assumption that only the machine's owner could ever reach them. A web-browsing AI agent is a new kind of resident on that machine, one a stranger can steer from the other side of the world. Expect the same triangle, a powerful local service, a localhost-only assumption, and a browsing agent sitting next to it, to turn up in other tools.

What to do about it

1. Keep web-browsing and code-running agents off your everyday machines. Run experimental agent frameworks inside a container, a sandbox, or a disposable virtual machine, because that confines any hijack to a throwaway environment instead of the laptop holding your credentials.
2. Stop trusting localhost by default. Require authentication on every local control channel, including debug and developer endpoints, since AutoJack worked precisely because a local service assumed its own machine was safe.
3. Give the agent its own identity, not the developer's. Run it under a separate, low-privilege account, so that anything launched through the agent cannot reach the source code, tokens, and secrets tied to the human's login.

Bottom line

AutoJack is a warning shot, not a casualty report. Microsoft built it, broke it, and helped fix it before the vulnerable code ever shipped. The reason to carry it into your next security review is the pattern rather than the single bug. The moment you place an AI agent on a machine and let it read the open internet, every quiet local service on that machine becomes something an outsider can try to reach through it. So ask one plain question about your developers' laptops: if an agent on one of them opened the wrong page tomorrow, what on that machine still assumes localhost can be trusted?