Serveurs MCP
Il tourne sur votre machine avec vos droits, comme n'importe quel paquet. Contrairement à un paquet, ses descriptions d'outils atterrissent dans le contexte du modèle, où elles se lisent comme des instructions. La sécurité d'un serveur MCP doit couvrir les deux moitiés.
Aucun n'est exotique. Ils découlent du fonctionnement du protocole et de l'endroit où les gens rangent leurs identifiants.
tool poisoning
Le nom, la description et le schéma de paramètres d'un outil arrivent au modèle sous forme de texte. Un serveur peut écrire une description qui dit au modèle de lire un fichier et d'en passer le contenu en argument, et le modèle n'a aucun moyen de distinguer cela d'une instruction légitime.
remise d'identifiants
Les serveurs MCP locaux tournent sur stdio comme processus enfants. Ils reçoivent l'environnement que vous leur donnez, ce qui veut généralement dire un jeton à longue durée dans une variable. À partir de là, l'identifiant vous échappe.
dérive de schéma
Les descriptions et les schémas d'outils peuvent changer à la prochaine mise à jour. Le serveur que vous avez examiné en mars n'est pas forcément celui qui tourne en juin, et rien dans le protocole ne rend ce changement bruyant.
portée du jeton
Les serveurs distants détiennent des jetons d'accès en votre nom. Un serveur qui accepte ou relaie un jeton émis pour une autre ressource devient un intermédiaire commode pour atteindre des choses que vous n'avez jamais autorisées.
aucune trace
La plupart des installations ne gardent aucune trace de quel outil MCP a tourné, avec quels arguments, contre quel hôte. L'ennui remonte au calendrier de quelqu'un d'autre, en général dans une facture ou une notification de fuite.
Le fil conducteur : c'est le modèle qui lit les descriptions d'outils, et l'identifiant se trouve quelque part où le serveur peut le lire. Réglez la seconde moitié et la première cesse de pouvoir rapporter quoi que ce soit.
Les serveurs MCP locaux et distants s'authentifient de manières complètement différentes, et cet écart compte davantage que ne le laissent croire la plupart des guides d'installation.
Il n'y a aucune étape d'authentification. Le serveur est un processus enfant que vous avez lancé, et il est aussi digne de confiance que l'environnement avec lequel vous l'avez démarré. Le jeton que vous avez exporté est désormais aussi celui du serveur.
confiance = votre environnement
Le profil d'autorisation MCP s'appuie sur OAuth 2.1 : le client découvre le serveur d'autorisation, vous consentez dans un navigateur, et le client détient un jeton d'accès à courte durée avec un jeton de rafraîchissement derrière.
confiance = la portée du jeton
Rien ici n'exige un produit. C'est l'examen que vous feriez de n'importe quelle dépendance, plus les deux questions propres à MCP.
Installez une version précise plutôt que ce vers quoi latest pointe aujourd'hui. Un serveur qui se met à jour tout seul peut changer ses descriptions d'outils après que vous les avez approuvées.
Le README est écrit pour vous. Les descriptions sont écrites pour le modèle. Lisez celles que le modèle recevra réellement.
Un serveur stdio est un processus enfant avec vos droits. Donnez-lui l'identifiant le plus étroit qui fasse encore le travail, jamais un jeton root qui traînait à côté.
Un jeton révocable et à courte durée vaut mieux qu'un personal access token dans une variable d'environnement, même si la configuration prend cinq minutes de plus.
Une ressource, un destinataire. Un serveur qui réclame un jeton à large portée, ou qui en accepte un émis pour autre chose, vous annonce déjà comment il va se comporter.
Regrouper cinq services derrière un seul serveur MCP concentre tous les identifiants dans un même processus. Séparez-les et le pire cas rétrécit.
Si vous ne pouvez pas dire ce qu'un serveur a fait mardi dernier, vous lui faites confiance au lieu de le vérifier. Les journaux sont ce qui transforme un incident en incident borné.
Traitez un changement de schéma d'outil comme une montée de dépendance : regardez le diff. C'est la vérification que presque personne ne fait, et c'est exactement pour cela qu'elle marche comme attaque.
Sallyport se place devant les serveurs MCP auxquels votre agent parle. Leurs appels gravissent la même échelle que tout le reste et atterrissent dans le même journal.
01
Claude Code, Cursor ou n'importe quel client MCP se connecte à Sallyport. Sallyport lui présente http.request, ssh.exec et les serveurs en amont que vous avez configurés.
02
Les serveurs stdio locaux et les serveurs OAuth 2.1 distants transitent tous les deux. Sallyport scelle leurs jetons dans le coffre et les rafraîchit dans l'application.
03
Un coffre verrouillé refuse l'appel. Une clé marquée pour approbation à chaque appel fait apparaître une carte. Sinon, l'approbation de session déjà donnée couvre l'exécution.
04
Chiffré et chaîné par hachage au moment où cela se produit, pour que la réponse à "qu'a fait ce serveur mardi dernier" existe avant que vous en ayez besoin.
Une limite honnête : un serveur MCP local en stdio que vous configurez reçoit bien l'identifiant que vous lui associez. Le transit vous donne une approbation et une trace pour ses appels ; il ne reprend pas la clé à un processus que vous avez choisi de lancer.
Téléchargement gratuit. Apple Silicon, macOS 14 ou plus récent. Aucun compte, jamais.
brew install --cask olegsotnikov/tap/sallyportmacOS 14+ · Apple Silicon