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

This paper reveals that MCP-based AI systems are fundamentally insecure due to a lack of caller identity authentication, which allows persistent authorization states and missing per-tool checks to enable unauthorized access to sensitive operations by untrusted callers.

The Gist

Here is an explanation of the paper "Give Them an Inch and They Will Take a Mile," translated into simple language with everyday analogies.

The Big Picture: The "Universal Remote" Problem

Imagine you have a Universal Remote Control for your house. This remote can turn on the TV, unlock the front door, adjust the thermostat, and even order pizza.

In the world of AI, this "Universal Remote" is called MCP (Model Context Protocol). It allows AI assistants (like a super-smart chatbot) to talk to real-world tools (like your email, your computer files, or your bank account).

The Problem:
The researchers found that many of these "Remotes" (MCP servers) are built with a dangerous flaw. They assume that once you let the remote in the house, it can do anything, forever, without asking who is holding it.

If you give the remote a "key" to unlock the front door just once, the remote assumes anyone who picks it up later is still you. It doesn't check if a stranger is holding it. This is called Caller Identity Confusion.

---

The Core Analogy: The "Trust Me" Hotel

To understand the vulnerability, imagine a high-end hotel with a Concierge Desk (the MCP Server).

1. The Setup: You (the user) walk up to the Concierge and say, "I want to book a spa appointment." The Concierge checks your ID, sees you are a VIP, and says, "Okay, you are authorized."
2. The Flaw: The Concierge writes "VIP Status: Active" on a sticky note and sticks it to the counter. They don't check your ID again.
3. The Attack: A stranger (the attacker) walks up to the same counter, picks up the phone, and says, "I want to book a private jet."
4. The Result: The Concierge looks at the sticky note, sees "VIP Status: Active," and books the jet. They never asked, "Who is holding the phone right now?"

In technical terms: The AI server gets authorized once by a legitimate user. Then, an attacker sends a request. The server sees it has a valid "ticket" (authorization state) and lets the attacker do whatever they want, thinking the attacker is the original user.

---

What Did the Researchers Do?

The team from Shandong University and City University of Hong Kong built a tool called MCPAuthChecker. Think of this tool as a Security Inspector who walks through thousands of these "Hotels" (MCP servers) to see how they handle guests.

How the Inspector works:

1. Maps the Hallways: It looks at the code to see where the "doors" (tools) are.
2. Checks the Bouncers: It traces the path of a request to see if a "Bouncer" (authorization check) stops and asks for ID every single time a door is opened.
3. The "Fake Guest" Test: It tries to send a request from a "fake guest" to see if the server lets them in just because a "real guest" was there earlier.

The Findings: It's Everywhere

They inspected 6,137 real-world MCP servers (like checking 6,000 different hotels).

• The Shocking Stat: 46.4% of them were insecure. That's nearly half!
• The "Give an Inch" Effect: Most of these servers were built to be convenient. They let the user log in once, and then they just kept the "door open" for everyone.
• Who is at risk? It wasn't just small, unknown projects. Even popular tools with thousands of "stars" (likes) on GitHub had this problem.
• The Worst Offenders: Tools that help developers (like code editors) were the most dangerous because they often have access to your entire computer.

Real-World Nightmares (The Attacks)

The researchers showed how this "sticky note" flaw could be used for real attacks:

1. The Remote Control Hijack:

   • Scenario: An AI tool lets you control your computer's mouse and keyboard.
   • Attack: Because the server didn't check who was holding the remote, an attacker could remotely move your mouse, click buttons, and even fill out forms as if you were doing it. They could bypass security questions that require you to click a button.

2. The "Ghost" Command:

   • Scenario: An AI tool lets you run code on your computer.
   • Attack: An attacker sends a command to delete your files or steal your passwords. The server runs it because it thinks the command is coming from the "authorized" user, even though it's coming from a stranger.

3. The Stolen Key:

   • Scenario: An AI tool connects to your Slack or AWS (cloud) account.
   • Attack: The attacker uses the AI server to send messages to your boss or delete your company's data. The server uses your valid login credentials, so the company's systems think it's a legitimate action.

Why Does This Happen?

It's not because the AI is "evil" or the code is broken in a complex way. It's a design choice.

• The "Lazy" Approach: Developers wanted the AI to be fast and smooth. They thought, "If the user logged in once, let's just keep them logged in so the AI doesn't have to ask for a password every second."
• The Mistake: They forgot that in the AI world, the "user" isn't always the one holding the remote. Sometimes, a script, a different app, or a hacker is holding it.

The Solution

The paper argues that we need to stop treating the AI server as a "trusted friend" and start treating it like a "strict bouncer."

• Check ID Every Time: Every single time the AI wants to open a door (run a tool), it must verify who is asking for it right now.
• Don't Rely on Sticky Notes: Don't assume that just because you were allowed in 5 minutes ago, you are allowed in 5 minutes from now.

The Takeaway

The title "Give Them an Inch and They Will Take a Mile" is a perfect summary.

• The Inch: We gave the AI server a little bit of trust (one-time login).
• The Mile: The server took that trust and let anyone walk in and take control of our computers, files, and accounts.

The researchers are calling for a new standard where AI systems must constantly check "Who is holding the remote?" before doing anything important.

Technical Summary

Here is a detailed technical summary of the paper "Give Them an Inch and They Will Take a Mile: Understanding and Measuring Caller Identity Confusion in MCP-Based AI Systems."

1. Problem Statement: Caller Identity Confusion

The paper identifies a fundamental security vulnerability in systems utilizing the Model Context Protocol (MCP), an open standard allowing Large Language Model (LLM) agents to interact with external tools and services.

