-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[notes] Security IG - October 7, 2025 #1629
Copy link
Copy link
Closed
Labels
notesNotes from meetings and discussions. Used for tracking purposes only, no action is needed.Notes from meetings and discussions. Used for tracking purposes only, no action is needed.security
Description
Security IG Meeting Notes
Date: October 7, 2025
Attendees
- Max Gerber
- Atul Tulshibagwale
- Joe Zhou
- Den Delimarsky
- Rob Robert
- Nick Steele
- Chris Phillips
- Almog Langleben
Discussion
Fixed Metadata Fields & Server Behavior
- Fixed Metadata: MCP server metadata is fixed at submission to prevent post-deployment changes ("tool poisoning"). While this limits dynamic updates, it doesn't eliminate the risk of "rugpull attacks," as servers can still change behavior without modifying metadata.
- Server Verification: Without API signatures, verifying MCP server behavior remains a challenge. Protocol-level controls are limited; clients must inspect and detect behavioral changes.
- Observability: A registry could sign or hash server metadata to alert clients when a server's state changes. This aids in detecting unauthorized changes but requires tooling support. This is a discussion that we need to have with @toby and team to understand what security controls there are in the future for the MCP registry.
MCP Server Models & Extensions
- Extension Model: OpenAI's implementation of MCP in their Apps SDK resembles WordPress/Salesforce, where users install extensions that are built on top of a shared protocol. There are no protocol-level controls to prevent malicious extensions, especially on remote servers. The validation process is still in the hands of the client/vendor owner.
- OpenAI's Approach: OpenAI also introduced some auth-related behaviors that are not in the spec but are submitted as SEPs.
Security & Governance
- Interest Groups: Rob suggested that there is some interest in adopting MCP in highly-regulated environments, such as healthcare, but that requires advanced capabilities (e.g., security-related traceability and observability). Existing guidance should be considered a starting point for this effort.
- Multi-Hop Authorization: Federated scenarios where agents connect across multiple MCP servers are challenging. The specification establishes the min bar but we do not have a good way to "break out" of that shell and show how to interact with other services. This requires additional guidance.
Trust, OAuth Challenges, and Local vs. Remote
- OAuth & Identity: OAuth remains the primary, though imperfect, mechanism for agentic identity. Managing diverse OAuth deployments across servers is complex and can be a barrier to broader MCP adoption.
- Trust Factors: Many MCP deployments are local due to data security and user trust concerns. Local servers are favored in developer tools and sensitive environments, while consumer products are trending toward remote servers. The security posture is going to be different between the two workloads, no matter how we look at it.
Follow-ups
- Explore registry-level signing/hashing for server metadata to improve observability (@localden and @toby).
- Continue discussion on federated authorization and audience management across multi-hop MCP scenarios (guides and reference implementations need to be established).
- Continue building on sector-specific interest groups for addressing domain-specific security needs.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
notesNotes from meetings and discussions. Used for tracking purposes only, no action is needed.Notes from meetings and discussions. Used for tracking purposes only, no action is needed.security