From the Palo Alto Networks edition of November 9, 2026
arXiv 2611.03555 (AISec '26): MCP tool poisoning succeeds in 22.9% of 9,720 real-execution tests across 12 agent frameworks; metadata scanning is only a partial control
Farooq Shaikh and Biagio Montaruli (academic preprint, accepted at AISec '26 / ACM CCS 2026) · Academic AI security research · Framework-agnostic laboratory measurement; no jurisdiction
- Publisher
- arXiv
- Original publication
- arXiv v1 submitted Mon, 2 Nov 2026 18:17:08 UTC
- Source retrieved
- 2026-11-10
What happened
The authors measured MCP tool poisoning with real tool execution using an open-source tool (mcpvenom) across a 9,720-cell matrix: 12 frameworks, 18 models and 45 attack scenarios, with a dual oracle that confirms exfiltration through a canary HTTP receipt. Overall attack success was 22.9% (2,113 vulnerable cells). Of those, 64.9% dispatched an attacker tool call, 23.0% contacted the attacker endpoint and 12.1% verifiably exfiltrated a secret. Nine core frameworks clustered at 23–26% (chi-squared 3.30, p = 0.91), so resistance is model-level; model attack success ranged from 0.4% to 49.7%. A regex description scanner rejected 20 of 45 scenarios at a 7.2% false-positive rate. A code audit found no intentional defense in twelve frameworks, and all five coordinated disclosures to four vendors were rejected. It is newly relevant tonight because Palo Alto's Nov. 9 byline markets MCP tool-call inspection and skill scanning.
Why it matters
SLED developers and research groups wiring agents to MCP servers inherit this risk regardless of framework. Interpretation: the study gives buyers an independent way to test vendor MCP-inspection claims, since it shows scanning tool descriptions alone misses more than half of scenarios.
Evidence and measured results
Opened the arXiv abstract page and read the abstract, comments (accepted at AISec '26, co-located with ACM CCS 2026; 12 pages, 9 tables) and submission history (v1, 2 Nov 2026). Full PDF tables were not reviewed in this run; all figures come from the abstract.
Limitations and uncertainty
Preprint; peer review status is acceptance at a workshop. Results depend on the 45 chosen scenarios and 18 models. Only the abstract was inspected. It does not test any Palo Alto product. Counts are cells in a lab matrix, not field incidents.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-10; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Agent frameworks pass attacker-controlled MCP tool metadata into model context, and no tested framework defends against it intentionally.
- Stakeholders
- CISO
- Application security lead
- Research computing director
- AI governance committee
- Discovery questions
- Which MCP servers do your agents use, and who maintains them?
- Do you test agents against poisoned tool descriptions?
- What egress controls apply to agent hosts?
- Value hypothesis
- Interpretation: an independent test harness can show whether a given control reduces poisoning success below the study's 22.9% baseline in the customer's own setup.
- Potential engagement
- A bounded MCP red-team exercise using the study's open-source approach against one pilot agent workflow.
- Unsupported claims
- That any Palo Alto product was tested
- That lab success rates predict field incident rates
- That framework choice reduces risk
Pre-sales engineering
Role takeaway
- Fit
- Applies to any team running tool-integrated LLM agents over MCP.
- Architecture and integration
- Use runtime tool-call inspection and egress controls in addition to description scanning; the study's canary oracle can validate egress blocking.
- Prerequisites
- A non-production agent environment
- Canary endpoint for exfiltration detection
- Inventory of models and frameworks in use
- Constraints
- Only 45 scenarios
- Results vary strongly by model
- Abstract-level review only
- Security
- Poisoned descriptions, schema fields and responses can trigger attacker tool calls and secret exfiltration; regex scanning gives partial coverage with 7.2% false positives.
- Proof of value
- Measure poisoning success with and without the inspection control
- Record false-positive rate of any scanner on legitimate tools
- Verify canary exfiltration is blocked at egress
Delivery
Role takeaway
- Work
- Build and maintain a poisoning test set and run it as a gate before agent workflows go live.
- Dependencies
- Security engineering time
- Access to agent configurations
- Agreement on acceptable residual risk
- Ownership
- Application security or security engineering team responsible for agent deployments.
- Skills and adoption
- Teams need basic red-team skills for agent testing and an understanding of MCP metadata risks.
- Governance checkpoints
- Test results reviewed before production approval
- Re-test when models or MCP servers change
- Acceptance criteria
- Proposed: documented poisoning test run for every production agent workflow
- Proposed: no canary exfiltration in the final pre-production run
- Risks
- False confidence from metadata scanning
- Test drift as tools change
- Over-generalizing preprint figures
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?
Because resistance varies by model rather than framework, interpretation is that defenses must sit outside the model and framework, at runtime inspection of tool calls and egress, rather than in tool-description scanning alone.
Governance
Who approves, reviews and stays accountable for outcomes?
All five coordinated disclosures were rejected by vendors, which suggests organizations cannot assume framework maintainers will add defenses; local allow-listing of MCP servers becomes a governance requirement.
Security and privacy
What data, permissions and controls need testing?
Attacker-controlled tool descriptions, schema fields and responses enter model context without validation; 12.1% of vulnerable cells verifiably exfiltrated a secret.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Agent testing requires red-team skills many SLED teams lack; the open-source tool lowers the barrier but still needs trained staff.
Procurement
What should contracts, pricing and exit terms secure?
RFPs for agent-security tools should require vendors to demonstrate results against a poisoning test set rather than list features.
Operating model
Which teams own the service once it runs?
Pre-production poisoning tests should become a standing gate, re-run when models or MCP servers change.
Publication history
- 2026-11-09Palo Alto Networks · Issue 106 resources
Stable resource ID: arxiv-2611-03555-mcp-tool-poisoning-cross-framework-measurement-20261102