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

Give Them an Inch and They Will Take a Mile: Understanding and Measuring Caller Identity Confusion in MCP-Based AI Systems Yuhang Huang Shandong University Qingdao, Shandong, China Boyang Ma Shandong University Qingdao, Shandong, China Biwei Yan Shandong University Qingdao, Shandong, China Xuelong Dai Shandong University Qingdao, Shandong, China Yechao Zhang Shandong University Qingdao, Shandong, China Minghui Xu Shandong University Qingdao, Shandong, China Kaidi Xu City University of Hong Kong Hong Kong, Hong Kong, China Yue Zhang ∗ zyueinfosec@sdu.edu.cn Shandong University Qingdao, Shandong, China Abstract The Model Context Protocol (MCP) is an open and standardized in- terface 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 un- explored.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 deci- sion 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 authentica- tion at the per-tool level, enabling unauthorized access to sensitive operations.These findings demonstrate that one-time authoriza- tion 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. CCS Concepts • Security and privacy→ Web Security. ∗ Corresponding author. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. Conference acronym ’X, Woodstock, NY © 2018 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-X-X/2018/06 https://doi.org/X.X Keywords Model Context Protocol, LLM Agent, Web Middleware, Authoriza- tion security ACM Reference Format: Yuhang Huang, Boyang Ma, Biwei Yan, Xuelong Dai, Yechao Zhang, Minghui Xu, Kaidi Xu, and Yue Zhang. 2018. Give Them an Inch and They Will Take a Mile: Understanding and Measuring Caller Identity Confusion in MCP- Based AI Systems. In Proceedings of Make sure to enter the correct conference title from your rights confirmation email (Conference acronym ’X). ACM, New York, NY, USA, 15 pages. https://doi.org/X.X 1 Introduction Large language model (LLM) agents are increasingly transitioning from purely informational roles to execution-bearing components that directly interact with backend systems. To bridge the gap between probabilistic model reasoning and deterministic system execution, recent deployments have adopted middleware-based execution architectures. Among these, the Model Context Protocol (MCP) [2] has emerged as a widely adopted interface that decouples agent reasoning from system-level actions. In MCP-based systems, agents issue structured tool invocations that are executed by inde- pendent MCP server processes, which hold the necessary creden- tials and execution context for accessing backend resources. Com- munity indicators reflect the rapid growth of MCP: practitioners have described it as “the USB-C of AI applications” [29], and indus- try commentary suggests that MCP is becoming a de facto standard for interoperable AI systems [9]. Its subsequent donation to the Linux Foundation further positions MCP as an open, community- driven standard rather than an experimental framework [17]. Unlike traditional middleware architectures, MCP servers oper- ate in a setting where execution requests are generated by LLM- driven agents rather than by user-facing clients that explicitly man- age identity and session state. Tool invocations are thus triggered through model-mediated interactions, without a standardized or protocol-level notion of the effective caller. In practice, LLMs are often deployed as third-party or stateless services and cannot be assumed to reliably preserve, bind, or forward user identity across arXiv:2603.07473v1 [cs.CR] 8 Mar 2026 interactions. To support continued tool execution under these con- straints, MCP servers commonly retain authorization decisions once they are established. While pragmatic, this approach trans- forms authorization from a per-invocation check into a persistent, server-held execution state. This abstraction implicitly assumes that all tool invocations re- ceived by an MCP server originate from a single, trusted caller context. In reality, MCP servers are frequently reused across mul- tiple agents, scripts, or applications, sometimes co-located on the same host. As a result, an authorization decision granted during one legitimate interaction may silently govern subsequent tool invoca- tions issued by entirely different callers. We refer to this previously underexplored vulnerability as caller identity confusion. When au- thorization is not explicitly bound to the caller that triggers a tool invocation, MCP servers may inadvertently enable authorization reuse across invocation contexts. Once an authorized execution state is established, subsequent tool calls (regardless of their ori- gin) can inherit this state without re-authentication. Notably, this behavior does not rely on credential theft, explicit authorization bypasses, or flaws in backend systems; rather, it emerges naturally from how authorization state is cached and reused within MCP servers. In effect, “give an MCP server an inch in authorization, and it may silently take a mile in execution authority”. This paper aims to determine whether an MCP server is subject to the caller identity confusion. Our idea is that this determination requires reasoning not about whether authorization logic merely exists in the code, but about whether a tool invocation that reaches a sensitive operation is authorized for the caller that triggered it. Translating this insight into a practical detection tool, however, presents several challenges. First, MCP servers do not provide stan- dardized or static execution entry points; tool invocations are ini- tiated through protocol-level tools/call requests and resolved via diverse and often dynamic dispatch mechanisms, making execution boundaries difficult to identify automatically. Second, authorization semantics are further decentralized and implementation-dependent, with checks scattered across handlers, dispatch logic, and helper functions rather than enforced at fixed APIs. Finally, authoriza- tion in MCP servers is frequently stateful, such that authorization obtained by one interaction may silently govern subsequent tool invocations, obscuring whether execution is constrained for the current caller. Guided by this insight, we design MCPAuthChecker, a frame- work that analyzes authorization at the granularity of individ- ual tool invocations. MCPAuthChecker first identifies execution- trigger points where protocol-level tool calls commit to concrete execution, independent of how tools are registered or dispatched. It then performs path-sensitive analysis to determine whether au- thorization is explicitly enforced along execution paths that lead to sensitive operations. To handle stateful authorization reuse, MAP further incorporates selective dynamic validation, observing exe- cution outcomes to verify whether tool invocations succeed under existing authorization state. Together, these techniques enable MAP to detect caller identity confusion by determining whether execu- tion authority is truly bound to the identity of the invoking caller. We perform a large-scale measurement of 6,137 real-world MCP servers and find that caller identity confusion is pervasive in prac- tice. Overall, 2,846 servers (46.4%) exhibit insecure authorization behavior, where authorization is missing, cached, or reused across invocations. Crucially, these vulnerabilities are not confined to specific categories or immature projects: insecure patterns persist across all functional domains and remain prevalent even among highly starred servers. Developer-facing MCP servers are particu- larly concerning (52% of them are insecure), as they both dominate the ecosystem and expose dense execution interfaces, amplifying the impact of authorization reuse. These measurement results are not merely indicative of poor engineering practices, but translate into concrete and exploitable security risks in real deployments. In practice, caller identity confusion enables attacks such as remote command execution, unauthorized UI control, and privileged API abuse. These attacks do not rely on memory corruption or creden- tial theft, but stem from MCP servers acting as long-lived execution proxies once authorized. We conducted a preliminary analysis of 87 widely used open- source MCP-related projects on GitHub, each with over 1K stars. Our analysis revealed that 8 of these projects suffer from authentication- related issues that could allow attackers to remotely execute com- mands on the MCP server. We responsibly reported the identi- fied vulnerabilities either directly to the repository maintainers or through the coordinated CVE disclosure process. During this process, the developers of two affected projects informed us that similar issues had already been reported and assigned CVE identi- fiers. Nevertheless, they acknowledged our reports and expressed appreciation for bringing the issue to their attention. For one addi- tional project, the vulnerability has already been fixed in the latest release. According to the repository’s commit history, the patch corresponds to the vulnerability described in our report. Five other projects are currently undergoing responsible disclosure. One of these projects acknowledged our report and is actively coordinat- ing the CVE assignment process. In their response, the maintainer thanked us for the report, describing it as an “excellent report,” and confirmed that they “will fix the issue” in the upcoming update. Through collaborative testing and verification between our team and the developers, we confirmed that the latest version success- fully mitigates the vulnerability. Following coordination with our team, the maintainers also publicly acknowledged our contribu- tion in the project’s release notes and community communication channels. As MCP increasingly mediates access to critical systems, a single authorization mistake can therefore escalate into broad and stealthy system compromise.This paper makes the following contributions: •We identify and formalize a previously underexplored vulner- ability in MCP deployments, which we term caller identity confusion. • Guided by an invocation-centric security model, we design MCPAuthChecker, a practical analysis framework for de- tecting caller identity confusion in MCP servers. •We conduct the first large-scale empirical study of caller identity confusion across 6,137 real-world MCP servers, find- ing that 46.4% exhibit insecure authorization behavior. We show that authorization reuse across invocation contexts enables real attacks such as remote command execution, GUI hijacking, and privileged API abuse without credential theft. Table 1: Execution-centric comparison of Agent paradigms Execution AspectIn-Process Plugin/API-Based Middleware Executed outside LLM runtime○␣○ Independent execution process○␣○ Clear execution boundary○␣○ Execution identity visible to backend○␣ Execution mediated by intermediary○␣è○ Centralized execution authority○␣○␣○ Execution decoupled from reasoning○␣è○ Supports system-level executionè○ Execution context shared across calls○␣○␣○ Legend:○ Absentè Partial / Implicit○ Explicit / Full 2 Background 2.1 AI Agents and Execution Paradigms Recent advances in large language models (LLMs) have enabled AI agents that go beyond passive text generation and actively inter- act with external systems. To translate model-generated decisions into concrete actions, modern agent frameworks rely on structured execution mechanisms that mediate access to databases, operat- ing systems, cloud services, and other system resources. These mechanisms define how probabilistic model outputs are bound to deterministic system execution. As shown in Table 1„ existing AI agent systems adopt several execution paradigms: •In-process Execution. One common approach is in-process execution, where tools are implemented as functions embed- ded directly within the agent runtime. In this model, the LLM produces structured outputs that are immediately exe- cuted in the same process, for example invoking local Python functions to read files or issue system calls. While this ap- proach simplifies integration, execution occurs with minimal isolation and weak execution boundaries. •Plugin/API-based Execution. One widely used paradigm is plugin- or API-based execution, in which agents invoke external services through predefined interfaces. For instance, an agent may issue HTTP requests to a cloud API or a data- base service that enforces its own authentication and au- thorization logic. This design introduces a clear execution boundary and allows backend systems to attribute and vali- date each request independently. •Middleware-based Execution. Agent middleware archi- tectures have emerged to decouple model reasoning from system execution. In this paradigm, execution capabilities are delegated to intermediary components that expose high- level actions as callable tools and execute them on behalf of the agent. The Model Context Protocol (MCP) is a rep- resentative example, where an independent server process exposes tools for database access, system interaction, or ex- ternal service invocation, and executes them using its own execution context. Despite their architectural differences, these execution paradigms share a common abstraction: agents do not directly manipulate system resources, but instead operate through capability-bearing execution interfaces. These interfaces translate high-level model intent into system-level operations and often hold the credentials and execution context required to perform privileged actions. As a Executed under MCP Server identity Executed under MCP Server identity Executed under MCP Server identity Structured Function Calls Tool Invoking Logic Backend Systems Databases Operation System/ Local Machine External Services MCP Servers （Execution Middleware) Centralized Execution Authority Capability Oriented Tools Database Query Tool File System Command Execution Tool External API Tool Tool Registry Execution Context Authorization State AI Agent Layer Natural Language Reasoning User 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 Figure 1, the Model Context Protocol (MCP) is a mid- dleware architecture designed to mediate execution between LLM- based agents and external systems. MCP adopts a client–server model in which an MCP client, typically an LLM-driven agent, is- sues structured tool invocations to an MCP server. The MCP server runs as an independent operating system process and acts as the sole execution endpoint for all agent-initiated actions. In MCP-based systems, the agent does not directly interact with backend resources. Instead, all execution follows a single, directed path: the agent generates a tool invocation, the MCP server inter- prets and executes the request, and backend systems receive opera- tions exclusively from the MCP server. From the agent’s perspective, tools appear as callable functions; from the system’s perspective, execution is performed entirely within the MCP server’s process boundary. The MCP server encapsulates execution-critical state, including tool definitions, execution context, and access creden- tials required to interact with backend systems such as databases, file systems, operating systems, and external services. As a result, backend systems authenticate and authorize requests based solely on the MCP server’s identity, without visibility into the originating agent or the intent behind individual tool invocations. MCP tools are the external interfaces exposed by MCP servers, defining the concrete operations that can be invoked by MCP clients or agents. An MCP server may expose multiple tools, each cor- responding to a specific capability such as querying a database, accessing files, or interacting with external services. Tool invoca- tions serve as the primary execution entry points into the MCP server: when a client issues a tool call, the request is routed to the corresponding server-side handler, which executes the associated logic under the server’s runtime context. As a result, the security properties of an MCP server are fundamentally determined by how its tools are implemented, dispatched, and protected. 2.3 MCP Execution and Authorization Model Unlike mobile platforms such as Android, where access to sensitive resources is mediated by a centralized operating system permis- sion framework, MCP servers operate in a fundamentally different authorization environment. In Android, permissions are enforced by the system at well-defined resource access points, and users Authorize MCPToolto connect to Facebook http://localhost MCPToolwill be able to: View data about your public profile (required) View your complete Facebook profile View data about your activities View data about your private activities Youractivitieswillnotcontainsensitivedata: ItlookslikeyoustillneedtoallowMCPToolto processyoursensitivedata.Pleasedothisinthe DataPermissionssectioninFacebook'ssettings beforeyouuploadyournextactivity. Authorize Cancel Basic information about the MCP server. The potentially sensitive information being requested. The potential consequences of disclosing such sensitive information. Asking the user whether they grant authorization Figure 2: Authorization and execution model of MCP servers are explicitly notified when applications attempt to access pro- tected resources (e.g., camera, microphone, or location). Crucially, authorization decisions are uniformly enforced by the OS and are independent of how individual applications implement their logic. In contrast, MCP servers do not benefit from a system-level au- thorization infrastructure. First, the set of sensitive operations in MCP-based systems extends beyond traditional system resources to include model-mediated actions, application-specific capabilities, and host-level operations exposed through tools. These resources vary widely in semantics and granularity and cannot be uniformly governed by a single permission interface. Second, MCP program- ming does not rely on a standardized SDK with built-in authoriza- tion primitives, as in the Android ecosystem. Instead, each MCP server implementation is responsible for defining and enforcing its own authorization logic. As a result, authorization behavior in MCP servers is highly implementation dependent. As shown in Figure 2, we observe three common authorization patterns. First, some MCP servers perform no authorization checks at all and assume that all tool invocations are implicitly trusted. Second, many servers perform authorization once and cache the resulting credentials or state locally, binding authorization only to the MCP server and the accessed resource. In this case, subsequent tool invocations reuse the cached authorization without regard to which agent or caller ini- tiated the request. Third, a smaller number of implementations bind authorization to the caller identity, requiring re-authorization when a new agent or invocation source interacts with the MCP server. 3 Caller Identity Confusion and Implications 3.1 The Vulnerability and Its Root Causes The authorization and execution semantics discussed in §2 enable practical and efficient tool-based execution for MCP servers. How- ever, as described above, MCP server implementations exhibit sub- stantially different authorization strategies, which critically affect how tool invocations are attributed at execution time. In particular, when authorization is not bound to the identity of the caller, security guarantees degrade significantly. In the first authorization pattern, where no authorization is performed, tool Google MCP Tool Invocation Unauthorized state and no credentials Facebook MCP Tool Invocation Executed under the user’s identity Configuration State/ Credentials State/credentials establishment Access Facebook? Yes! Google is a trusted company Facebook MCP Tool Invocation Executed under the user’s identity Configuration State/ Credentials Stored State/credentials Without user notification npx mcp-remote http://192.168.8.11:12345/mcp Remote Access Figure 3: Authorization reuse without caller binding. Please note that the user (or an attacker) can directly interact with the Facebook MCP tool. invocations execute without any access control and are trivially unsafe. In the second and more prevalent pattern, authorization is performed once and the resulting credentials or access state are cached within the MCP server. While this approach binds authoriza- tion to the server and the accessed resource, it does not distinguish between different callers or agent interactions. As a result, all sub- sequent tool invocations are implicitly treated as equally trusted once the server reaches an authorized state. Only the third pattern, in which authorization is explicitly bound to the caller identity and re-evaluated when a new caller interacts with the server, provides meaningful isolation between different invocation contexts. To illustrate the risk of authorization reuse without caller bind- ing, consider a deployment in which an MCP server developed by Google is granted access to a sensitive resource controlled by Facebook. Facebook authorizes the MCP server under the assump- tion that it will be invoked exclusively by Google-controlled agents. However, this assumption does not hold in practice. The MCP protocol explicitly supports remote invocation, allowing external agents to invoke an MCP server over the network (e.g., vianpx mcp-remote http://IP:port/mcp), provided that the server end- point is reachable. If the MCP server does not authenticate or dis- tinguish the identity of the invoking agent, then any remote and potentially untrusted agent capable of issuing tool invocations can indirectly operate under Facebook’s granted authorization. In this scenario, the attacker is neither co-located with the MCP server nor embedded within Google’s infrastructure; instead, it may be an arbitrary remote agent that simply speaks the MCP protocol. Crucially, the security failure does not arise from Facebook’s au- thorization decision itself, but from the MCP server’s failure to scope that authorization to the intended caller. This phenomenon is illustrated in Figure 3. Tool invocations may occur both before and after authorization is established. Once the MCP server enters an Agent-Accessible ResourceRepresentative MCP Tool or Action System-Level Execution System ExecutionExecute commands or programs on the host Process ManagementSpawn, terminate, or monitor processes Privileged OperationsInvoke administrative or elevated commands Environment ControlModify environment variables or runtime context Inter-Process CommunicationInteract with local services, sockets, or IPC Scheduling and Background TasksRegister timers or background jobs Persistent Data Access File Read / WriteRead or write local files Configuration FilesAccess or modify system or application configs Source Code and BinariesRead or alter code artifacts and executables Logs and Persistent StateAccess logs, caches, or application state Removable and Mounted StorageInteract with external or mounted storage Network and External Communication Network CommunicationSend outbound or inbound network requests Authenticated SessionsReuse existing sessions, cookies, or tokens Remote Service InteractionInvoke cloud services or remote APIs Data TransferUpload or download remote content Local Network InteractionDiscover or interact with local network services Physical / Human-Interface Operations Device and Interface InteractionInteract with physical devices or user interfaces Audio CaptureAccess microphone or record audio Camera and VideoAccess camera or capture video Display and ScreenCapture or manipulate screen output Input SimulationSimulate or capture keyboard and mouse actions Connectivity InterfacesInteract with Bluetooth, WiFi, or USB devices Table 2: Enumeration of agent-accessible resources. authorized execution state, subsequent operations are executed un- der a shared, server-held authorization, regardless of which agent interaction originally triggered them. Root Cause and Our Insight. MCP servers are particularly prone to authorization state reuse because they operate as mid- dleware between external resources and LLM-driven agents, where caller identity is conveyed indirectly through a model rather than explicitly through protocol fields. In traditional mid- dleware, caller identity is naturally maintained and propagated by user-facing applications, enabling authorization to be evalu- ated per request. In contrast, LLMs are often third-party, state- less, or privacy-preserving services that may not retain or be trusted to forward user identity. As a result, MCP servers cannot reliably depend on upstream components to supply stable caller identifiers and often resort to establishing authorization through direct user interaction and caching the resulting state for subse- quent tool invocations. While this design improves usability and supports autonomous agent execution, it shifts authorization from a per-call decision to a persistent server-held state, making caller identity confusion a natural but unintended consequence. Please note that caller identity confusion does not reflect a flaw in the MCP specification itself, but rather a consequence of how authorization semantics are implemented by MCP server developers. While MCP permits authorization state to be established and reused for efficiency, it does not mandate how this state should be scoped or attributed. When implementations fail to explicitly bind authorization to caller identity, identity confusion emerges as an unintended but exploitable outcome. 3.2 Attack Surface Analysis Threat Model. Our threat model is quite simple.First, we assume that, prior to any adversarial activity, a legitimate user has already used the MCP server and successfully completed the required au- thorization, such that the server holds valid authorization state. Importantly, this assumption does not imply that an attacker can necessarily exploit the server. Whether an adversarial tool in- vocation actually succeeds depends on the specific authorization and execution semantics implemented by the MCP server. In im- plementations that enforce per-invocation, caller-bound authoriza- tion, such invocations are correctly rejected. Second, the attacker controls an agent or invocation source that can issuetools/call requests remotely to the already-authorized MCP server. Attackers do not control the MCP server process itself and do not directly obtain credentials or other authorization material. Attacks and Security Impacts. At a high level, the exploitation of identity confusion follows a simple and practical pattern. After a legitimate user interaction has established authorization in an MCP server, an attacker-controlled agent remotely issues additional tools/callinvocations to that server. Because authorization is maintained as shared execution state, these subsequent invocations are executed under the previously established authorization, even though they originate from a different agent context. No credential theft or direct authorization bypass is required; instead, the attacker benefits from the reuse of existing authorization state within the MCP server. To reason about the impact of such exploitation, we examine the functional behavior of agents rather than specific tool implemen- tations. In practice, agents extend their capabilities by invoking tools that interact with external resources on their behalf. These resources may include local or remote systems, persistent storage, communication interfaces, or physical devices. Importantly, tools may be composed, invoked transitively, or implemented through multiple layers of abstraction. Therefore, we adopt a resource- centric view and classify tool invocations based on the type of resource they ultimately affect, rather than on how the tool is invoked or implemented. we outline four representative attack scenarios derived from the four resource categories summarized in Table 2. These scenarios are not exhaustive, but illustrate how authorization reuse across agent contexts can manifest as concrete and observable security failures: • System-Level Execution. Tool invocations that execute op- erating system actions, such as process management, shell commands, or system utilities. Under identity confusion, attacker-triggered commands may execute using authoriza- tion established for legitimate agent behavior, causing unin- tended system state changes. •Persistent Data Access. Interactions with persistent arti- facts, including files, configuration data, and logs. Identity confusion may allow attacker-triggered operations to access or modify data beyond the scope intended for their agent context, affecting subsequent executions. • Network and External Communication. Tool invoca- tions that issue network requests or interact with external services. Authorization reuse can cause attacker-triggered requests to be sent under trusted identities or sessions estab- lished by prior legitimate use. •Physical and Human-Interface Interaction. Tools that in- teract with physical devices or simulate human actions, such as peripheral control or sensor access. Attacker-triggered actions may be executed as if initiated by the legitimate user, directly impacting the physical environment or user experience. 4 Design of MCPAuthChecker 4.1 Core Idea and Design Overview Our tool is built on the observation that caller identity confusion arises not simply when authorization is missing, but when autho- rization is enforced at the server level without being bound to the identity of the caller that triggers a tool invocation. In such cases, au- thorization obtained through a legitimate interaction can be silently reused by subsequent invocations originating from different agents or execution contexts. To detect this class of vulnerabilities, the tool analyzes MCP server implementations from the perspective of attribution, asking a fundamental question: when a tool invo- cation ultimately affects a sensitive resource, is the authorization decision explicitly scoped to the identity of the caller that initiated the invocation? At a high level, the tool shifts authorization analysis from coarse- grained server-level assumptions to invocation-level attribution. Rather than reasoning about whether an MCP server supports au- thorization in general, the tool examines how authorization state is established, stored, and subsequently reused across tool invocations. It first identifies the execution entry points of MCP tools and then traces the control flow from each entry point to operations that in- teract with system, file, network, or physical resources. Along each execution path, the tool analyzes whether authorization is (i) per- formed at all, (i) cached as server-level state, or (i) explicitly bound to the caller identity associated with the invocation. Crucially, the tool does not assume that authorization established earlier in the server lifecycle is sufficient to justify subsequent executions. In- stead, it treats each tool invocation as a potentially distinct security principal whose actions must be individually attributable. If a path from a tool invocation to a resource-affecting operation relies on authorization state that is not scoped to the caller identity, the tool flags the corresponding tool as susceptible to caller identity confu- sion, even when authorization logic exists elsewhere in the server. 4.2 Challenges and Solutions C1: Non-standardized Tool Registration and Entry Points. Identifying where execution begins is a fundamental prerequisite for reasoning about authorization and security enforcement. In conventional systems, this problem is simplified by the presence of well-defined execution entry points. For example, C programs start from a fixedmainfunction, and Android applications expose stan- dardized lifecycle callbacks and permission-guarded APIs. These entry points provide a stable and semantically meaningful basis for analyzing control flow, authorization checks, and resource access. At first glance, MCP servers may appear similar to libraries or frameworks without a fixedmainfunction. In such settings, tradi- tional program analysis techniques typically treat exported func- tions or registered callbacks as potential entry points and reason about their reachable behaviors. However, this assumption does not directly carry over to MCP servers. Tool execution in MCP is initiated by protocol-leveltools/callrequests rather than di- rect function calls. The translation from atools/callrequest to executable code is realized through server-specific dispatch logic, which may involve dynamic lookups, indirection, or runtime con- struction of handlers. As a result, the execution entry of a tool invocation cannot be reliably identified by inspecting exported functions or callbacks alone. As a result, MCP servers realize tool execution through a wide range of implementation strategies. Some servers map tool names directly to handler functions, making the execution entry appear straightforward. Others route tool invo- cations through generic dispatchers, helper functions, or layered callback mechanisms, where the code that receives atools/call request is separated from the code that performs the actual opera- tion by multiple levels of indirection. In more complex designs, the set of available tools and their handlers is constructed dynamically at runtime, for example by enumerating configuration-dependent tool lists or loading handlers on demand. In conclusion, unlike con- ventional systems, tool execution in MCP servers does not begin at a well-defined function entry, but only after protocol-level dispatch and runtime binding. (S-1) Execution-Triggered Tool Entry Resolution. Our key insight is that, in MCP servers, the security-relevant notion of a tool entry is not a function boundary but the moment at which a protocol-leveltools/callinvocation commits to con- crete execution. Existing analyses fail because they search for fixed handler functions, while MCP implementations only ex- pose execution implicitly through dispatch logic. Guided by this insight, we model execution-trigger points as a first-class analy- sis abstraction. Instead of treating tool handlers as static entry functions, the tool identifies the program locations where an externaltools/callrequest transitions into internal execution behavior. Registration, dispatch, and runtime enumeration logic are thus treated not as endpoints, but as intermediate steps that collectively define when execution is triggered. C2: Implicit and Decentralized Authorization Semantics. Iden- tifying execution entry points alone is insufficient for reasoning about security. A second challenge lies in determining whether authorization is actually enforced along the execution path of a tool invocation. In many conventional platforms, authorization se- mantics are explicit, centralized, and tightly coupled with resource access. For example, modern operating systems enforce access con- trol through well-defined system calls and kernel-mediated checks; mobile platforms such as Android gate sensitive functionality be- hind fixed, permission-guarded APIs (e.g.,createBondto verify whether Bluetooth pairing has been initiated); and web frameworks often enforce authorization through standardized middleware or request filters that dominate application logic. These designs enable traditional authorization analysis to rely on stable assumptions: security checks occur at known API boundaries, and each execution request is evaluated independently at those boundaries. As a result, verifying authorization often reduces to identifying calls to specific APIs or ensuring that execution entry points are dominated by corresponding permission checks. However, in practice, MCP servers express authorization through heterogeneous mechanisms, including conditional checks embed- ded in tool handlers, validation logic placed in dispatch routines, au- thorization wrappers applied to subsets of tools, or resource-specific Execution ContextAuth State Per-Invocation Execution Backend CheckConstrained Visibility Pre-authorizationNone○␣○␣○␣ Authorization-triggeringEstablished○␣○␣ Subsequent callCached○␣○␣ Caller-bound authorization Per-caller○ Table 3: Authorization semantics across MCP executions checks implemented within helper functions. There is no fixed API boundary or framework-level hook that consistently delineates where authorization occurs. Consequently, authorization checks are not localized to a single program location but are often scattered across different execution paths. This diversity complicates analysis in two ways. First, the presence or absence of authorization cannot be inferred from the existence of specific APIs or framework con- structs. Second, determining whether a particular tool invocation is subject to authorization requires reasoning about the concrete exe- cution path that leads to resource-affecting operations, rather than inspecting isolated code fragments. As a result, analyses that rely on syntactic patterns or function-level summaries are insufficient to accurately characterize authorization enforcement in MCP servers. (S-2) Path-Sensitive Authorization Analysis. To recover au- thorization semantics in MCP servers, we analyze execution paths in a path-sensitive manner. Instead of treating authoriza- tion as a global server property, the analysis tracks where au- thorization state is established and how it propagates through the server’s execution context. For each tool invocation, the tool examines the concrete execution path from thetools/callen- try to resource-affecting operations and determines whether authorization (e.g., a conditional guard that validates the cur- rent invocation) is explicitly enforced along that path. Execution paths that rely solely on previously established or cached au- thorization state, without an explicit per-invocation check, are identified as lacking proper authorization enforcement. C3. Authorization State Confusion at Execution Time. While the absence of authorization checks clearly leads to insecure tool execution, the presence of authorization logic in MCP server code does not necessarily imply that executions are properly constrained. This challenge extends beyond identifying whether authorization exists, and concerns how authorization state is maintained and applied at execution time. As disussed in §2, many MCP servers implement authorization in a stateful manner. Authorization may be performed once and cached in memory, stored as a global flag, associated with a server-side session, or embedded in complex initialization logic. Subsequent tool invocations then rely on this cached state rather than reval- idating authorization for each invocation. As a result, the same execution path may appear to be guarded by authorization in the code, while at runtime it executes under an authorization state that was established by a different caller, prompt, or agent interaction. As summarized in Table 3, the presence of authorization state does not imply that individual tool executions are explicitly checked or properly attributed. For example, an MCP server may perform an authorization check during a setup phase and store the result in a global variable or server object. Later tool handlers consult this cached state before accessing sensitive resources, without verifying the identity or context of the current invocation. Although static in- spection reveals the presence of authorization logic, it is impossible to determine from code structure alone whether a given resource access is properly authorized for the invoking agent. This stateful execution model fundamentally limits purely static reasoning. Because authorization state evolves over time and is shared across tool invocations, static analysis cannot reliably de- termine whether authorization checks correspond to the current invocation or are inherited from prior ones. Consequently, even MCP servers that appear to implement authorization may still ex- hibit identity confusion, where resource-affecting operations are executed under authorization established by an unintended caller. (S-3) Selective Dynamic Authorization Validation. Our key insight is that authorization correctness in MCP servers is an execution-time property. Because authorization state may be cached or reused across tool invocations, static analysis alone cannot determine whether a resource operation is constrained for the current invocation. Accordingly, building on (S-2), the tool selectively validates authorization dynamically by observing execution outcomes. For tools whose paths contain authoriza- tion logic but where per-invocation enforcement is unclear, the tool issues controlled invocations to resource-affecting paths and checks whether execution succeeds without triggering an authorization failure. Successful execution indicates that the resource is accessible under the existing authorization state. 4.3 Workflow of MCPAuthChecker As shown in Figure 4, MCPAuthChecker detects identity con- fusion in MCP servers through a three-phase, execution-centric analysis. The first phase resolves where protocol-leveltools/call requests enter concrete execution logic, despite diverse tool reg- istration and dispatch patterns. The second phase analyzes how authorization is enforced along the resulting execution paths and whether such checks are explicitly applied to individual tool invo- cations. The third phase characterizes the resource-affecting opera- tions reached by each path to assess the security impact of missing or improperly scoped authorization. 4.3.1 Execution-Triggered Tool Entry Resolution. The first phase reconstructs fine-grained program dependencies and iden- tifies externally exposed MCP tool entry points. This component provides the foundational execution and data-flow information required by subsequent authorization analysis. (Step-I): Program Dependency Reconstruction. Colla et al.[5] show that CodeQL[11] achieves the best overall balance between precision and recall among common program query languages, due to its strong expressiveness and ability to reason over pro- gram structure, making it well suited for complex static analysis tasks.We first reconstruct how values are introduced, propagated, and transformed throughout the program. This analysis is imple- mented on top of CodeQL and operates over the abstract syntax tree (AST) of the MCP server. For each variable, the analysis records Source code CodeQLAST Parsing Function call Variables Object/Class Callback/Loop Location trace Mutation operation AST @mcp.tool mep.add_tool Tool(name, handler) FastAPlendpoint list_tools() ToolHandler subclass (Step-I): Program Dependency Reconstruction. (Step-I): MCP Tool Entry Extraction. Tool name Handler Registration pattern Source location Tool Entry Set Call Graph BFS Path Enumeration (Step-I) Execution Path Construction Load cache OAUTH Bearer Token Username/Password (Step-I) Sensitive Operation Identification Keyring (Step-I) Multi-Dimensional Authorization Evaluation AuthRuntime AuthCache NoAuth Static Analysis System Command File Read/Write HTTP Request Physical interface MCP-remote proxy SSE SERVER StdioSERVER Dynamic Analysis (Step-I): MCP Server Activation via Unified Proxy (Step-I) Execution Outcome Monitoring PHASE 1: Execution-Triggered Tool Entry Resolution PHASE 2: Path-Sensitive Authorization Analysis PHASE 3: Selective Dynamic Validation Figure 4: Workflow of MCPAuthChecker PatternRegistration 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-MCPRoute-based registration with operation_id Universal MCPRuntime enumeration via list_tools() Register API server.register_tool(func) ToolHandler ClassSubclasses of ToolHandler Table 4: Supported MCP tool registration patterns its assignment sites and usage locations, covering function param- eters, local variables, global variables, and object fields. Beyond direct assignments, the analysis recursively resolves entire expres- sions to capture implicit dependencies. If a variable refers to a composite object rather than a primitive value, the analysis further expands and tracks dependencies across its internal fields. Callback parameters are also handled explicitly, enabling the analysis to re- cover data-flow dependencies even when execution is deferred or indirect. These capabilities establish a precise foundation for sub- sequent taint and authorization reasoning. To improve precision and reduce false positives, the dependency reconstruction supports multiple dependency dimensions: (i) context-sensitive distinction between identifiers used as functions and variables, (i) type-based filtering to exclude container abstractions such asList,Dict, and Optional, (i) explicit callback parameter tracing to resolve lambda and higher-order functions, and (iv) loop-aware dependency track- ing to propagate sources through iterable constructs. (Step-I): MCP Tool Entry Extraction. Building on the recon- structed dependency graph, the second step identifies MCP tools exposed by the server. Since the MCP protocol permits developers to register tools through diverse and often dynamic mechanisms, tool entry points cannot be inferred from a single syntactic pattern. This component leverages CodeQL’s query capabilities to cover a wide range of tool registration styles. In addition to standard decorator-based registrations, the analysis resolves dynamic reg- istrations performed through helper functions, object constructors, framework-specific abstractions, and runtime enumeration inter- faces. For each identified tool, the component extracts the tool name, handler function, registration pattern, source location, and descrip- tive metadata. These extracted tool entries serve as the execution starting points for subsequent path-sensitive authorization analysis. Algorithm 1: Execution Path and Dependency Context Construction Input: AST analysis dataD Output: Contextual dependency mapM for MCP tools Initialize call graphG by resolving caller–callee relations fromD; Initialize contextual mapM ←∅; foreach tool handler 푡 ∈ D do // Identify Related Functions F 푟푒푙푎푡푒푑 ←all functions reachable from푡inGusing BFS or DFS; // Extract Dependency Chains Initialize tool contextC 푡 ←∅; foreach function 푓 ∈ F 푟푒푙푎푡푒푑 do foreach operation 표푝 ∈ 푓 (assignments or calls) do // Reconstruct dependency tree 푇푟푒 ← ExtractDependencyTree(표푝); if 푇푟푒 originates from parameters of 푡 then Associate 푇푟푒 with input-dependent data flow inC 푡 ; else Associate 푇푟푒 with internal or static logic inC 푡 ; Add(푡,F 푟푒푙푎푡푒푑 ,C 푡 ) toM; returnM 4.3.2 Path-Sensitive Authorization Analysis. The second phase performs path-sensitive authorization analysis by integrating function- level dependency information into complete execution paths and evaluating how authorization is enforced along these paths. This component builds directly on the outputs of last phase. (Step-I): Execution Path Construction. The first step constructs complete execution paths starting from each MCP tool entry. While the first component analyzes individual functions in isolation, this step connects them into inter-procedural execution paths that re- flect how tool invocations propagate through the program. Starting from each identified MCP tool handler, the analysis recursively resolves function calls by matching callee names and call-site refer- ences. For each function invocation, argument values are mapped to the corresponding parameters of the callee, allowing data depen- dencies to be propagated across function boundaries. This process continues until no further function calls can be resolved. The resulting execution structure is represented as a directed graph, where nodes correspond to functions and edges represent call relationships. The analysis maintains both a forward call graph (caller→callee) to track downward execution flow and a reverse call graph (callee←caller) to support backward reasoning. As shown in algorithm 1, breadth-first search (BFS) is used to enu- merate reachable execution paths of the form, ensuring systematic coverage of inter-procedural behavior. (Step-I): Multi-Dimensional Authorization Evaluation. The second step evaluates authorization enforcement along the con- structed execution paths. Rather than assuming a single authoriza- tion model, this module analyzes authorization logic across multiple dimensions to characterize how server identity is established and applied. Specifically, the analysis identifies the form of authoriza- tion used (e.g., OAuth, bearer token, API key, username/password, or local cached credentials), the timing of authorization (performed once at server startup or evaluated for each tool invocation), and the binding between authorization state and the caller. The analysis further determines whether authorization depends on tool input parameters or contextual information such as session identifiers or execution context objects. Authorization checks are detected using flow-sensitive analysis, allowing both explicit conditional checks and implicit validation logic to be identified. These checks are then associated with the execution paths on which they appear, enabling path-sensitive reasoning about whether authorization is enforced for a given tool invocation. (Step-I): Sensitive Operation Identification. The final step identifies sensitive operations along the constructed execution paths. While authorization analysis determines whether checks are present and how they are applied, security impact ultimately de- pends on what resources a tool invocation can affect. Based on the execution paths constructed in Step I, the analysis locates resource- affecting operations by matching calls to known sensitive APIs and runtime behaviors. These include system command execution, file system access, network communication, and interactions with external services or physical interfaces. Sensitive operations may appear directly in tool handlers or be invoked transitively through helper functions and library calls. 4.3.3 Selective Dynamic Validation. The third phase performs selective dynamic validation to resolve cases where static, path- sensitive analysis cannot determine whether authorization is effec- tively enforced at execution time. This component builds on the results of last phase and is applied only to tools whose execution paths contain authorization logic. (Step-I): MCP Server Activation via Unified Proxy. Dynamic validation requires executing MCP tools under realistic runtime con- ditions. However, MCP servers support multiple execution modes, including server-sent events (SSE)–based web services and stdio- based local processes. Directly handling these modes separately would complicate validation and reduce coverage. To unify dynamic validation across deployment modes, we leveragemcp-remoteas CategoryLanguageStars python js/ts 0–50 50–100 100–500 500–1000 >1000 Developer Tools1579 2446 34162472595251 Data Science & AI188275366473947 API & Integration1542373461913310 Productivity & Collaboration10621329581222 Web Scraping & Search141175280121743 Databases & Storage92132197101115 Security & Testing468411541001 Analytics & Monitoring3567894702 Cloud & Infrastructure3649761530 Other4438663715 Total2421 3716 5246 35538070 86 Table 5: MCP server counts by category, language, and GitHub star ranges. 05001000150020002500300035004000 MCP server count Other Cloud & Infrastructure Analytics & Monitoring Security & Testing Databases & Storage Web Scraping & Search Productivity & Collaboration API & Integration Data Science & AI Developer Tools Category 0-50 50-100 100-500 500-1000 >1000 Stars 0 1000 2000 3000 4000 5000 MCP server count Tool count 012-56-10>10 Figure 5: Relationship between MCP server counts and ex- posed tool functions across categories and star ranges. a protocol-level proxy. This proxy abstracts away the underly- ing execution mode and exposes a uniform interface for issuing tools/call requests. (Step-I): Execution Outcome Monitoring. After activation, the component monitors tool execution outcomes to determine whether authorization is enforced per invocation. Rather than modifying the MCP server, the system hooks into the proxy-mediated com- munication path to observe tool inputs and outputs. Concretely, all tools/callrequests issued by the MCP client are routed through the proxy, which forwards them to the MCP server and relays responses back to the client. This traffic-forwarding mechanism allows the system to capture invocation parameters, intermediate execution results, and final outputs for each tool call, regardless of whether the server runs in SSE or stdio mode. If a tool invoca- tion succeeds in performing a resource-affecting operation without triggering an authorization prompt or failure, the tool is deemed executable under the existing authorization state. Conversely, ex- plicit authorization failures indicate effective per-invocation en- forcement. 5 Evaluation 5.1 Experiment Setup Dataset. To systematically study the security of the MCP server ecosystem, we collected 6,137 MCP server projects implemented in Python and JavaScript, sourced from the MCPCollection [12] and MCPZoo [32] datasets.Table 5 summarizes the distribution of MCP servers by functional category and GitHub star range. Developer Tools form the largest category, and most servers fall within the 0–100 star range, indicating that the MCP ecosystem is still at an early and rapidly evolving stage. Figure 5 shows the sources from which MCP servers are collected. We observe that the ecosystem is largely centralized around a small number of MCP marketplaces, with Smithery Registry[27], MCPMarket[21], and Pulse MCP[24] together contributing over two-thirds of all collected servers, sug- gesting that our dataset provides a representative snapshot of the current MCP server ecosystem while highlighting key aggregation points where security issues may propagate. As discussed in §2, in MCP systems, tools represent the functional interfaces exposed by MCP servers, with each tool corresponding to a server-side function that can be invoked by clients. To character- ize how functionality is distributed across the MCP ecosystem, we measure, for each functional category, the number of MCP servers and the total number of exposed tool functions, further stratified by GitHub star ranges. Figure 5 shows a clear relationship between MCP server counts and exposed tool functions across categories. Categories with more servers consistently expose more tool func- tions, with Developer Tools standing out as the most prominent example. Beyond this aggregate trend, the distribution of tool func- tions is highly uneven: a small subset of categories contributes a disproportionately large share of the exposed functions. Since each exposed tool constitutes a callable execution interface, this concen- tration effectively expands the potential attack surface of the ecosys- tem in a highly uneven manner. This pattern persists across differ- ent popularity levels. As shown in Figure 5, categories with dense functional exposure remain so even among highly starred projects, suggesting that popularity alone does not imply reduced interface complexity. Taken together, these results indicate that functional exposure (shaped jointly by server prevalence and interface density) plays a central role in defining where security risks are likely to concentrate, motivating our subsequent function-level analysis. Hardware Environment. All experiments were conducted on a dedicated desktop machine equipped with an Intel Core i7-13700 CPU, 32 GB of main memory, and running Windows 11. The system is an HP Pro Tower 280 G9 Desktop PC and was used exclusively for analysis and evaluation to ensure a stable and reproducible execution environment. 5.2 Performance of MCPAuthChecker Effectiveness. Since our analysis operates at the function level, accurate extraction of MCP tool names is a prerequisite for all downstream analyses. We evaluate our tool extraction component by randomly sampling 100 MCP server projects from the MCP Col- lection, including 50 Python and 50 JavaScript/TypeScript projects (one project may contain multiple tools), and manually validating the extracted tools through dynamic setup and verification. Table 6 summarizes the results. Our approach achieves high recall for tool extraction on both languages (94.08% on Python and 100.00% on JavaScript/TypeScript), indicating that most ground-truth tools are successfully identified. The false positive rates remain moderate (7.40% on Python and 8.04% on JavaScript/TypeScript), primarily due to developer-defined helper or wrapper functions that resemble tool entry points. We further evaluate two downstream components Table 6: Effectiveness of MCPAuthChecker MetricPythonJavaScript/TypeScript Tool Extraction Projects Analyzed5050 Total Tools (Ground Truth) * 321309 Total Tools Identified338336 Recall94.08%100.00% False Negative Rate (FN)5.92%0.00% False Positive Rate (FP)7.40%8.04% Authorization Detection Recall92.30%90.10% False Negative Rate (FN)7.70%9.90% False Positive Rate (FP)4.20%4.80% Capability Detection Recall94.00%96.00% False Negative Rate (FN)6.00%4.00% False Positive Rate (FP)9.00%8.00% *Ground truth was established via dynamic source-code inspection. 0-250251-600601-15001501-3000>3000 Python LOC bin 0 50 100 150 200 250 300 350 Average time (s) AST + dependency Security analysis 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 94% on both languages. Overall, these results indicate that our extraction pipeline provides reliable function-level inputs for subsequent security analyses. Efficiency. Our tool is built on CodeQL and analyzes MCP servers through a multi-stage pipeline. The analysis cost is dominated by CodeQL database construction and query execution. To evaluate performance, we randomly sampled 100 MCP server projects cover- ing a wide range of codebase sizes, grouped them by lines of code (LOC), and measured the average analysis time per group. As shown in Figure 6, analysis time increases with project size, with a more pronounced growth for projects exceeding 3,000 LOC, reflecting the higher cost of dependency extraction in larger codebases. In contrast, the overhead introduced by the security analysis stage remains low and stable across all size ranges. Even for the largest projects, its cost is modest compared to dependency extraction. 5.3 Measuring Caller Identity Confusion We evaluated a total of 6,137 MCP servers, among which 2,846 were found to be vulnerable, corresponding to an overall vulnera- bility rate of 46.4%. In the following sections, we zoom in on these vulnerable instances from multiple perspectives: (I) Identity Confusion w.r.t. Categories and Popularity. Differ- ent functional categories expose MCP tools with varying capabili- ties, while GitHub stars are commonly used as a proxy for maturity Table 7: Identity Confusion w.r.t. categories and popularity Category / Stars SecureVulnerable #% AuthNoneAuthCache AuthRuntime #%#%#% By Category Developer Tools1712 48.0896 25.1 1454.1 100528.2 Data Science & AI180 45.196 24.1143.512832.1 API & Integration151 45.361 18.3144.213039.0 Web Scraping & Search130 45.085 29.493.17626.3 Productivity & Collaboration135 46.651 17.6258.610837.2 Databases & Storage104 53.1189.273.67538.3 Security & Testing48 40.332 26.9119.24134.5 Analytics & Monitoring34 37.817 18.977.84044.4 Cloud & Infrastructure38 54.310 14.3710.02231.4 Other22 44.013 26.036.01428.0 By Star Range 0–502225 48.1 1094 23.6 1813.9 136529.5 50–100124 39.278 24.7237.311737.0 100–500153 45.874 22.2267.811634.7 500–100029 50.016 27.6610.31424.1 >100023 34.817 25.869.12740.9 and code quality. Examining authorization practices across both functional domains and popularity levels therefore helps reveal whether insecure patterns are isolated to specific use cases or re- flect broader, systemic issues. We classify MCP tools as secure or insecure based on whether authorization is correctly enforced at each invocation, and further divide unsafe tools into AuthNone, AuthCache, and AuthRuntime. AuthNone refers to tools that perform no authorization checks be- fore or during execution. AuthCache denotes tools where authoriza- tion is performed only once (e.g., during initialization) and the result is cached locally and reused for subsequent invocations without re- validation. AuthRuntime captures tools that enforce authorization at runtime, but rely on in-memory state or partial checks that may be inconsistently applied across tool invocations. Table 7 shows that insecure tools dominate across all categories and star ranges. By category, Developer Tools contain the largest absolute number of unsafe tools, with over 50% classified as insecure, and similar trends appear in API & Integration, Databases & Storage, and Produc- tivity & Collaboration. By star range, insecure patterns persist even among highly starred projects, where AuthNone and AuthRuntime remain prevalent, indicating that popularity does not reliably imply stronger authorization practices. Moreover, the persistent presence of AuthCache patterns in long-lived and infrastructure-oriented tools highlights a reuse-oriented design flaw with cross-context security implications. Overall, these results suggest that authoriza- tion weaknesses in MCP tools are systemic rather than category- or maturity-specific, and that powerful, developer-facing tools fre- quently expose functionality without runtime authorization. (I) Identity Confusion w.r.t. Exposed Capabilities. While prior analysis characterizes how authorization flaws are distributed across MCP server categories, an equally important question is what kinds of security consequences these vulnerable servers can enable once invoked without proper authorization. To capture this relationship, we map vulnerable MCP servers to the classes of security conse- quences (based on their APIs) enabled by their exposed tools and analyze the distribution across categories. As shown in Figure 7, Developer Tools Data Science & AI API & Integration Web Scraping & Search Productivity & Collaboration Databases & Storage Other Security & Testing Cloud & Infrastructure Analytics & Monitoring Category 0 200 400 600 800 1000 1200 Insecure MCP server count 1196 151 161 120 110 36 14 42 23 43 (a) Network and External Communication Developer Tools Data Science & AI API & Integration Web Scraping & Search Productivity & Collaboration Databases & Storage Other Security & Testing Cloud & Infrastructure Analytics & Monitoring Category 0 200 400 600 800 Insecure MCP server count 748 95 52 56 62 21 17 38 9 21 (b) Persistent Data Access Developer Tools Data Science & AI API & Integration Web Scraping & Search Productivity & Collaboration Databases & Storage Other Security & Testing Cloud & Infrastructure Analytics & Monitoring Category 0 100 200 300 400 Insecure MCP server count 398 49 1919 26 7 11 27 7 8 (c) System-Level Execution Developer Tools Data Science & AI API & Integration Web Scraping & Search Productivity & Collaboration Databases & Storage Other Security & Testing Cloud & Infrastructure Analytics & Monitoring Category 0 100 200 300 400 Insecure MCP server count 394 56 31 44 42 61 7 23 1010 (d) Physical and Human-Interface Interaction Figure 7: Vulnerable MCP Server Capabilities by Category vulnerable developer tools often aggregate multiple powerful ca- pabilities, allowing a single authorization failure to escalate into diverse and high-impact outcomes. In contrast, other categories display more specialized consequence patterns. For example, API & Integration and Web Scraping & Search servers primarily enable network-centric actions, while Databases & Storage servers pre- dominantly expose persistent data access. Although system-level execution appears in fewer categories, it represents particularly severe consequences when present. It can be observed that a tight coupling between MCP server categories and the types of security consequences they enable. These results suggest that security risks in the MCP ecosystem cannot be assessed solely by counting vul- nerable servers, but must also consider the nature and severity of the actions those servers make possible. (I) Identity Confusion w.r.t. Developers. Beyond functional categories, another important dimension is who develops vulnera- ble MCP servers. Understanding how vulnerable implementations are distributed across authors helps distinguish isolated mistakes from patterns that may arise through development practices. To this end, we analyze the authorship of vulnerable MCP servers. Figure 8 shows that vulnerable MCP server implementations are highly con- centrated among a small subset of authors. As shown in Figure 8(a), a limited number of developers account for a disproportionately large number of vulnerable MCP servers. Figure 8(b) illustrates the relationship between authors and their total MCP servers across all projects. The top three authors in total server count are also the top three in vulnerable servers, with about one-third of their servers being vulnerable. Such clustering amplifies the potential impact of authorization flaws through repeated reuse. (IV) Identity Confusion w.r.t. Reuse Patterns Across Cate- gories. Beyond whether authorization exists, authorization reuse patterns (e.g., runtime, cached) is enforced plays a critical role in shaping the security behavior of MCP servers. Examining this di- mension across functional categories helps reveal category-specific design assumptions. We therefore analyze vulnerable MCP servers by categorizing their authorization reuse patterns behavior across 0102030405060 Vulnerable MCP Server Count mcp-mirror kukapay DynamicEndpoints cyanheads mario-andreschak GongRzhe crazyrabbitltc bsmi021 MCP-Mirror samihalawa Author 58 11 10 7 7 7 6 6 6 6 (a) Top Authors by Vulnerable Projects 050100150200 MCP Server Count mcp-mirror kukapay DynamicEndpoints MCP-Mirror bsmi021 GongRzhe aliyun kazuph bmorphism falahgs Author 187 30 17 16 15 15 12 11 11 10 (b) Top Authors by All Projects Figure 8: vulnerable MCP Server by author AuthCacheAuthRuntime Load credentials Type Developer Tools API & Integration Data Science & AI Productivity & Collaboration Databases & Storage Web Scraping & Search Security & Testing Cloud & Infrastructure Analytics & Monitoring Other Category 1451005 14130 14128 25108 775 976 1141 722 740 314 200 400 600 800 1000 Figure 9: Vulnerable MCP Server load credentials type different functional domains. Figure 9 shows that vulnerable au- thorization reuse patterns are strongly correlated with MCP server categories. In particular, Developer Tools and API & Integration servers exhibit the largest number of vulnerable instances that rely on runtime authorization decisions. Such designs implicitly assume a stable and trusted execution context, an assumption that breaks down in the presence of multiple callers or cross-context invocations. In contrast, categories such as Analytics & Monitoring and Cloud & Infrastructure display comparatively fewer vulnerable reuse patterns, suggesting more conservative or narrowly scoped execution models. These results indicate that vulnerable authoriza- tion often stems not from the complete absence of checks, but from flawed assumptions about execution context and caller identity. 6 Real MCP Attacks and Security Implications In the following, we demonstrate several real-world attacks that exploit these weaknesses; detailed defense mechanisms and protec- tion strategies are discussed in Appendix A.1. Attack-I: Agent-Originated RCE. The MCP server namedkjozsa _git-mcpexposes a tool that executes Git commands by directly passing tool parameters into a system command invocation, as shown in Figure 10. The tool performs no authentication, no caller verification, and no input sanitization, and executes commands with the privileges of the MCP server process. Because MCP does not require the server to authenticate or bind the caller identity, any local or remote program capable of invoking this MCP tool can supply arbitrary arguments. Although the command is prefixed def _run_git_command(repo_path: str, command: List[str]) -> str: full_command = ["git"] + command result = subprocess.run( full_command, cwd=repo_path, check=True, capture_output=True, text=True) return result.stdout 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 command execution endpoint. When deployed on developer machines, CI infrastructure, or cloud servers, an attacker can achieve persistent code execution, credential theft, or lateral movement. The attack does not rely on memory corruption or sandbox escape; instead, it abuses the MCP execution model itself, resulting in system-level compro- mise through legitimate agent tooling. Attack-I: Unauthenticated Browser and GUI Control. We found some MCP servers (e.g.,twolven_mcp-server-puppeteer, AB498/computer-control-mcp) expose tools that directly control browsers and GUI interactions, including page navigation, screen- shot capture, mouse movement, and keyboard input. Tool invo- cations are not authenticated, and all action parameters originate directly from MCP tool inputs. Because the MCP server does not distinguish who invoked the tool, any external process can remotely drive real user interfaces through MCP. This includes automated interaction with websites, triggering UI-based workflows, or cap- turing visual output from the host system. Impact. This attack enables remote hijacking of hu- man–computer interfaces without requiring desktop access, malware installation, or user interaction. An attacker can silently operate browsers, manipulate GUI-driven applications, and extract visual information. In practice, this allows bypassing se- curity mechanisms such as CAPTCHA, UI-based confirmations, and multi-step workflows, escalating MCP misuse into real- world user action manipulation rather than mere data access. Attack-I: Persistent Third-Party API Abuse. We found some MCP servers (e.g.,redhat-ai-tools/slack-mcp, aws-cost-expl orer-mcp-server) authenticate once during initialization using high-privilege credentials (e.g., Slack tokens or AWS SDK creden- tials) and subsequently reuse this authorization state for all tool invocations. Tool calls do not re-authenticate per request and are not bound to the caller identity. As a result, any entity capable of invoking MCP tools can indirectly perform privileged operations on third-party services without possessing credentials or triggering additional authorization checks. Impact. This vulnerability transforms the MCP server into a long-lived, high-privilege API proxy. Attackers can read or post Slack messages, query cloud usage data, or interact with enter- prise services under a legitimate account context. Since all oper- ations use valid credentials, external services cannot distinguish malicious use from intended agent behavior, enabling stealthy cross-system privilege abuse with limited forensic visibility. 7 Related Work MCP Security. Recent work has extensively examined the security, architecture, and ecosystem challenges of the Model Context Proto- col (MCP) and LLM-driven agent systems. Errico et al. [7], Hou et al. [15], and Sarkar et al. [25] analyze MCP as a foundational interop- erability layer for agent–tool integration, proposing threat models, taxonomies, and design patterns to improve security, scalability, and reliability. Automated vulnerability detection and evaluation have also been explored: MCPGuard [30] and MCPSECBENCH [33] formalize MCP attack surfaces and empirically assess defenses, while studies reveal real-world risks such as malicious servers [34], ecosystem-level security and maintainability issues [14], and the transferability of MCP-specific attack techniques [13]. Beyond MCP, Kong et al. [18] propose a layered taxonomy for LLM agent com- munication protocols and experimentally demonstrate risks such as protocol manipulation and tool poisoning, and Fei et al. [8] ad- dress MCP scalability with significantly reduced token consumption. Complementing prior works, our work introduces an execution- centric perspective that inspects how authorization is actually ap- plied along tool execution paths in MCP server implementations. Authorization Security. Prior studies have extensively examined authorization and credential security across mobile, cloud, IoT, and distributed systems (e.g., [1,3,6,10,16,19,20,22,23,26,28,31]). For example, Wen et al. [31] revealed widespread SDK credential misuse in iOS applications and proposed iCredFinder to detect exposed cre- dentials in Mach-O binaries, while Meli et al. [22] demonstrated that leaked secrets can be discovered almost immediately from version control histories, rendering deletion alone ineffective. In broader identity and authorization contexts, Mazzocca et al. [20] identified key threats such as credential correlation and revocation challenges, and Chen et al. [4] showed that OAuth flows become ambiguous and error-prone when applied to mobile platforms. In contrast, our work focuses on a new execution paradigm (MCP), leading to new caller identity confusion that existing tools do not capture. 8 Conclusion As MCP increasingly serves as the execution substrate for LLM agents, authorization reuse without explicit caller binding intro- duces a systemic security risk. We identify caller identity confusion as a fundamental flaw in current MCP deployments, demonstrate its real-world exploitability, and present MCPAuthChecker to detect such vulnerabilities at the granularity of individual tool in- vocations. Our large-scale measurement shows that this issue is widespread across the MCP ecosystem and persists across cate- gories and project maturity levels. These findings highlight the need for invocation-level, caller-bound authorization as a first-class design principle for agent execution frameworks. Ethical Considerations Our work analyzes authorization and access control mechanisms in MCP servers and strictly follows the ACM CCS ethical guidelines for security measurement research. First, all MCP servers analyzed in this work were collected ex- clusively from publicly available online repositories. Our analy- sis relied primarily on static analysis and controlled local testing conducted in fully author-owned environments. No experiments interacted with live production services, external networks, or third- party infrastructure, and no measurements were performed against deployed systems. Second, throughout the study, we avoided any form of real- world exploitation. No real user credentials, API keys, access tokens, or sensitive data were used, and no malicious payloads, privilege escalation attempts, or unauthorized operations were executed. All security findings were derived from code-level inspection and semantic reasoning about authorization logic, rather than from triggering vulnerabilities in operational deployments. Third, when authorization and access control weaknesses with realistic security implications were identified, we followed respon- sible disclosure practices. Due to the large number of affected MCP servers uncovered in this study, it was not feasible to report all findings simultaneously. We therefore adopted a staged disclosure strategy. Some vulnerabilities identified were reported in January privately to corresponding maintainers through appropriate chan- nels, including GitHub security advisories, restricted issue trackers, or direct maintainer contact when available. We are continuing to engage with more maintainers and plan to disclose additional findings in follow-up rounds. References [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). [2]Anthropic. 2024. Introducing the Model Context Protocol.https://w. anthropic.com/news/model-context-protocol/ [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 Technology 8, 6 (2019), 2072–2078. [4]Eric Y Chen, Yutong Pei, Shuo Chen, Yuan Tian, Robert Kotcher, and Patrick Tague. 2014. Oauth demystified for mobile application developers. In Proceedings of the 2014 ACM SIGSAC conference on computer and communications security. 892–903. [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. [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. [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). [8] Xiang Fei, Xiawu Zheng, and Hao Feng. 2025. Mcp-zero: Active tool discovery for autonomous llm agents. arXiv preprint arXiv:2506.01056 (2025). [9]Hayden Field. 2025. AI companies want a new internet — and they think they’ve found the key. https://w.theverge.com/ai-artificial-intelligence/841156/ai- companies-aaif-anthropic-mcp-model-context-protocol [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). [11]GitHub. 2019. CodeQL Documentation. https://codeql.github.com/docs/ [Ac- cessed: Nov. 13, 2025]. [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). [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). [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). [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). [16]I Indu and PM Rubesh Anand. 2016. Hybrid authentication and authorization model for web based applications. In 2016 International Conference on Wireless Communications, Signal Processing and Networking (WiSPNET). IEEE, 1187–1191. [17]Ross Kelly. 2025.Anthropic says MCP will stay ’open, neutral, and community-driven’ after donating project to Linux Foundation.https: //w.itpro.com/software/open-source/anthropic-says-mcp-will-stay-open- neutral-and-community-driven-after-donating-project-to-linux-foundation [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). [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 Networks 13, 7 (2017), 1550147717718496. [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). [21] Mcpmarket. 2025. Find The Best MCP Servers. https://mcpmarket.com/ [22] Michael Meli, Matthew R McNiece, and Bradley Reaves. 2019. How bad can it git? characterizing secret leakage in public github repositories.. In NDSS. [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. In 2020 12th In- ternational Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP). IEEE, 1–6. [24] Plusmcp. 2025. MCP Server Directory. https://w.pulsemcp.com/servers [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). [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. [27] Smithery. 2025. The fastest way to extend your AI. https://smithery.ai/ [28]Yuan Tian, Nan Zhang, Yueh-Hsun Lin, XiaoFeng Wang, Blase Ur, Xianzheng Guo, and Patrick Tague. 2017.SmartAuth:User-Centeredauthorization for the internet of things. In 26th USENIX Security Symposium (USENIX Security 17). 361–378. [29]The Verge. 2025.Windows is getting support for the ‘USB-C of AI apps’. https://w.theverge.com/news/669298/microsoft-windows-ai-foundry- mcp-support Accessed: 2025-08-23. [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). [31]Haohuang Wen, Juanru Li, Yuanyuan Zhang, and Dawu Gu. 2018. An empirical study of sdk credential misuse in ios apps. In 2018 25th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 258–267. [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 [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). [34]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 confusion in MCP servers can be approached from two complementary direc- tions: system-level enforcement mechanisms and developer-driven authorization discipline. These approaches differ in where trust is placed and how much responsibility is shifted away from MCP server implementations. System-Level Protection and Permission Enforcement. One possible direction is to introduce system-level protection mecha- nisms that mediate MCP tool execution independently of applica- tion logic. This includes enforcing permissions at the operating system, runtime, or container level, such that sensitive operations (e.g., process execution, file access, network requests, or device inter- action) are constrained by external policy rather than solely by MCP server code. For example, MCP servers could be deployed within sandboxed environments that restrict access to system resources unless explicitly granted. In such designs, even if authorization state is improperly reused within the MCP server, the impact of unautho- rized tool invocations can be limited by mandatory access controls, capability-based execution, or container isolation. While effective at reducing blast radius, these mechanisms are coarse-grained and do not address the root cause of caller identity confusion at the MCP layer. They also require additional system support and careful policy configuration, which may not be feasible in lightweight or user-installed MCP deployments. Developer-Enforced Session and Caller Identity Management. A more direct and MCP-specific defense relies on correct autho- rization semantics implemented by MCP server developers. In par- ticular, authorization should be explicitly scoped to caller identity and session context, rather than cached as a global server state. Although OAuth is commonly used to authenticate users or ob- tain access tokens, OAuth alone does not establish MCP session boundaries or distinguish between different callers. As illustrated in Figure 11, a robust design treats theinitializephase as the sole entry point for session creation, binding the OAuth token, caller identity (e.g.,client_id), and connection context into an isolated session. Each subsequenttools/callinvocation is then authorized with respect to this session, preventing token reuse and privilege inheritance across connections. This approach ensures that even when valid tokens exist, unauthorized or unexpected callers cannot invoke tools without completing a proper initialization flow. While this defense places responsibility on developers, it aligns naturally with MCP’s execution model and provides fine-grained control over authorization scope. Our detection tool complements this approach by helping developers identify where such binding is missing or inconsistently enforced in existing MCP server implementations. SESSIONS = def mcp_initialize(connection_id: str, client_name: str): token, client_id = open("token.cache").read().split(":") if client_id != client_name: raise PermissionError("caller mismatch") session = # Creates fresh session per connection "session_id": uuid4().hex, "token": token, "client_id": client_id, "connection_id": connection_id, SESSIONS[connection_id] = session return "session_id": session["session_id"] def mcp_call(connection_id: str, params): if connection_id not in SESSIONS: raise PermissionError("session not initialized") return run_tool(SESSIONS[connection_id], params) Figure 11: Secure MCP server with per-connection session