Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

Give Them an Inch and They Will Take a Mile:Understanding and Measuring Caller Identity Confusion in MCP-Based AI Systems

T0 review · 4 major / 5 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper argues that MCP servers, the middleware that lets AI agents call external tools, are fundamentally insecure when they treat authorization as a server-held state instead of binding it to the caller, and it measures that 46.4% of 6

desk verdict Real problem, useful measurement, but the 46.4% headline counts code-level authorization patterns as exploitable vulnerabilities without measuring whether the servers are actually reachable. read the letter →

arxiv 2603.07473 v2 pith:AW4MVA4K submitted 2026-03-08 cs.CR cs.AI

Yuhang Huang , Boyang Ma , Biwei Yan , Xuelong Dai , Yechao Zhang , Minghui Xu , Kaidi Xu , Yue Zhang This is my paper
classification cs.CRcs.AI
keywords ModelContextProtocolcalleridentityconfusionauthorizationreuseLLMagentsMCPsecuritytoolinvocationstaticanalysisaccesscontrol
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper identifies a vulnerability class it calls caller identity confusion in Model Context Protocol (MCP) servers: a single authorization decision, such as a one-time OAuth grant, is often cached as server-wide state and then reused for every later tool invocation, no matter which agent or caller triggered it. Because MCP does not require servers to authenticate or attribute the caller, an authorization granted during one legitimate interaction can silently govern requests from entirely unrelated, potentially remote, callers. The authors build an analysis tool that traces each tool invocation to resource-affecting operations and checks whether authorization is truly scoped to that invocation, then measure 6,137 real MCP servers and find 2,846 (46.4%) with missing, cached, or inconsistently enforced authorization. They show these patterns enable concrete attacks—remote command execution, browser and GUI hijacking, and persistent third-party API abuse—without credential theft or any explicit authorization bypass. The underlying message is that MCP servers must move from one-time, server-level trust to per-caller, per-invocation authorization.

What carries the argument