• The Core Issue: In MCP architectures, an LLM agent (client) sends tool invocation requests to an independent MCP server process. The server holds the necessary credentials to access backend resources (databases, file systems, APIs).
• The Flaw: Many MCP servers treat the server process itself as the trusted entity. Once a user authorizes the server (e.g., via OAuth), the server caches this authorization state. Crucially, the server often fails to distinguish between different callers (agents) or re-verify the identity of the caller for subsequent requests.
• The Consequence: This leads to Caller Identity Confusion. If a legitimate user authorizes the server, an attacker controlling a different agent (or a malicious script) can invoke tools on that same server. The server, seeing valid cached credentials, executes the attacker's commands under the legitimate user's authorization context.
• Impact: This allows attackers to perform remote command execution, hijack GUIs, and abuse privileged APIs without stealing credentials or bypassing authentication mechanisms directly. The attack relies entirely on the server's failure to bind authorization to the specific invoking caller.

2. Methodology: MCPAuthChecker

To detect and measure this vulnerability, the authors designed MCPAuthChecker, a static and dynamic analysis framework. The tool faces three main challenges: non-standardized entry points, decentralized authorization logic, and stateful execution.

Key Technical Components:

1. Execution-Triggered Tool Entry Resolution:

   • Unlike traditional apps with fixed main functions, MCP tools are registered dynamically.
   • The tool uses CodeQL to reconstruct program dependencies and identify the specific code locations where a protocol-level tools/call request transitions into concrete execution logic, regardless of the registration pattern (decorators, API calls, or runtime enumeration).

2. Path-Sensitive Authorization Analysis:

   • The tool traces execution paths from the identified entry points to sensitive resource operations (e.g., file I/O, system commands, network requests).
   • It evaluates whether authorization is:
     • Missing: No checks performed.
     • Cached: Checks performed once at startup, with results reused globally.
     • Caller-Bound: Checks performed per-invocation, explicitly verifying the current caller's identity.
   • It distinguishes between global server state and per-invocation constraints.

3. Selective Dynamic Validation:

   • Since static analysis cannot always determine if cached state is being reused across different callers, the tool performs controlled dynamic execution.
   • It acts as a proxy to issue tool calls to the MCP server. If a tool executes a sensitive operation (e.g., reading a file) without triggering a new authorization prompt or failure, it confirms the presence of caller identity confusion.

3. Key Contributions

• Formalization of Caller Identity Confusion: The paper defines a new vulnerability class specific to middleware-based AI execution where authorization is decoupled from the caller identity.
• MCPAuthChecker Framework: A novel analysis tool combining static dependency reconstruction, path-sensitive control flow analysis, and dynamic validation to detect these issues at the granularity of individual tool invocations.
• Large-Scale Empirical Study: The first comprehensive measurement of the MCP ecosystem, analyzing 6,137 real-world MCP servers.
• Real-World Attack Demonstrations: The authors demonstrated three concrete attack vectors:
  1. Agent-Originated RCE: Executing arbitrary shell commands via Git tools.
  2. Unauthenticated GUI Control: Remotely hijacking browsers and mouse/keyboard inputs.
  3. Persistent API Abuse: Using cached tokens to access third-party services (Slack, AWS) without re-authentication.

4. Results

The study analyzed 6,137 MCP servers across various categories (Developer Tools, Data Science, API Integration, etc.) and popularity levels (GitHub stars).

• Vulnerability Rate: 46.4% (2,846 servers) exhibited insecure authorization behavior.
• Vulnerability Types:
  • AuthNone: No authorization checks (25.1% of vulnerable servers).
  • AuthCache: Authorization performed once and cached/reused (38.3% of vulnerable servers).
  • AuthRuntime: Checks exist but rely on shared state not bound to the caller (36.6% of vulnerable servers).
• Distribution:
  • Vulnerabilities are systemic, not limited to immature projects. Even highly starred projects (>1,000 stars) showed high vulnerability rates (40.9% insecure).
  • Developer Tools were the most affected category, containing the highest absolute number of insecure tools.
  • Author Concentration: A small subset of developers was responsible for a disproportionately large number of vulnerable servers, suggesting a pattern of flawed design practices rather than isolated errors.
• Impact Correlation: Vulnerable servers in "Developer Tools" and "API & Integration" categories were found to expose the most dangerous capabilities, including system-level execution and persistent data access.

5. Significance and Implications

• Paradigm Shift in AI Security: The paper highlights that traditional security models (which assume a trusted client or per-request authentication) are insufficient for LLM agents. The "stateful" nature of MCP servers creates a unique attack surface where authorization is "sticky" and easily misused.
• Design Principle Recommendation: The authors argue that explicit caller authentication and fine-grained, invocation-level authorization must become first-class design principles for AI execution frameworks. Relying on server-level trust is fundamentally insecure.
• Responsible Disclosure: The authors responsibly reported findings to 87 high-profile open-source projects. Several projects acknowledged the issues, with some already assigning CVEs or patching the vulnerabilities, validating the practical severity of the findings.
• Broader Context: This work serves as a warning for the rapidly growing ecosystem of AI agents. As agents gain the ability to execute code and interact with critical infrastructure, the lack of caller identity binding could lead to widespread, stealthy system compromises that are difficult to detect via traditional logging (since the requests appear to come from a valid, authorized server).

In summary, the paper demonstrates that the convenience of "one-time authorization" in MCP systems has created a massive, exploitable security gap where "giving an inch" (server-level trust) allows attackers to "take a mile" (unrestricted execution authority).