Repository navigation
Mitigations for profound privacy and security issues seem to be missing? #313
Description
These are among the largest and most diverse set of security and privacy threats introduced by a single spec -- a malicious website can very likely access huge amounts of personal information from the user, including from other origins (all of their emails, say), other browsing history, or other sensitive sources, without any user involvement or awareness, and even take consequential actions that cost the user money, spread the harms to other people, hurt reputations, etc.
But there mostly don't seem to be any mitigations? Hopefully the implementers will share notes in real time about all the prompt injection attacks that they encounter? A few of these mitigations are aimed at site authors, but the largest threats are when the site author is the attacker.
The Privacy Working Group discussed this briefly, but the reaction was mostly that the threats are severe and that the protections seem to just be missing. I recognize that many implementers are shipping various agentic browsing tools that already suffer from many of these threats, but, this seems to provide a well-suited surface for large-scale open-ended attacks.
Activity
Hronom commentedon Sep 22, 2026
One useful mitigation set is to make the agent's authority explicit and inspectable rather than treating page-registered tool descriptions as trusted intent:
Visible UI helps only when the approval is bound to the same origin, context, and generation that will execute; otherwise a spoofable UI can merely relocate the attack.
I maintain Hronaut, a local visible Browser/MCP workspace; this is general design feedback, not a WebMCP compatibility claim.
domfarolino commentedon Sep 25, 2026
True, an agent with sufficiently broad authority can create these risks. But they are not enabled by WebMCP. They are simply what is possible when agents use websites on behalf of users, regardless of whether those sites author WebMCP tools.
I'm sure @johannhof and @jpagnucco can share anything that they've been working on and experiencing, that's not already covered by https://webmachinelearning.github.io/webmcp/#security-privacy.
All of the mitigations above listed by @Hronom are very reasonable, and something that we can non-normatively recommend agent harness implementers to support, but they're probably not something any web standard can normatively enforce. That's kind of like trying to force "users must not mix data from other origins", if you see agents as another kind of user.
In particular, I think it's useful to separate the authority an agent has from the mechanism it uses to interact with a website. If an agent is allowed to read data from origin A and then interact with origin B, WebMCP does not create that cross-origin sharing merely just B exposes a tool. Preventing the agent from inappropriately combining or disclosing that data is primarily a responsibility of the agent/harness and its security model.
That doesn't mean there can't be WebMCP-specific security considerations or mitigations, and we should absolutely identify those where they exist. But we should distinguish those from the broader security problem of agents operating on the web.
domfarolino commentedon Sep 25, 2026
And again, I don't think we should punt on figuring out what a sensible agent security model should be. Folks like @johannhof and @jpagnucco have been working on exactly that. It's just that those recommendations (or even requirements) need to live at the appropriate, where they can actually be enforced.
[-]mitigations for profound privacy and security issues seem to be missing?[/-][+]Mitigations for profound privacy and security issues seem to be missing?[/+]npdoty commentedon Sep 28, 2026
If you define as out-of-scope the most common and significant set of security threats for a particular technology, that can indeed make the security considerations of a web spec quite concise. Prompt injection is a well-defined and notable threat. It's true that this threat is available because agent software is itself notably insecure. But WebMCP is a feature currently designed in a way that will create hard to detect surface area for prompt injection.
Design differences at the spec level could make a difference: it's not just an issue that agent software is insecure and someone ought to do something about it somewhere else. For example, I recently opened another issue (already closed, with minimal discussion) pointing out an alternative approach that wouldn't introduce the same amount of threat surface.
jpagnucco commentedon Sep 28, 2026
I agree with @domfarolino here. Mitigations happen at the agent or browser level when we are thinking about site attackers. We (Chrome) have published documentation for agent and site developers to guide them on security best practices.
Site dev guidance
Agent dev guidance
We intend to keep these documents up to date as well.
@npdoty , Are you looking for a discussion of mitigations in the security & privacy section of the spec?
jpagnucco commentedon Oct 6, 2026
I've opened #334 to update the Security and Privacy Considerations section and linked to the proposed W3C Agentic Web Working Group Charter as the broader venue where these types of discussions should take place.
npdoty commentedon Oct 6, 2026
Personally, I was looking for mitigations for the attacks (limitations on the surface being exposed just to agents in a way perfectly suited for invisible prompt injection), rather than a justification in the security and privacy considerations section about why mitigations are out of scope.
domfarolino commentedon Oct 8, 2026
Mitigations beyond what https://webmachinelearning.github.io/webmcp/#mitigations elaborates on, right?