The central object is the vulnerability class 'caller identity confusion,' defined as the failure of an MCP server to bind authorization state to the identity of the caller that triggered a tool invocation. The technique that carries the argument is MCPAuthChecker, an invocation-centric analysis framework built around three abstractions: execution-trigger points (the program locations where a protocol-level tools/call request transitions into concrete execution, identified despite diverse registration and dispatch mechanisms), path-sensitive authorization evaluation (tracing each tool path to resource-affecting operations and checking whether authorization is explicitly enforced per invocati

What would settle it

Measure the real exposure of the 2,846 flagged servers: for each, determine whether it runs as a stdio-only single-client process, an SSE/HTTP network endpoint, or a multi-client deployment, and test whether a second non-authorized caller can actually issue a successful tool invocation. If nearly all flagged servers are stdio-only and single-client, the 46.4% rate would be a code-pattern statistic rather than a measure of exploitable identity confusion.

Watch

Extended reading notes

Core claim

The central claim is that MCP servers often cannot distinguish who is invoking a request, so a single authorization decision may implicitly grant execution authority to multiple, potentially untrusted callers. The paper formalizes this as caller identity confusion and argues it is not a flaw in the MCP specification but a natural consequence of how server developers implement authorization: many perform no checks, many authorize once and cache the resulting credentials or state, and only a minority bind authorization to caller identity and re-evaluate it for each new caller. To detect this, the authors design MCPAuthChecker, which shifts analysis from the server level to individual tool invo

Load-bearing premise

The claim collapses if an attacker cannot actually reach an already-authorized MCP server: the threat model assumes the attacker controls an agent or invocation source that can issue tools/call requests remotely to that server, but the measurement counts code-level authorization patterns, not how often servers are remotely reachable or multi-tenant.

Editorial extensions

If this is right

  • If the central claim holds, MCP deployments cannot rely on one-time OAuth or server-level trust: any remote agent that can speak the MCP protocol can inherit the authorization established by a legitimate user.
  • Developers of MCP servers should treat per-invocation, caller-bound authorization as a first-class design requirement, since the paper finds that developer-facing tools, which dominate the ecosystem, have a 52% insecure rate and expose dense execution interfaces.
  • The three demonstrated attacks—remote command execution, GUI and browser hijacking, and privileged third-party API abuse—become realistic post-exploitation paths that require no credential theft, memory corruption, or sandbox escape.
  • Authorization reuse patterns vary by functional category, with developer tools and API-integration servers relying most heavily on runtime authorization decisions, meaning risk assessment must go beyond counting vulnerable servers to considering what capabilities each server exposes.
  • A practical mitigation direction is to bind OAuth tokens, caller identity, and connection context into an isolated session during the initialize phase, and authorize every subsequent tools/call against that session.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The 46.4% figure is a measurement of authorization code patterns, not of network exposure or multi-tenant deployment; if most flagged servers run as single-client stdio processes with no remote interface and no co-located untrusted caller, the real-world exploitability would be substantially lower than the headline rate suggests.
  • The same caller-identity confusion likely extends beyond MCP to other agent middleware that caches authorization state, so the invocation-centric detection approach may transfer to similar execution-proxy architectures.
  • A protocol-level fix could be as effective as per-server fixes: if MCP standardized caller identity propagation and required servers to reject tools/call requests lacking an authenticated caller binding, the entire class of confusion would shrink even without changing individual server implementations.
  • One could test the paper's threat model directly by instrumenting a sample of flagged servers in realistic single-client and multi-client configurations and measuring how often a second, unauthorized caller can actually reach and invoke them.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper identifies a vulnerability class in MCP-based AI agent systems, termed 'caller identity confusion': MCP servers that cache or reuse authorization state without binding it to the identity of the invoking caller can let one authorized interaction implicitly authorize subsequent tool calls from different, possibly untrusted callers. The authors design MCPAuthChecker, a static/dynamic analysis framework that extracts MCP tool entry points, performs path-sensitive authorization analysis, and selectively validates ambiguous cases at runtime. They apply it to 6,137 Python/JavaScript MCP servers and report that 2,846 (46.4%) exhibit insecure authorization patterns (AuthNone, AuthCache, AuthRuntime). They also present three concrete attack sketches (remote command execution, browser/GUI control, persistent third-party API abuse) and report responsible disclosure of findings to a subset of high-star projects. The paper argues that these results demonstrate a systemic weakness in current MCP deployment practices.

Significance. If the central claim holds, this is a meaningful and timely contribution to the security analysis of MCP-based agent systems. The notion of caller identity confusion is well motivated and distinct from prior MCP threat models, and the invocation-centric analysis design addresses real engineering challenges (non-standard tool registration, decentralized authorization, stateful authorization reuse). The paper also provides concrete attack examples and a component-level evaluation with high recall for tool extraction (94% Python, 100% JS/TS) and authorization detection (~90-92%), which are useful strengths. However, the headline prevalence result depends on assumptions and classification definitions that are not fully validated end-to-end, as detailed in the major comments.

major comments (4)
  1. [§5.3 vs. §3.2] The headline '2,846 servers (46.4%) exhibit insecure authorization behavior' is computed from static code-level classification of authorization patterns, but the threat model in §3.2 requires that 'the attacker controls an agent or invocation source that can issue tools/call requests remotely to the already-authorized MCP server.' The paper does not measure how many servers are actually reachable by a remote attacker, how many are deployed behind mcp-remote/SSE/HTTP vs. plain stdio, or how often multiple callers share one server. Most MCP servers use stdio by default, so the 46.4% figure is an upper bound on source-level susceptibility, not a measured prevalence of exploitable systems. The authors should either measure adoption of remote-capable transports/multi-caller deployments or carefully reframe the claim as a code-level susceptibility measurement.
  2. [§5.2, Table 6] There is no end-to-end validation of the final secure/insecure classification. Table 6 reports recall and false-positive rates for tool extraction, authorization detection, and capability detection separately, but the 46.4% figure is the output of the combined classifier. The error rates of the components (e.g., authorization-detection FP 4.2-4.8%, capability-detection FP 8-9%) can compound, and the final label is never manually verified on a sample. In addition, the AuthRuntime category is defined as 'in-memory state or partial checks that may be inconsistently applied across tool invocations'; this is broad enough to include implementations that do perform per-request checks but keep any in-memory state. The paper needs a confusion matrix or manual audit of final labels, with particular attention to distinguishing AuthRuntime from secure per-invocation enforcement.
  3. [§5.3, Table 7] The numbers in Table 7 do not reconcile with the total dataset or with Table 5. Summing the rows of Table 7 by category gives 5,714, not 6,137; category totals also differ from Table 5 (e.g., Developer Tools 3,758 vs. 4,025; Other 52 vs. 82). The star-range rows similarly sum to 5,714. Since the 46.4% prevalence is the central quantitative claim, these inconsistencies are load-bearing. The authors need to clarify whether the unit is servers or tools, correct the table, and re-derive the headline percentage from the corrected data.
  4. [§1 and §6] The introduction and §6 report a 'preliminary analysis of 87 widely used open-source MCP-related projects' with 8 confirmed vulnerabilities and responsible disclosure, but the methodology for this analysis is not described: how the 87 projects were selected, how the 8 were confirmed, and whether these are a subset of the 6,137-server dataset. Without this context, the claim that the measured patterns 'translate into concrete and exploitable security risks' is supported only by the three illustrative examples in §6, whose selection criteria are also unspecified. A short description of the disclosure sample and confirmation process should be added.
minor comments (5)
  1. [Figures 5, 7, 8, 9] These figures appear to contain garbled character sequences (e.g., '/uni00000013/...') in the captions/labels, making them unreadable. They should be regenerated with proper text rendering.
  2. [§4.1 and throughout] The tool is called MCPAuthChecker, but at one point it is referred to as 'MAP' ('MAP further incorporates selective dynamic validation'). Please use one consistent name.
  3. [§2.3, §3.2, §4.2] Minor typos and stylistic issues: 'disussed' should be 'discussed'; 'we outline four representative attack scenarios' should have a capital 'We' after the semicolon; the heading 'C3.' should be 'C3:' for consistency with C1 and C2.
  4. [Algorithm 1] Algorithm 1's comment says 'enumerate reachable execution paths of the form, ensuring...' but the path form is not specified. Either complete the sentence or remove the dangling phrase.
  5. [References] Reference [12] (MCPCollection) appears to share overlapping authors with this paper. This is acceptable for a data source, but the paper should explicitly state the relationship in the dataset description to avoid any perception of undisclosed self-citation bias.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the prevalence result is a defined-code-pattern census, not a fitted prediction; the self-cited dataset is a data source, not the derived result.

full rationale

The paper's central claim ('2,846 servers (46.4%) exhibit insecure authorization behavior') is not a derived prediction that reduces to its inputs. The paper defines a security taxonomy (AuthNone, AuthCache, AuthRuntime) in §5.3 and uses MCPAuthChecker's path-sensitive static analysis plus selective dynamic validation to count servers matching those patterns. The classification is definitional ('We classify MCP tools as secure or insecure based on whether authorization is correctly enforced at each invocation'), but that is standard measurement, not circularity: the attacks in §6 are demonstrated on concrete servers (kjozsa_git-mcp, twolven_mcp-server-puppeteer, redhat-ai-tools/slack-mcp) and are consistent with, not assumed by, the classification. The threat-model premise in §3.2 that an attacker 'can issue tools/call requests remotely to the already-authorized MCP server' is an explicit assumption; the paper even notes it 'does not imply that an attacker can necessarily exploit the server.' Failing to measure network reachability is a validity/generalization concern, not a circularity. The only overlapping-author citation is the MCPCollection dataset [12], used as one of two repository sources; the security verdicts come from the present paper's own CodeQL-based code analysis and controlled dynamic execution, so this citation is not load-bearing in the derivation. No equation is fitted to target data, no uniqueness theorem is imported from the authors' prior work, and no ansatz is smuggled in via citation. The paper is therefore self-contained with respect to the circularity patterns considered here.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No numeric free parameters are fitted; the analysis uses rule-based classifications (AuthNone/AuthCache/AuthRuntime, sensitive-operation categories) rather than fitted constants. No new physical or technical entities are introduced; 'caller identity confusion' is a named vulnerability class, not a postulated mechanism.

assumptions (3)
  • domain assumption An attacker can issue tools/call requests to an already-authorized MCP server (remotely via mcp-remote or from a co-located process).
    Threat model in §3.2 assumes this reachability; the measurement counts code-level authorization patterns, not actual exposure, so exploitability claims depend on it.
  • domain assumption CodeQL-based path-sensitive analysis correctly identifies tool entries, authorization checks, and sensitive operations.
    MCPAuthChecker's verdicts rely on this; component precision/recall is reported on 100 projects but end-to-end per-server classification is not ground-truthed at scale (§5.2, Table 6).
  • domain assumption The 6,137 servers from MCPCollection and MCPZoo are representative of the real MCP ecosystem.
    Dataset is drawn from marketplaces (Smithery, MCPMarket, Pulse MCP) with most servers <50 stars (§5.1, Table 5); extrapolating to all deployments assumes representativeness.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Give Them an Inch and They Will Take a Mile:Understanding and Measuring Caller Identity Confusion in MCP-Based AI Systems." pith.science (2026). https://pith.science/paper/AW4MVA4K

@misc{pith2026260307473,
  author       = {Pith},
  title        = {Pith review of: Give Them an Inch and They Will Take a Mile:Understanding and Measuring Caller Identity Confusion in MCP-Based AI Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AW4MVA4K}},
  note         = {Machine review of arXiv:2603.07473}
}
read the original abstract

