MCP server credentials and what can go wrong

The key decides, the description does not

Most of what can go wrong with an MCP server comes back to one fact: the server acts with whatever credential you hand it, and the model decides when to use it. A token that can delete lets the model delete. A token that can read every customer record lets the model read every customer record and repeat them into a conversation. Security for MCP is mostly the discipline of handing over less.

The server's README describes an intended use. The credential describes the actual limit. When the two differ, the credential wins every time, which is why the MCP server directory puts the credential each server asks for beside its name rather than in a detail page.

Three ways a broad key goes wrong

The first is a plain mistake. The model misreads a request, picks the wrong tool, or passes the wrong argument, and the call succeeds because the key allowed it. Nothing malicious happened. A narrower key would have turned the mistake into an error message.

The second is instructions arriving from data. A model that reads a web page, a ticket or an email through one server may meet text written to steer it, and then act on that text through another server. The protocol does not stop this on its own. What limits the harm is what the other servers' keys allow.

The third is the server itself. Code can do more than its tool list says, and an install command that pulls the newest release on every start will run whatever was published last. A key held by a process you have not read is a key you have shared with its author.

Each of these can happen to a careful person. All three need only a key that was broader than the task.

Least privilege, done concretely

Make a new key for each server rather than reusing one you already have. Give it read-only access unless the job needs writing. Limit it to one project, one folder, one database schema or one channel where the service allows that. Set an expiry. Name it after the server so you can find and revoke it later.

For a database, connect as a role that can read the tables the task needs and nothing else. For a file server, point it at a folder made for the purpose, not at your home directory. For a code host, a token limited to one repository is a better start than one that covers an organisation.

Where a service only offers all-or-nothing keys, that is a reason to pause. Some servers are worth running against a separate account made for the purpose, with only the data you are willing to expose copied into it.

Where the key lives

A secret pasted into a client's configuration file sits on disk in plain text, often in a folder that gets synced or backed up. Keep that file out of any repository. Where the client can read secrets from the environment or from a system keychain, prefer that.

Remote servers raise a separate question: you are handing the key to whoever operates the server, not just to code on your machine. That is a trust decision about an operator, and the README cannot settle it.

What the credential column shows, and what it misses

Each server's credential list in the directory is read from the configuration block in its own README: environment variables whose names end in words like TOKEN, KEY, SECRET or PASSWORD. Example values such as YOUR_TOKEN are removed, because a placeholder is not something anyone can act on. The list is the set of secrets the author tells you to supply.

It cannot show a credential requested some other way, such as a sign-in through a browser or a file of saved credentials. An empty column means the README names no such variable, not that the server needs nothing. Read it as the first question to ask, then confirm the answer in the code. The MCP server page on what a server is covers the basics for anyone starting here.

Revoking and rotating

Plan the removal before the install. Write down where each key was made, what it reaches and which server holds it, so that when you stop using a server you can revoke its key in one place instead of hunting for it. A key nobody remembers making is a key nobody will revoke.

Rotate keys on a schedule for servers you keep. If a server's repository changes owner, goes quiet for a long time, or starts pulling in code you have not read, treat that as a reason to revoke the key and look again before issuing a new one. Short expiries force that second look on a schedule.

When something does go wrong, the service's own audit log is usually the only record of what a key did. Check whether the service keeps one before you rely on it, and note how long it is kept. The log will show the key, not the model, so a key per server is what lets you tell which server made a call.

The same planning helps when a server is replaced rather than dropped. Issue the new server its own key, run both side by side on test data for a short while, then revoke the old key on the day you remove the old server, so no key outlives the program that used it.