AutoJack: When the AI Browser Becomes the Initial Access Broker

An AI agent that browses the web on your behalf is, functionally, a confused deputy with a keyboard.

Microsoft researchers have published details of an exploit chain they call AutoJack, which weaponizes that confusion. The premise is uncomfortably simple. Steer an AI browsing agent to an attacker-controlled page. The page's JavaScript then reaches a privileged local service running on the same machine and spawns a process on the host.

No credential prompt. No consent dialog. No second click.

The chain hinges on a trust assumption baked into a lot of agentic browser tooling: that traffic originating from localhost or a loopback interface is implicitly authorized. When the AI agent loads the malicious page in its own browser context, the page's script is same-origin enough — or routed through enough — to call into the local helper service that the agent uses to control the host. That service was designed to let the agent do useful things like launch tools or interact with the filesystem. It will happily do the same for whatever script gets to it first.

The attacker never needs to compromise the agent's model, jailbreak its system prompt, or smuggle instructions through prompt injection. The model is incidental. The page is the payload.

That distinction matters. A lot of the public conversation about agent security has fixated on prompt-injection defenses and guardrail tuning. AutoJack sidesteps the model layer entirely. It is a classic local privilege boundary failure dressed up in AI clothing.

Microsoft has not, at time of writing, published a single consolidated advisory page for AutoJack, and no CVE identifier has surfaced in public vulnerability databases yet. The research was disclosed as a class of issue affecting agentic browser architectures broadly, rather than a single shipped product bug. Expect follow-on CVEs against specific vendors as the disclosure timeline plays out.

There is no breach-notification dimension here yet — no exposed records, no regulator filing, no named victim set. The exposure is prospective. Anyone running an AI browser agent with a local control plane is in scope.

What affected users should do

If you run an AI agent that drives a browser on your workstation, treat its local helper service as a network-exposed attack surface, not an implementation detail. Audit which ports it binds and whether it authenticates callers beyond an origin check. Restrict the agent to an allowlist of domains where feasible. Run the agent in a separate user account or container, so a successful host-spawn doesn't immediately reach your real files. And watch your endpoint telemetry for child processes parented to the agent binary that you didn't ask for.

The model isn't the problem. The shell around it is.