Logistics Route Optimization: Guide in 2026
April 29, 2025
- BLOG
MCP Security: Understanding Authentication, Permissions, and Tool Access
Published: November 2, 2026
Table of Contents
An MCP server can read your repositories, query your database, look up a customer’s address, and in some setups send messages or move money. That reach is the whole point of the protocol. It is also the reason security teams ask hard questions before they approve it. A model that can call real tools can also be steered into calling the wrong ones, and a server you install can do anything your own account can do.
MCP security comes down to three questions. Who is making this request, and how do you know? What is that caller allowed to do? And which tools can an agent use, with what inputs, and what happens to the results it reads? This guide calls those layers authentication, permissions, and tool access. It follows what the MCP specification and the project’s security best practices actually say, and it uses NextBillion.ai MCP as a worked example of a server with a small, clear attack surface.
If you are still deciding what to build, start with our guide to MCP use cases. If you are ready to evaluate risk, read on. We cover how OAuth works for remote servers, how to limit permissions, how to handle prompt injection, and how to vet a server before you connect it.
Why MCP Security Differs From Normal API Security
In a traditional integration, your code decides which API calls to make. In an MCP setup, a model decides, and it decides based on text. That text can include the user’s request, the tool descriptions a server provides, and the results that earlier tool calls returned. If an attacker can get words in front of the model, they may not need to break into anything.
That changes where the risk sits. OWASP ranks prompt injection first in its Top 10 for LLM Applications for 2025. MCP also adds supply-chain questions that ordinary APIs rarely raise, because people install third-party servers and some of them run on a developer’s own machine. For a refresher on how requests move between the model, client, and server, see how AI agents use MCP.
The MCP Security Model at a Glance
Each layer answers a different question, and each has its own controls. The table below maps them, so you can see where a given risk belongs.
Layer | Question it answers | Main controls |
Authentication | Who is calling? | OAuth 2.1 for remote servers, environment credentials for local servers |
Permissions | What may they do? | Minimal scopes, read-only access, per-user authorization |
Tool access | Which tools run, and with what inputs? | Human approval, trusted servers only, inspected inputs |
Data handling | What comes back, and who reads it? | Treat tool output as data, sanitize results, log calls |
No single layer is enough. A perfectly authenticated user can still be tricked by hostile text in a tool result, and a locked-down tool list does nothing if the server itself is malicious.
Authentication: Proving Who Is Calling
Authentication works differently for remote and local servers. Remote servers use a standard OAuth flow defined in the authorization specification. Local servers usually rely on credentials stored in the environment. Knowing which one you are dealing with tells you which risks to plan for
.
How OAuth Works for Remote MCP Servers
The authorization specification covers HTTP-based transports. In that model, a protected MCP server acts as an OAuth 2.1 resource server, and the client acts as an OAuth 2.1 client. Servers must implement OAuth 2.0 Protected Resource Metadata, and clients must use it to find the right authorization server.
The flow runs in a set order. The client sends an unauthenticated request and gets a 401 response that points to the server’s metadata. It reads that metadata, finds the authorization server, obtains a client ID, and sends the user to sign in through a browser. Clients must use PKCE, and they must check the authorization server’s metadata to confirm it supports PKCE before going further. They must also send a resource parameter, defined in RFC 8707, so the token is issued for one specific server.
Local Servers and API Keys
A local server that runs over stdio does not use that browser flow. It typically reads a credential from its environment. NextBillion.ai MCP works this way: you export an API key as NBAI_API_KEY, and the server uses it to call NextBillion’s location APIs. The repository also describes a shared HTTP client that handles authentication, timeouts, retries, and key redaction, so the key does not show up in logs.
Treat that key like a password. Keep it in a secret manager or an environment variable, never in a config file you commit, and never in browser code. Stdio helps too. The security guidance advises local servers to use stdio so that only the MCP client can reach them.
Token Mistakes to Avoid
The official guidance names three mistakes that matter most. The first is token passthrough. An MCP server must not accept any token that was not explicitly issued for that server. If it does, and then forwards the token downstream, clients can bypass rate limits and other controls, and your audit trail stops showing who did what.
The second is the confused deputy problem. It affects proxy servers that use one static client ID with a third-party API while also allowing clients to register dynamically. If the third-party server has already set a consent cookie, an attacker can skip the consent screen. Such proxy servers must collect consent from each client separately.
The third is state handle hijacking. MCP is now stateless, so servers that need to remember something between requests hand out handles, like a cart ID. Possession of a handle must never count as proof of identity. Use random, hard-to-guess handles and tie each one to the authenticated user.
Client Identity and Redirect Risks
Servers also need a way to know which client is asking. The specification says authorization servers and clients should support OAuth Client ID Metadata Documents, where a client identifies itself with a URL that hosts its details. That proves the client controls a domain. It does not prove which program on a user’s computer is listening for the sign-in response. A local app that uses a localhost redirect address can be impersonated by another process on the same machine. For that reason, authorization servers should show extra warnings for localhost redirects and display the redirect address clearly, so the user can spot something wrong.
Read more: Build Location-Reasoning AI Applications with NextBillion.ai MCP
Permissions: Limiting What a Connection Can Do
Authentication tells you who is calling. Permissions decide what that caller can touch. This is where most real-world damage gets limited, because a stolen or misused credential is only as dangerous as the access behind it.
Least Privilege and Scope Minimization
The project’s guidance is direct: start with the smallest set of scopes that covers basic, low-risk operations. When a user later tries something more sensitive, the server challenges for the extra scope at that moment, and the client requests it then.
The same guidance lists common mistakes. Publishing every scope in scopes_supported invites clients to ask for all of them. Wildcard scopes such as * or full-access make a stolen token far more powerful. Servers should also log each scope elevation so you can see when and why access grew.
Here is how that works in practice. A server starts by granting a basic scope that covers lookups and reads. Later, a user asks the agent to change something. The server replies with a challenge naming the extra scope it needs, the client asks the user to approve it, and only then does the token grow. Each step is visible, and each one can be logged.
Read-Only First
Where you can, separate reading from writing and begin with reading. The GitHub MCP server can run with read-only toolsets. A database connection can use read-only credentials and a row limit. The location tools in NextBillion.ai MCP, such as geocode_forward, distance_matrix, and directions, are lookups against NextBillion’s APIs. For a server like that, the main exposure is the API key and the usage it can run up, so you can limit damage by restricting the key and watching usage.
Per-User Access on Shared Servers
When many people share one remote server, each person should sign in as themselves. The server then checks permissions on every request, using the identity from the verified token and not anything the client claims. This keeps one user’s agent from reading another user’s data.
Tool Access: Controlling What an Agent Can Do
Even with good authentication and tight permissions, you still need to control which tools an agent calls and what it does with the output. The tools specification puts a person at the center of that control.
Human Approval for Sensitive Actions
The tools specification says there should always be a human in the loop who can deny tool invocations. Clients should show tool inputs before sending them to the server, which helps catch accidental or malicious data exfiltration. In practice, require approval for anything that sends, pays, deletes, or changes records. Don’t ask for approval on harmless lookups. If people click “allow” hundreds of times a day, they stop reading the prompts.
Treat Tool Descriptions and Annotations as Untrusted
A tool’s description is text the model reads, so a bad description can steer the model. The specification says clients must treat tool annotations as untrusted unless they come from a trusted server. Servers can also notify clients when their tool list changes, which means a server you approved last week can offer different tools today. Pin server versions where you can, and review tool changes before you accept them.
Validate Inputs and Limit Usage
Tools take inputs from a model, and a model can be wrong or manipulated. The tools specification lists several safeguards for servers and clients. Servers should validate every tool input, enforce access controls, rate limit tool calls, and sanitize outputs. Clients should show inputs to the user before a call, set timeouts, and keep a log of tool usage for audits. Rate limits matter for cost as well as safety, since a looping agent can send thousands of requests to a paid API in minutes.
Prompt Injection Through Tool Results
Prompt injection is the risk most teams underestimate. A model reads instructions and data as one stream of text, so a web page, support ticket, email, or error log can carry commands that the model may follow. The MCP guidance asks servers to sanitize tool outputs, and the safest rule for builders is to treat everything a tool returns as data.
Design helps more than filtering. Avoid giving a single agent private data, untrusted content, and a way to send information out all at once. If an agent must read outside content, remove its ability to take sensitive actions in the same session, or put a human approval step in front of them. Our guide to MCP clients explains where those approval prompts live.
Read more: NextBillion.ai Launches MCP Server for AI Agents and LLMs
Vetting MCP Servers and Running Them Safely
Everything above assumes the server itself is honest. That is not guaranteed, so the last layer is deciding which servers to trust and where to run them.
Local Servers Run With Your Privileges
A local server is a program that runs on your machine, and it runs with the same privileges as the client. The specification describes real attack paths: a malicious startup command hidden in a configuration, a malicious payload inside the server, or an insecure server left running that another process can reach.
For one-click setups, clients must show the exact command without cutting it off and require explicit approval before running it. They should also warn about risky patterns and run servers in a sandbox with limited file and network access. If you install servers yourself, read the command before you run it.
Checking Third-Party Servers Before You Connect
Before you add a server, ask a few plain questions. Who maintains it, and is the source open for review? Which tools does it expose, and do you need all of them? What credentials will it hold? NextBillion.ai MCP is a useful example of what a reviewable server looks like. Its code is public under the Apache-2.0 license, it exposes a short list of 15 location tools, and it runs on your own machine.
Test any new server in a sandbox first, with a low-privilege credential, and check what it does before you give it real access.
What a Basic Security Review Looks Like
You don’t need a large program to review an MCP project. Start by listing every server in use and every tool each one exposes. Next, note which credential each server holds and what that credential can reach. Then sort the tools into read tools and write tools, and decide which writes need approval. Finally, test the weak spot directly. Put harmless but suspicious instructions into a ticket or document the agent will read, and see whether it acts on them. Repeat the review whenever you add a server or a server’s tool list changes.
Network Risks for Clients and Servers
Clients that run on a server can be tricked into fetching internal addresses, a risk known as server-side request forgery. During OAuth discovery, a malicious server can point the client to a private IP address or a cloud metadata endpoint. The guidance recommends requiring HTTPS, blocking private and link-local address ranges, and sending these requests through an egress proxy. It also advises against writing your own IP validation, because attackers use encoding tricks that custom code often misses. The OWASP SSRF Prevention Cheat Sheet covers these defenses in more detail.
Putting It Together: Securing a Location MCP Server
NextBillion.ai MCP makes a good worked example because its surface is small. It runs locally over stdio, so only your client can reach it. It authenticates with one API key that you export as NBAI_API_KEY. It exposes 15 tools for geocoding, place search, routing, distance matrices, isochrones, and static maps, and each one is a lookup. Even so, you can tighten the setup in a few steps.
Keep the key in a secret manager or your shell profile, not in a shared configuration file. Restrict the key to what the project needs and monitor its usage. The quick-start command pulls the package with npx -y nextbillion-mcp, so consider pinning a specific version, which means an update can’t change the tools without your review. Finally, if a dispatcher or driver-facing agent also reads outside content, such as customer notes, treat that text as untrusted and keep any action that assigns work or notifies customers behind an approval step.
MCP Security Checklist
Use this list before you move an MCP project from a test to production:
- Confirm whether the server is local or remote, and choose the matching authentication method.
- For remote servers, check that OAuth uses PKCE and the resource parameter.
- Reject any design that forwards tokens the server did not issue.
- Store API keys in a secret manager or environment variable, never in code or in browser code.
- Start with read-only access and the smallest scopes that work.
- Require human approval for tools that send, pay, delete, or change records.
- Treat tool descriptions, annotations, and results as untrusted data.
- Pin server versions and review tool list changes.
- Run local servers in a sandbox and read every startup command.
- Log every tool call so you can trace what an agent did and why.
Conclusion: Start Narrow and Widen Slowly
MCP security is not one setting. It is a set of habits across three layers: prove who is calling, limit what they can do, and control what the agent is allowed to run and read. None of this is exotic. It is least privilege, careful review, and human approval applied to a new kind of integration.
A sensible path is to connect one server, give it the most limited access that works, test it with real questions, and widen the scope only when you have a reason. If your use case involves addresses, routes, or travel times, NextBillion.ai MCP is a practical place to practice. NextBillion.ai builds location and logistics APIs, including Route Optimization, Distance Matrix, and Directions, and its MCP server exposes them as tools your agent can call. Get an API key, export it as NBAI_API_KEY, and add the server to a client like Claude Code, Cursor, or Codex. Then apply the checklist above before you share it with your team.
Read more: Route Optimization with AI Agents (Beyond Static APIs)
Frequently Asked Questions
No. The protocol gives you an authorization framework and detailed security guidance, but it can’t secure your deployment for you. Your choices about credentials, scopes, approval steps, and which servers to trust decide how safe the setup is.
The authorization specification covers HTTP-based transports, and it uses OAuth 2.1. Local servers that run over stdio usually take credentials from the environment instead. NextBillion.ai MCP, for example, reads an API key from NBAI_API_KEY.
It is an attack where hostile instructions hide in content the agent reads, such as a web page, ticket, or tool result. The model may treat those instructions as legitimate. Treat tool output as data, limit what the agent can do in the same session, and keep a person in the loop for sensitive actions.
They can be, but they run with your privileges, so treat them like any program you install. Read the startup command, prefer open-source servers you can review, and run them in a sandbox with limited file and network access
Toggle Content
Not every one. The specification says a person should be able to deny tool invocations, and clients should show inputs before calls run. In practice, require approval for actions that send, pay, delete, or change data, and let harmless lookups run on their own to avoid approval fatigue.
