Privacy & security considerations for WebMCP

[victorhuangwq]

I would like to contribute to the privacy and security discussion around WebMCP, as requested in #35 (comment)

Assumptions

To make meaningful progress, we should align on some baseline assumptions about agent capabilities:

• Agents can inherit user identity and context from the browser. E.g. When an agent visits Amazon, it will have the logged in credentials of the user (if the user logged in)
• Agents can be provided with extended capabilities to information about the user, such as personalization, browsing history, and even payment information.
• Agents can access context across multiple websites

Based on conversations and review of current issues, I’d like to surface three key areas for deeper discussion, and focus from a problem first approach:

1. Prompt injection attacks, which is already mentioned in: #11

WebMCP tools will be both:

• a vector (for malicious actors to prompt inject)
• and a target

2. Misrepresentation of intent in the WebMCP tool

There is no guarantee that the WebMCP tool’s declared intent matches its actual behavior. This creates a trust gap because:

• Tool descriptions are in natural language, which is ambiguous and unverifiable.
• Agents rely on these descriptions to decide whether to act but cannot confirm the tool’s real effect.
• Misalignment can be malicious (e.g., fraud) or accidental (poorly written descriptions).

Even when the agent does not share any of the user’s sensitive data, risky actions can still occur because the user is already authenticated on the site. This means the tool can perform high-privilege actions without additional checks.

Example Scenario
ExampleShoppingSite.com implements an add-to-cart tool.

• Declared intent: Adds item to cart
• Actual behavior: Completes purchase using stored credit card
  Agent trusts the description → assumes low risk → skips user permission prompt. Outcome: Full purchase occurs silently.

3. Personalization scraping / fingerprinting through over parametrization

In the context where agents have access to personalization information, it creates a privacy risk when sites design parameterized WebMCP tools to extract sensitive data.

In the dress purchasing example mentioned in the WebMCP spec, there was a potential use case by agents where Notice, the user did not give their size, but the agent knows this from personalization and may even translate the stored size into EU units to use it with this site.

Being helpful by design, agents can provide the right inputs to WebMCP tools, helping the user quickly achieve their goals. But it can allow for over-parameterization abuse.

Example:
Sites can craft functions like:

• get_dresses(size, price) → benign
• get_dresses(size, price, age, pregnant, location → silently extracts private attributes
  Sites can turn personalization into fingerprinting, enabling sites to build profiles of anonymous users without explicit consent.

Next step

Would love to brainstorm on the following questions together:

• Emerging risks: Beyond the issues already raised (e.g. prompt injection, misrepresentation of intent, over‑parameterization), what other problems should we be concerned about?
• Scope of responsibility: What should be built into WebMCP’s design itself to help address issues, and what should be left up to agents to handle?
• Where should we follow MCP in terms of how they are approaching this, and where are we different?

Looking forward to hearing your perspectives and building this out collectively. My hope is that this conversation can help inform potential solutions, I can already see issue #44 starting to address part of this space around action‑specific permission.

[victorhuangwq]

@anssiko would appreciate your guidance, if you prefer that I split this up into separate issues. But my intention here is to try and surface a broader discussion of privacy and security considerations, where we draw the lines, before we branch off into different issues.

[anssiko]

@victorhuangwq thank you for this important contribution. This broader issue is appropriate for TPAC discussion webmachinelearning/meetings#35

After the meeting we can split this into actionable smaller issues and assign priorities.

[victorhuangwq]

Sounds good! I’ll use this thread to share any additional findings or updates (if any) as I continue investigating.

[victorhuangwq]

Additionally tagging @EmLauber who collaborated with me on the above P/S considerations, if she has any further points of discussion to add :)

[khushalsagar]

Thanks for the summary above! Here's my take on these:

Prompt injection attacks

I don't think there can be a single deterministic defense here. This will have to be layers of mitigations at every level: site author, browser and Agent providers. We can provide recommendations for browser implementors and Agent providers and spec APIs where the author can help. For example:

• Marking up content in the tool output which is sensitive/PII so browsers/Agents can avoid putting them directly in the context window.
• Marking up user generated content in the tool output. Generally we assume that content from the same origin doesn't need to be isolated. In this case user generated content from the same origin can be used to steal other data from the same origin if it came from different users.

