From the Palo Alto Networks edition of November 10, 2026
Preprint: static analysis of 10,655 real-world MCP servers finds credential and PII leakage rates above 10%
Biwei Yan, Minghui Xu, Yijun Yang, Boyang Ma, Xuelong Dai, Jingku Li, Yue Zhang (arXiv authors) · Academic research / MCP security · Global open-source ecosystem
- Publisher
- arXiv
- Original publication
- arXiv:2606.21338 v1, submitted 19 Jun 2026
- Source retrieved
- 2026-11-11
What happened
Preprint, not peer reviewed. The authors argue that leakage in MCP servers is largely protocol-induced: credentials, API keys and personally identifiable information cross the local-to-LLM boundary simply by being returned, logged or raised inside a tool handler, with no explicit outbound request. Their MCPPrivacyDetector uses cross-language static and taint analysis; applied to 10,655 real-world MCP servers it finds leakage rates above 10%, with case studies of leaked bearer tokens, propagated API keys and plaintext authentication credentials.
Why it matters
Why now: Palo Alto's Nov. 10 Data Security MCP Server is pitched as safer because it runs locally, and SLED security teams are being invited to connect DLP data to agents. This study shows that local MCP servers still pass secrets and PII into model context, so the local framing does not by itself settle data-protection questions for regulated public-sector data.
Evidence and measured results
Opened the arXiv abstract page (v1, 19 Jun 2026, cs.CR; arXiv DOI 10.48550/arXiv.2606.21338). Figures are from the abstract; the full paper was not read, so per-category rates, false-positive rates and whether any vendor-published servers were included are unknown.
Limitations and uncertainty
Preprint, not peer reviewed. Static analysis of open-source servers; it did not evaluate Palo Alto's Data Security MCP Server. 'Above 10%' is an aggregate; the abstract gives no breakdown.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-11; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Agencies adopting MCP connectors lack a way to judge whether connectors expose credentials or personal data to AI models.
- Stakeholders
- CISO
- Application security lead
- Privacy officer
- Developers building agents
- Discovery questions
- Which MCP servers are approved, and how were they reviewed?
- Do connector logs or outputs contain secrets or PII?
- Who owns MCP server approval?
- Value hypothesis
- A structured MCP review can reduce the chance that connectors leak secrets or regulated data into model context.
- Potential engagement
- An MCP connector inventory and leakage review for a pilot group of agents.
- Unsupported claims
- That Palo Alto's MCP server leaks data
- That local deployment prevents leakage
- Exact leakage rates for any specific server
Pre-sales engineering
Role takeaway
- Fit
- Applies to any MCP server in SLED agent deployments, vendor or in-house.
- Architecture and integration
- Review sits in the connector approval and CI pipeline; static or runtime checks on tool handlers.
- Prerequisites
- MCP server inventory
- Access to connector code or test environment
- Defined sensitive-data patterns
- Constraints
- Vendor servers may be closed source
- Static analysis may miss runtime-only flows
- Security
- Minimize data returned by tools, redact secrets, use scoped short-lived credentials and keep logs out of model context.
- Proof of value
- Run leakage tests on each approved connector
- Inspect tool outputs during a sample agent session for secrets and PII
Delivery
Role takeaway
- Work
- Add MCP leakage review to connector approval and change management.
- Dependencies
- Application security capacity
- Connector inventory
- DLP patterns for testing
- Ownership
- Application security lead, with privacy officer sign-off for regulated data.
- Skills and adoption
- Developers need training on what tool handlers expose to models.
- Governance checkpoints
- Pre-production leakage review
- Re-review on connector updates
- Acceptance criteria
- Proposed: no secrets or regulated identifiers in tool outputs or logs in test sessions
- Proposed: every production MCP server has a recorded review
- Risks
- Closed-source connectors that cannot be reviewed
- Review fatigue as connectors multiply
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Treat any MCP server, including vendor-supplied ones, as a data path into the model provider; review what tool handlers return and log.
Governance
Who approves, reviews and stays accountable for outcomes?
MCP server approval should include a code or behavior review for secret and PII exposure, not only a vendor reputation check.
Security and privacy
What data, permissions and controls need testing?
Directly concerns credential and PII leakage into LLM context and logs, relevant to CJIS, HIPAA and FERPA obligations.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Developers building agents need training on what tool handlers expose; no accessibility implications.
Procurement
What should contracts, pricing and exit terms secure?
Require vendors of MCP connectors to document data returned to models and logging behavior.
Operating model
Which teams own the service once it runs?
MCP connector review becomes part of application security change management.
Publication history
- 2026-11-10Palo Alto Networks · Issue 117 resources
Stable resource ID: arxiv-2606-21338-mcp-server-privacy-leakage-detector-20260619