The Model Context Protocol (MCP) is an open and standardized interface that enables large language models (LLMs) to interact with external tools and services, and is increasingly adopted by AI agents. However, the security of MCP-based systems remains largely unexplored.In this work, we conduct a large-scale security analysis of MCP servers integrated within MCP clients. We show that treating MCP servers as trusted entities without authenticating the caller identity is fundamentally insecure. Since MCP servers often cannot distinguish who is invoking a request, a single authorization decision may implicitly grant access to multiple, potentially untrusted callers.Our empirical study reveals that most MCP servers rely on persistent authorization states, allowing tool invocations after an initial authorization without re-authentication, regardless of the caller. In addition, many MCP servers fail to enforce authentication at the per-tool level, enabling unauthorized access to sensitive operations.These findings demonstrate that one-time authorization and server-level trust significantly expand the attack surface of MCP-based systems, highlighting the need for explicit caller authentication and fine-grained authorization mechanisms.

Figures

Figures reproduced from arXiv: 2603.07473 by the authors.

Figure 1
Figure 1. MCP server workflow result, they form a critical boundary where model behavior directly influences security-sensitive execution. 2.2 Model Context Protocol As shown in [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Authorization and execution model of MCP servers [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Workflow of MCPAuthChecker Pattern Registration Mechanism Decorator-based @mcp.tool, @app.call_tool(...) Add-tool API mcp.add_tool(func), add_tool_handler(func) Tool Objects Tool(name, handler), types.Tool(...) FastAPI-MCP Route-based registration with operation_id Universal MCP Runtime enumeration via list_tools() Register API server.register_tool(func) ToolHandler Class Subclasses of ToolHandler [PITH_FULL_IMAGE:… view at source ↗
Figures from the paper (6 more)
Figure 5
Figure 5. Figure 5: Relationship between MCP server counts and ex [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 6
Figure 6. Figure 6: execution time overhead that depend on extracted tools. Authorization detection achieves 92.3% recall on Python and 90.1% on JavaScript/TypeScript, reflect￾ing the diversity of authorization implementations, while capability detection consistently attains recall above …
Figure 7
Figure 7. Figure 7: Vulnerable MCP Server Capabilities by Category [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]
Figure 10
Figure 10. Figure 10: Code fragment of MCP server kjozsa_git-mcp with git, attackers can exploit Git’s extensibility (e.g., git config –global core.editor) to execute arbitrary shell commands. Impact. This vulnerability effectively turns the MCP server into an unauthenticated remote comman…
Figure 9
Figure 9. Figure 9: Vulnerable MCP Server load credentials type [PITH_FULL_IMAGE:figures/full_fig_p012_9.png]
Figure 11
Figure 11. Figure 11: Secure MCP server with per-connection session [PITH_FULL_IMAGE:figures/full_fig_p015_11.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Protocol-Level Attacks on Agentic Commerce Platforms: A Cross-Platform Taxonomy, AIP-Bench, and Unified Defense

    cs.CR 2026-07 conditional novelty 6.0 of 10

    Protocol-level vulnerabilities in agentic commerce platforms are model-independent and can be measured with a deterministic benchmark and mitigated with a sidecar defense.

Reference graph

Works this paper leans on

34 extracted references · 7 linked inside Pith · cited by 1 Pith paper

  1. [1]

    Inayat Ali, Sonia Sabir, and Zahid Ullah. 2019. Internet of things security, device authentication and access control: a review.arXiv preprint arXiv:1901.07309 (2019)

    arXiv 2019

  2. [2]

    Anthropic. 2024. Introducing the Model Context Protocol. https://www. anthropic.com/news/model-context-protocol/

    2024

  3. [3]

    J Vijaya Chandra, Narasimham Challa, and Sai Kiran Pasupuletti. 2019. Authen- tication and authorization mechanism for cloud security.International Journal of Engineering and Advanced Technology8, 6 (2019), 2072–2078

    2019

  4. [4]

    Eric Y Chen, Yutong Pei, Shuo Chen, Yuan Tian, Robert Kotcher, and Patrick Tague. 2014. Oauth demystified for mobile application developers. InProceedings of the 2014 ACM SIGSAC conference on computer and communications security. 892–903

    2014

  5. [5]

    Quentin Colla, Kim Mens, and Julien Liénard. 2025. A Comparison of Three Program Query Languages to Detect Python Programming Misconceptions. In Companion Proceedings of the 9th International Conference on the Art, Science, and Engineering of Programming (Programming 2025). Schloss Dagstuhl–Leibniz- Zentrum für Informatik, 21–1

    2025

  6. [6]

    Marlon C Domenech, Azzedine Boukerche, and Michelle S Wangham. 2016. An authentication and authorization infrastructure for the web of things. In Proceedings of the 12th ACM symposium on QoS and security for wireless and mobile networks. 39–46

    2016

  7. [7]

    Herman Errico, Jiquan Ngiam, and Shanita Sojan. 2025. Securing the Model Context Protocol (MCP): Risks, Controls, and Governance.arXiv preprint arXiv:2511.20920(2025)

    arXiv 2025

  8. [8]

    Xiang Fei, Xiawu Zheng, and Hao Feng. 2025. Mcp-zero: Active tool discovery for autonomous llm agents.arXiv preprint arXiv:2506.01056(2025)

    arXiv 2025

Show all 34 references
  1. [9]

    2025.AI companies want a new internet — and they think they’ve found the key

    Hayden Field. 2025.AI companies want a new internet — and they think they’ve found the key. https://www.theverge.com/ai-artificial-intelligence/841156/ai- companies-aaif-anthropic-mcp-model-context-protocol

    2025

  2. [10]

    Nikos Fotiou, Iakovos Pittaras, Vasilios A Siris, Spyros Voulgaris, and George C Polyzos. 2020. OAuth 2.0 authorization using blockchain-based tokens.arXiv preprint arXiv:2001.10461(2020)

    2020 arXiv

  3. [11]

    GitHub. 2019. CodeQL Documentation. https://codeql.github.com/docs/ [Ac- cessed: Nov. 13, 2025]

    2019

  4. [12]

    Hechuan Guo, Yongle Hao, Yue Zhang, Minghui Xu, Peizhuo Lv, Jiezhi Chen, and Xiuzhen Cheng. 2025. A Measurement Study of Model Context Protocol Ecosystem.arXiv preprint arXiv:2509.25292(2025)

    2025

  5. [13]

    Yongjian Guo, Puzhuo Liu, Wanlun Ma, Zehang Deng, Xiaogang Zhu, Peng Di, Xi Xiao, and Sheng Wen. 2025. Systematic analysis of mcp security.arXiv preprint arXiv:2508.12538(2025)

    2025 arXiv

  6. [14]

    Mohammed Mehedi Hasan, Hao Li, Emad Fallahzadeh, Gopi Krishnan Rajbahadur, Bram Adams, and Ahmed E Hassan. 2025. Model context protocol (mcp) at first glance: Studying the security and maintainability of mcp servers.arXiv preprint arXiv:2506.13538(2025)

    2025 arXiv

  7. [15]

    Xinyi Hou, Yanjie Zhao, Shenao Wang, and Haoyu Wang. 2025. Model context protocol (mcp): Landscape, security threats, and future research directions.arXiv preprint arXiv:2503.23278(2025)

    2025 arXiv

  8. [16]

    I Indu and PM Rubesh Anand. 2016. Hybrid authentication and authorization model for web based applications. In2016 International Conference on Wireless Communications, Signal Processing and Networking (WiSPNET). IEEE, 1187–1191

    2016

  9. [17]

    2025.Anthropic says MCP will stay ’open, neutral, and community-driven’ after donating project to Linux Foundation

    Ross Kelly. 2025.Anthropic says MCP will stay ’open, neutral, and community-driven’ after donating project to Linux Foundation. https: //www.itpro.com/software/open-source/anthropic-says-mcp-will-stay-open- neutral-and-community-driven-after-donating-project-to-linux-foundation

    2025

  10. [18]

    Dezhang Kong, Shi Lin, Zhenhua Xu, Zhebo Wang, Minghao Li, Yufeng Li, Yilun Zhang, Hujin Peng, Xiang Chen, Zeyang Sha, et al. 2025. A survey of llm-driven ai agent communication: Protocols, security risks, and defense countermeasures. arXiv preprint arXiv:2506.19676(2025)

    2025

  11. [19]

    Shih-Hsiung Lee, Ko-Wei Huang, and Chu-Sing Yang. 2017. TBAS: Token-based authorization service architecture in Internet of things scenarios.International Journal of Distributed Sensor Networks13, 7 (2017), 1550147717718496

    2017

  12. [20]

    Carlo Mazzocca, Abbas Acar, Selcuk Uluagac, Rebecca Montanari, Paolo Bellav- ista, and Mauro Conti. 2025. A survey on decentralized identifiers and verifiable credentials.IEEE Communications Surveys & Tutorials(2025)

    2025

  13. [21]

    Mcpmarket. 2025. Find The Best MCP Servers. https://mcpmarket.com/

    2025

  14. [22]

    Michael Meli, Matthew R McNiece, and Bradley Reaves. 2019. How bad can it git? characterizing secret leakage in public github repositories.. InNDSS

    2019

  15. [23]

    Maria Papaioannou, Georgios Mantas, Dimitrios Lymberopoulos, and Jonathan Rodriguez. 2020. User authentication and authorization for next generation mobile passenger ID devices for land and sea border control. In2020 12th In- ternational Symposium on Communication Systems, Net...

    2020

  16. [24]

    Plusmcp. 2025. MCP Server Directory. https://www.pulsemcp.com/servers

    2025

  17. [25]

    Anjana Sarkar and Soumyendu Sarkar. 2025. Survey of LLM Agent Communi- cation with MCP: A Software Design Pattern Centric Review.arXiv preprint arXiv:2506.05364(2025)

    2025 arXiv

  18. [26]

    Siva Raja Sindiramutty and Noor Zaman Jhanjhi. 2026. Assessing User Authenti- cation and Authorization in Mobile Apps Ensuring Secure Access Control. In Analyzing Mobile Apps Using Smart Assessment Methodology. IGI Global Scientific Publishing, 57–94

    2026

  19. [27]

    Smithery. 2025. The fastest way to extend your AI. https://smithery.ai/

    2025

  20. [28]

    2017.{SmartAuth}:{User-Centered} authorization for the internet of things

    Yuan Tian, Nan Zhang, Yueh-Hsun Lin, XiaoFeng Wang, Blase Ur, Xianzheng Guo, and Patrick Tague. 2017.{SmartAuth}:{User-Centered} authorization for the internet of things. In26th USENIX Security Symposium (USENIX Security 17). 361–378

    2017

  21. [29]

    The Verge. 2025. Windows is getting support for the ‘USB-C of AI apps’. https://www.theverge.com/news/669298/microsoft-windows-ai-foundry- mcp-support Accessed: 2025-08-23

    2025

  22. [30]

    Bin Wang, Zexin Liu, Hao Yu, Ao Yang, Yenan Huang, Jing Guo, Huangsheng Cheng, Hui Li, and Huiyu Wu. 2025. Mcpguard: Automatically detecting vulner- abilities in mcp servers.arXiv preprint arXiv:2510.23673(2025)

    2025

  23. [31]

    Haohuang Wen, Juanru Li, Yuanyuan Zhang, and Dawu Gu. 2018. An empirical study of sdk credential misuse in ios apps. In2018 25th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 258–267

    2018

  24. [32]

    Mengying Wu, Pei Chen, Geng Hong, Baichao An, Jinsong Chen, Binwang Wan, Xudong Pan, Jiarun Dai, and Min Yang. 2025. MCPZoo: A Large-Scale Dataset of Runnable Model Context Protocol Servers for AI Agent. arXiv:2512.15144 [cs.CR] https://arxiv.org/abs/2512.15144

    2025

  25. [33]

    Yixuan Yang, Daoyuan Wu, and Yufan Chen. 2025. Mcpsecbench: A systematic security benchmark and playground for testing model context protocols.arXiv preprint arXiv:2508.13220(2025)

    2025

  26. [34]

    token.cache

    Weibo Zhao, Jiahao Liu, Bonan Ruan, Shaofei Li, and Zhenkai Liang. 2025. When mcp servers attack: Taxonomy, feasibility, and mitigation.arXiv preprint arXiv:2509.24272(2025). A Appendix A.1 Mitigating Identity Confusion From a defense perspective, mitigating caller identity co...

    2025

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.