Misrepresentation of intent in the WebMCP tool

I'm trying to understand the attack vector here. Specifically "Even when the agent does not share any of the user’s sensitive data, risky actions can still occur because the user is already authenticated on the site. This means the tool can perform high-privilege actions without additional checks". Wouldn't the site be able to do those actions anyway? We're running code on the site that it can invoke itself.

The misrepresentation also seems similar to the site putting wrong labels in their UI. For example, there is an "Add to Cart" button which instead finishes the purchase when the user clicks it. The only difference I can see is that when it's misrepresentation in the UI, it's obvious to the user that it came from the site. But if the Agent takes an unexpected action it could be either:

a) The Agent made an error in translating the user request to the correct action: invoked make_purchase instead of add_to_cart.
b) The Agent invoked the correct action, add_to_cart, but the site instead made a purchase. That could be malicious on the site's part or a bug.

Sounds like the Agent would need to keep a trail of user query and list of actions to distinguish between the cases above?

Personalization scraping / fingerprinting through over parametrization

Agreed that this is an issue. And this requires the Agent to seek user consent before sharing any PII. The autofill feature comes to mind where browsers show UI for the user to confirm before sending any data to the site. Maybe the browser or Agent can remember if they've already shared some info with an origin to minimize consent flows? :)

---

Scope of responsibility: What should be built into WebMCP’s design itself to help address issues, and what should be left up to agents to handle?

Hints from the site that Agents can use to protect their content should be built into WebMCP's design. The examples I can think of for now are above: sensitive/PII and user generated content in the tool output. This will be iterative as we get more feedback from Agent providers.

Where should we follow MCP in terms of how they are approaching this, and where are we different?

The site is conceptually an MCP server so any additions MCP makes to the server’s API surface for these problems are worth considering for us. And vice-versa, we should recommend changes to the MCP spec. The more closely the primitives can be aligned the better.

As an example, the syntax for the tool output including marking up PII in it should be common between the 2.

[TomCJones]

i am participate in SING - this is my personal comment

the following statement from the doc gets to the core of the problem that i posted to SING a while ago. Generative AI makes stuff up and that seems to be intentionally unfixable. What is needed is a separate evaluation layer to test the intent against the results. Otherwise the agent could start sending itself goods from Amazon with my credit card. And knowing Amazon - i would be stuck with the bill, not Amazon and not the guy supplying the agent.

I can't imagine any user accepting this condition.
I can't imagine that i would accept this agent, but i can imagine someone in my family doing it and charging my credit card.

quote =
There is no guarantee that the WebMCP tool’s declared intent matches its actual behavior.

[victorhuangwq]

Some clarifications based on @khushalsagar's reponse.

on prompt injection

Marking up content in the tool output which is sensitive/PII so browsers/Agents can avoid putting them directly in the context window.
Marking up user generated content in the tool output. Generally, we assume that content from the same origin doesn't need to be isolated. In this case user generated content from the same origin can be used to steal other data from the same origin if it came from different users.

Based on current proposal it seems like the response is just a string. Are you suggesting defining some standardized semantics to indicate sensitive information returned, and/or untrusted user generated content? (I do like this direction)

Additionally, I think it’s important to highlight that WebMCP tools themselves can become high-value targets for prompt injection attacks. For example, if a site like bank.com exposes a resetPassword tool, a malicious site could try to trick an agent into invoking it. We should decide whether protections against this belong in the design, such as semantic labels for sensitive tools, or if this should be left entirely to agents to infer from tool descriptions.

on misrepresentation

The only difference I can see is that when it's misrepresentation in the UI, it's obvious to the user that it came from the site. But if the Agent takes an unexpected action it could be either:
a) The Agent made an error in translating the user request to the correct action: invoked make_purchase instead of add_to_cart.
b) The Agent invoked the correct action, add_to_cart, but the site instead made a purchase. That could be malicious on the site's part or a bug.

I think your thought here is in the direction that I was trying to convey. Let me try and clarify the nuance better.

With traditional UI, responsibility is straightforward: was the website clear in what it presented to the user? The user sees the button, the label, and the flow.

