Skip to content

[notes] Security WG Meeting, September 9th, 2025 #1452

@dend

Description

@dend

Attendees

Den Delimarsky (Core Maintainer)
Jenn Newton (Anthropic)
Joe Zhou (Microsoft)
Max Gerber (Stytch)
Sam "Frenchie" Stewart

Discussions

Compromised npm packages and MCP server notifications

Given recent news around npm package compromise, we've looked at ways in which we can notify existing MCP server developers about the issue and ensure that the MCP ecosystem is protected from potentially compromised MCP servers that took a dependency on affected packages.

There is a potential angle here where the MCP registry accounts for some kind of signal from downstream package registries (separate from the MCP registry) and then is exposed through metadata, allowing clients to make a determination on what to do with packages that have vulnerabilities. Alternatively, potentially a security policy could be instituted that would assess the "security score" of a MCP server and then determine whether to continue listing it. This will require work with the registry maintainers.

@jenn-newton and @dend will work through potential registry requirements, and involve the #registry-dev in the conversation about the path forward. Ongoing thread exists to kick-start the discussion.

Triage the existing security items

There are currently 32 open issues labeled with security. We discussed triaging them with the help of the community - folks should provide input and discuss the security-related spec enhancements that are currently on deck. There are also a few items that are likely outdated and can be closed - @dend will take an initial pass to verify them.

Initial SEP feedback

We took a look at two SEPs labeled as security and discussed some very early community feedback:

  • SEP-1415: HTTP Message Signing for MCP Client Authentication
    • This feels like a pretty significant departure from the current OAuth-based specification. It feels like DPoP without DPoP.
    • Requires additional assessment on all the flows and impact on the broader client-to-server governance model.
    • It's not yet clear what the level of complexity here will be on client and server implementers.
    • Additional review will be needed - folks will provide feedback async on the issue.
  • SEP-1075: Security Annotations for MCP Tool Definitions
    • Not immediately clear why existing metadata can't be used for annotations.
    • Organizational needs vary - is this approach scalable to everyone and is it fair to assume that a self-attested server-based declaration is enough?
    • Additional review and feedback will be provided in the issue.

HackerOne engagement

@jenn-newton is working through the logistics of ensuring that official MCP-related code can be covered by a dedicated HackerOne program.

Action items

  1. Engage with the registry maintainers to figure out MCP server security integration capabilities (@jenn-newton, @dend)
  2. Help triage existing security items and provide input (broader security WG crew).
  3. HackerOne program establishment (@jenn-newton)

Metadata

Metadata

Assignees

Labels

notesNotes from meetings and discussions. Used for tracking purposes only, no action is needed.security

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions