MCP servers
It runs on your machine with your rights, like any package. Unlike a package, its tool descriptions land inside the model's context, where they read as instructions. MCP server security has to account for both halves of that.
None of these is exotic. They follow from how the protocol works and from where people put their credentials.
tool poisoning
A tool's name, description, and parameter schema go to the model as text. A server can write a description that tells the model to read a file and pass its contents as an argument, and the model has no way to tell that apart from a legitimate instruction.
credential handoff
Local MCP servers run over stdio as child processes. They receive the environment you give them, which usually means a long-lived token in a variable. From there the credential is out of your hands.
schema drift
Tool descriptions and schemas can change on the next update. The server you reviewed in March is not necessarily the server running in June, and nothing in the protocol makes that change loud.
token scope
Remote servers hold access tokens on your behalf. A server that accepts or forwards a token issued for a different resource turns into a convenient deputy for reaching things you never authorized.
no record
Most setups have no record of which MCP tool ran, with what arguments, against which host. Trouble surfaces on someone else's schedule, usually in a bill or a breach notice.
The common thread: the model is the one reading the tool descriptions, and the credential is sitting somewhere the server can read it. Fix the second half and the first half stops being able to pay off.
Local and remote MCP servers authenticate in completely different ways, and the difference matters more than most setup guides suggest.
There is no authentication step. The server is a child process you launched, and it is as trusted as the environment you started it with. Whatever token you exported is now the server's token too.
trust = your environment
The MCP authorization profile builds on OAuth 2.1: the client discovers the authorization server, you consent in a browser, and the client holds a short-lived access token with a refresh token behind it.
trust = the token's scope
Nothing here needs a product. It is the review you would give any dependency, plus the two questions that are specific to MCP.
Install a specific version rather than whatever latest resolves to today. A server that updates itself can change its tool descriptions after you approved them.
The README is written for you. The descriptions are written for the model. Read the ones the model will actually receive.
A stdio server is a child process with your rights. Hand it the narrowest credential that still does the job, never a root token that happens to be nearby.
A revocable, short-lived token beats a personal access token in an environment variable, even when the setup takes five more minutes.
One resource, one audience. A server that wants a broadly scoped token, or accepts one issued for something else, is telling you how it will behave.
Aggregating five services behind a single MCP server concentrates every credential in one process. Split them and the worst case gets smaller.
If you cannot say what a server did last Tuesday, you are trusting it rather than verifying it. Logs are what turn an incident into a bounded incident.
Treat a tool-schema change like a dependency bump: look at the diff. This is the check almost nobody does, which is exactly why it works as an attack.
Sallyport sits in front of the MCP servers your agent talks to. Their calls climb the same ladder as everything else and land in the same journal.
01
Claude Code, Cursor, or any MCP client connects to Sallyport. Sallyport presents http.request, ssh.exec, and the upstream servers you configured.
02
Local stdio servers and remote OAuth 2.1 servers are both proxied. Sallyport seals their tokens in the vault and refreshes them inside the app.
03
A locked vault denies the call. A key flagged for approval per call raises a card. Otherwise the session approval you already gave covers the run.
04
Encrypted and hash-chained as it happens, so an answer to "what did that server do last Tuesday" exists before you need it.
One honest limit: a local stdio MCP server you configure does receive the credential you bind to it. Proxying gives you approval and a record for its calls; it does not take the key back out of a process you chose to start.
Free download. Apple Silicon, macOS 14 or newer. No account, ever.
brew install --cask olegsotnikov/tap/sallyportmacOS 14+ · Apple Silicon