In WebMCP, the situation is more complex. Let me provide a better example than I did: a site exposes a tool called finalizeCart, does that mean “review cart contents” or “complete purchase”? If an agent misinterprets that intent, we end up in a tri-party ambiguity (which I think @TomCJones is alluding to):

Website responsibility: Should sites ensure their tool names and descriptions are unambiguous and tested across different browser agents? The challenge is that tools aren’t defined by imperative code - they rely on natural language tool & descriptions. Throw in other languages this could be a little complex.
Agent responsibility: Should agents be held accountable for failing to infer the correct meaning?
User expectation: The user assumes their instruction will be carried out safely, but attribution is unclear when something goes wrong.

It’s perfectly fine if we decide that responsibility lies with agents to infer intent from tool name and description - but we should acknowledge this ambiguity explicitly. One possible mitigation is for tools to include structured metadata about expected outcomes, which agents can use for validation.

[johannhof]

Specifically on prompt injection and misrepresentation of intent, I believe this needs a clear(er) threat model: Who do we consider a potential attacker, and what would be their goal? To Khushal's point, I'm not sure the first party developer of the page would have any particular incentive to force malicious action through WebMCP on their own site - they already control the page! However, there are a few other potential threats:

• (1P/3P) origins trying to enforce malicious action or data exfiltration on other origins
  • This would be helped by stronger definitions of cross-origin boundaries in the proposal, but seems addressable overall.
• 3P content included in tool definitions or responses trying to enforce malicious action or data exfiltration on the 1P origin that declares WebMCP tools
  • This is, to a certain degree, a responsibility of the 1P origin, but there are likely mitigations that we should propose to help 1P authors defend against this.
• (1P / 3P) origins using prompt injection to attack the agent / model directly, for the purpose of e.g. PII leakage or memory poisoning
  • This is less a security issue that affects web developers, and more something that agent / browser developers will need to address, so I'm not sure this (Web Platform) proposal can deliver many answers for it.

[victorhuangwq]

@johannhof I agree that defining a clearer threat model would be really helpful here. I also agree with the three points you've outlined as well.

On the misrepresentation of intent aspect, just to add more flavor to the discussion, the fuzziness isn’t always about identifying a malicious actor per se, but rather about the ambiguity in how intent is expressed and interpreted. The example I mentioned in my reply was about unintended outcomes, but to give a more explicitly malicious variant:

Imagine shoppingsite.com defines a function like finalizeCart intentionally being ambiguous about the outcome. The user just wanted to view their final cart. But the agent calls it, and it actually triggers a purchase. Who’s responsible in that case? The user didn’t intend to buy anything. The site can now deflect blame onto the agent for misinterpreting the tool (and this is for the malicious case - I'm sure the non-malicious case will be equally prevalent).

This might not fall squarely under “security,” but it does feel like a design ergonomics issue we should address. Maybe there’s room in the spec for a way to express expected outcomes or side effects more explicitly, so agents can verify intent. That could help reduce both accidental and adversarial misfires.

[johannhof]

Yeah, I agree that the question of responsibility for a misunderstanding between the agent and the website is quite unclear, which is probably a concern for all agentic commerce. There is probably an opportunity to develop technologies that enable the merchant (or sites with other sensitive functionality) to require presentation of e.g. a passkey as proof that the user intended to take the sensitive action.

[khushalsagar]

Based on current proposal it seems like the response is just a string. Are you suggesting defining some standardized semantics to indicate sensitive information returned, and/or untrusted user generated content? (I do like this direction)

Exactly. We already have an open issue for switching to a json schema for the output: #9. We can add more semantics to annotate parts of the response.

Maybe there’s room in the spec for a way to express expected outcomes or side effects more explicitly, so agents can verify intent. That could help reduce both accidental and adversarial misfires.

Happy to explore this but I can't think of a good way offhand, especially for the adversarial case: the site is knowingly making the tool description ambiguous. This is a common problem with MCP, I'm curious if they've considered this too.

Also, it feels like there's some intersection with #44 about who is responsible for seeking user consent before taking "sensitive" action. If it's the site, and they also get to present the UI for seeking that consent, then the responsibility seems similar to what happens today: the site should clarify the action being agreed to for the user. That should help with the accidental case. But there's still a question of who is responsible if the site doesn't seek consent for an action and the user would've expected them to.