The Model Context Protocol, MCP, lets an AI application connect to tools and data through a common interface. A developer adds a server to their editor, and the agent can suddenly read tickets, query a database or open a pull request.
That convenience has a price that is easy to miss. To the agent, an MCP server is a list of tools. Behind that list, the server holds the credentials it needs to act, and whoever can use the server can use them.
In this piece, we will cover:
- What an MCP server is, and where its credentials live
- Three ways MCP servers go wrong in a company
- The questions to ask about every server
- What a useful inventory shows you
What an MCP server actually is
An MCP server exposes a set of tools to an AI application. It runs either on the developer's machine, started by the application, or as a remote service the application connects to. Either way, it needs access to the thing it wraps.
| What the server exposes | What sits behind it |
|---|---|
| Tokens | Personal and service tokens for code, chat and ticket systems. |
| OAuth grants | Access a person approved once and the server keeps using. |
| API keys | Keys for cloud, database and AI providers, often in the server environment. |
So the server is not just a convenience layer. It is the place where credentials meet an agent that decides what to do.
Three ways MCP servers go wrong
1. Nobody owns them
A server set up by one developer for one task keeps running. It has no ticket, no review and no named owner. When that person changes teams, the server and its credentials stay.
2. The credentials are broader than the task
Developers connect a server with whatever token works. A read-only question about one repository ends up behind a token that can write to all of them. The agent only needed a small part of that access, and has all of it.
3. They do not show up where you look
A list of accounts in your identity provider will not show an MCP server, because the server itself is not an account. Its identity is the token it holds. Standard identity reviews miss it for that reason.
The questions to ask about every server
| Question | Why it matters |
|---|---|
| Who owns this server? | Without an owner, nobody notices when access changes or is no longer needed. |
| Which credentials does it hold? | Reach is decided by the credentials, not by the tool names. |
| Which agents can use it? | Every agent that connects inherits everything the server can do. |
| What can those credentials reach? | The route from server to sensitive data is the actual exposure. |
| Did any of this change since the last scan? | New servers and wider grants appear without a change request. |
What a useful inventory shows you
nerl0 builds an inventory of every agent and MCP server it finds in your connected platforms. For each one it shows the privilege it holds, the data it can reach and the risk, next to the person who answers for it. Servers with no owner are flagged, so the first conversation is short: claim it, narrow it or remove it.
nerl0 reads the platforms you connect. A server that runs only on a laptop and never touches a connected platform is outside what it can see. Every answer says what it cannot show, so you know where the picture ends.
Summary
An MCP server is a doorway with credentials behind it. The risk is rarely the protocol. It is the combination of no owner, credentials wider than the task, and a place that standard identity reviews do not look. Ask the five questions about every server, and start with the ones nobody owns.
Sascha writes about what AI agents and non-human identities can reach, and builds nerl0 to keep that visible.