The Model Context Protocol connects agents to tools, and every tool call runs with some credential: an API key, an OAuth token or a service account. An MCP server is therefore a non-human identity, often with broader access than the agent that uses it.
MCP servers are easy to add and hard to track. A developer connects one to try a workflow, it gets a token with generous scopes, and the token stays. Research on public MCP servers has found long-lived static keys to be common, and the protocol leaves much of authorization to the implementation. Our MCP security checklist covers the protocol-level risks such as prompt injection and tool poisoning.
The question this page is about is different: if an agent or an attacker drives this MCP server, which data can it reach through the credentials behind its tools?
Five questions Elmoz answers for every MCP server your agents can call.
Including experimental servers without an owner.
The keys, tokens and roles behind its tools and their scopes.
An MCP server shared by several agents concentrates their access in one place.
The data stores and production systems reachable through the server's credentials.
Scope the token, split a shared server or remove access that no tool actually needs.
A real case: PocketOS. A Cursor agent found a Railway CLI token in an unrelated file. The token was made for domains, but it could call any Railway operation, including volumeDelete. One API call removed the production volume and the backups stored inside it. Elmoz shows a path like this before it is used.
Elmoz shows the impact of each change before you make it.
Short answers on MCP servers as identities and how to audit what they reach.
In practice yes. Each MCP server calls other systems with credentials such as API keys, OAuth tokens or service accounts, and those credentials define what it can reach.
Broad, long-lived credentials behind tools. If an agent is manipulated or the server is compromised, whoever controls it inherits everything those credentials can reach.
List every connected server, the credential behind each tool and its scopes, the agents that can call it and the data those credentials reach. Then scope or remove what no tool needs.
Every use case ends in the same place: a path from an identity to sensitive data.
Book a demo and we walk through the access paths in an environment like yours.