The browser's Same-Origin Policy is completely unprepared for

Researchers proposed WebMCP-Phalanx, a dual-layer runtime architecture that splits AI agents into a low-privilege quarantine agent (Q-LLM) and a high-privilege executor (P-LLM) to defend against prompt injection and tool hijacking in browsers. In testing, their cryptographic capability credentials reduced revocation and overwrite attack success from 100% to 0%, but a white-box bypass via malicious tool names invoked before inspection remains, prompting a proposed call-timing gate.

The browser's Same-Origin Policy is completely unprepared for website-a.com from reading your cookies on bank.com , but it's terrible at managing the "provenance" of a tool being called by an AI.If an agent is browsing the web and encounters a malicious tool or a hijacked capability, the browser currently doesn't have a native way to verify exactly who "owns" that tool or how long its lifecycle should last. This opens the door to three nightmare scenarios: subject-attribution spoofing pretending a tool comes from a trusted source , uncontrolled tool lifecycles, and the inevitable semantic prompt injection. The researchers behind the WebMCP-Phalanx architecture are trying to solve this by proposing a dual-layer runtime that effectively treats AI tool usage like a high-security clearance operation. The Dual-Layer Defense Strategy Instead of letting one big, powerful agent roam the web with full privileges, Phalanx splits the brain into two distinct entities: The Quarantine Agent Q-LLM : This is a "low-privilege" agent. It has zero authority to actually execute tools. Its entire job is to act as a semantic inspector. It looks at tool metadata, examines the outputs, and scans the page content for anything that looks like a prompt injection attempt. Crucially, the web page can't see the Q-LLM's internal reasoning or state, which prevents the page from "gaming" the inspector. The Privileged Agent P-LLM : This is the "high-privilege" executor. It only receives content that has been scrubbed and validated by the Q-LLM. It handles the actual heavy lifting and tool invocation, but it stays isolated from the raw, potentially toxic input of the web page. To back this up, they also suggest a browser-native trust anchor. This involves using cryptographically protected capability credentials to bind every single tool to its specific creator. In their testing, this ownership mechanism was incredibly effective, dropping the success rate of revocation and overwrite attacks from 100% down to 0%. Where the defense still breaks Even with this setup, security isn't a solved problem. In a "white-box" scenario—where an attacker knows exactly how the defense works—they found a way to bypass the description-based filtering. By using malicious tool names that are invoked before the inspection process is completed, an attacker can slip through the cracks. This is a classic race condition in AI security. The fix they are proposing is a "call-timing gate." Basically, you shouldn't allow the agent to even look at or invoke a tool until the system has completed a full validation of every single piece of visible tool metadata on the page. If we want browser-integrated agents to be more than just toys that can be easily hijacked to steal session tokens or manipulate data, we need to move toward this kind of multi-agent, sandboxed deployment model. Relying on the LLM's "intelligence" to stay safe is a losing game; we need architectural enforcement. Next I prioritize user safety. → /en/threads/7803/ an AI side-hustle playbook https://tanyan888.com/ , with plenty of directly applicable cases. All Replies （4） @CameronCat /en/users/CameronCat/ it's a nightmare for devs. u basically have to build custom scrapers for every single site now