-
Notifications
You must be signed in to change notification settings - Fork 18
add security and privacy considerations living document #55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
initial draft based on discussion here: #45 will update it based on relevant discussions in the thread, as well as from TPAC before marking it as ready to merge. |
khushalsagar
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good!
| Prompt injection represents a critical threat to WebMCP where malicious instructions are embedded in tool metadata, inputs, or outputs to manipulate agent behavior or compromise systems. Unlike traditional injection attacks, these exploits target the language model's interpretation of natural language rather than code execution vulnerabilities. | ||
|
|
||
| **Key Risk Factors**: | ||
| - No cryptographic verification of tool descriptions or schemas |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't follow this. how does cryptographic verification help?
|
|
||
| Malicious instructions embedded in tool parameters by compromised or malicious agents, targeting the website's own processing of tool inputs. | ||
|
|
||
| - **Threat Actor**: Malicious users controlling or manipulating agents using WebMCP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is quite interesting. Definitely worth documenting but I think the onus is on the site as an "Agent provider". Every Agent provider has to mitigate against a common set of attacks when taking untrusted input. They likely have mitigations aside from WebMCP, the same tool could be exposed using an option in the Web UI.
Can you add something along these lines to the text? WebMCP doesn't expand the attack surface for this.
|
|
||
| #### Misalignment Types | ||
|
|
||
| 1. **Malicious misrepresentation** (fraud): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's ambiguous what the site accomplishes from this attack, since it already has the ability to execute this action. Worth documenting that this is about deflecting blame/misattribution. Intentionally taking a harmful action which can be attributed to the Agent.
| - Side effects not mentioned in the description | ||
| - Example: Tool deletes draft after sending email without mentioning this behavior | ||
|
|
||
| 3. **Ambiguous scope**: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a duplicate of 2), imprecise i.e. poorly written.
| - Are there specific attack scenarios from existing web security domains (CSRF, XSS, etc.) that apply to WebMCP in novel ways? | ||
| - What risks emerge when combining WebMCP with other emerging web capabilities (Prompt API, Web AI, etc.)? | ||
|
|
||
| ### 2. Responsibility and Scope |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't say these are overarching open questions, it's just considerations for how to approach mitigations in this space.
I'd probably put something like this in the introduction: "Mitigations for any attack vector will need to consider all systems/entities involved: Site authors, Agent providers and browser vendors. While the spec can't define precise mitigation strategies that Agents/browser vendors must provide, the responsibilities for each system should be clearly defined. Common mitigations are documented as recommendations for Agents/browser vendors. We also explore these mitigations to inform additions to the Web API."
| - Should some tool categories require elevated permissions or review processes? | ||
| - Related: [Issue #44 - Action-specific permission](https://github.com/webmachinelearning/webmcp/issues/44) | ||
|
|
||
| ### 4. Comparison with MCP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar here, can go into the section at the beginning which explains the overall approach. Something like: "It's likely that many mitigations to handle tools from untrusted sources will be common across MCP and WebMCP."
Because this is something we'll consider for every attack vector/mitigation.
No description provided.