Sécurité et bonnes pratiques

Ce que vous ouvrez en connectant un serveur

Brancher Grok sur des serveurs MCP distants revient à confier à un modèle la capacité d’agir sur vos systèmes. Cette puissance a un revers, et les leçons précédentes ont introduit les paramètres qui le maîtrisent. Il s’agit maintenant de les organiser en une posture cohérente pour un déploiement en production.

HTTPS et authentification : le socle non négociable

La règle tient en une phrase : tout serveur MCP de production doit être en HTTPS et exiger une authentification. xAI impose déjà le premier point et rejettera toute URL en clair. Le second, en revanche, dépend entièrement de vous, et c’est là que se logent les erreurs.

Un serveur sans authentification est accessible à quiconque en connaît l’URL. Cela signifie que n’importe qui peut appeler vos outils internes, que vos données circulent sans contrôle d’accès, et que vous n’avez aucun moyen de savoir qui a fait quoi lorsqu’une anomalie apparaît. L’URL n’est pas un secret : elle transite, elle se retrouve dans des logs, elle est devinable quand elle suit une convention.

# Production : TOUJOURS avec authentification
mcp(
    server_url="https://api.monentreprise.com/mcp",
    server_label="interne",
    authorization=f"Bearer {os.getenv('MCP_TOKEN')}"
)

# Développement UNIQUEMENT : sans authentification
# À ne JAMAIS déployer en production
mcp(
    server_url="https://mcp.deepwiki.com/mcp",
    server_label="deepwiki"
)

La gestion des tokens obéit ensuite à quatre disciplines simples, mais qui doivent être tenues dans la durée. Stockez-les en variables d’environnement et jamais dans le code source, sans quoi le premier git push public envoie votre jeton au monde entier. Renouvelez-les périodiquement, tous les 90 jours au minimum : une rotation planifiée transforme une fuite éventuelle en fenêtre d’exposition bornée. Générez-les avec les permissions minimales nécessaires, de sorte qu’un token volé pour un agent de lecture ne serve à rien à qui voudrait écrire. Et si l’un d’eux est compromis, révoquez-le immédiatement avant d’en générer un nouveau — l’ordre compte, car un token révoqué après coup a continué de fonctionner pendant tout le temps où vous cherchiez son remplaçant.

La liste blanche comme seconde ligne de défense

Un token valide prouve l’identité de l’appelant, il ne dit rien de ce que l’appelant devrait pouvoir faire. C’est le rôle de allowed_tool_names, qui applique le principe du moindre privilège en n’exposant au modèle que le strict nécessaire.

La forme concrète de cette restriction dépend du profil de l’agent. Un chatbot public s’en tient à la lecture, sans le moindre outil d’écriture à portée.

allowed_tool_names=["search_docs", "get_article", "list_categories"]
# Pas d'accès à : create_article, update_article, delete_article

Un agent interne peut se permettre davantage, y compris commenter un ticket, tout en gardant hors de portée les actions irréversibles ou visibles par des tiers.

allowed_tool_names=[
    "search_tickets", "get_ticket", "add_comment",
    # Pas d'accès à : close_ticket, delete_ticket, reassign_ticket
]

Une pipeline automatisée, enfin, n’a besoin que des deux outils que son traitement enchaîne, et rien ne justifie qu’elle puisse reconfigurer quoi que ce soit.

allowed_tool_names=["run_analysis", "get_results"]
# Pas d'accès à : configure_pipeline, delete_results

Le scénario contre lequel ces listes vous protègent est le prompt injection. Un document analysé, un ticket, un email entrant peut contenir une instruction destinée au modèle. Sans restriction, cette instruction peut le conduire à supprimer des données via un outil delete_*, à modifier un paramétrage via update_config, ou à émettre des communications non souhaitées via send_email. Un outil qui n’a jamais été exposé ne peut pas être détourné : c’est la seule garantie réellement solide.

Le contexte est une ressource finie

Chaque outil exposé consomme des tokens dans la fenêtre de contexte, puisque son nom, sa description et son schéma de paramètres doivent y être présents. Un serveur qui publie trente outils peut ainsi engloutir plusieurs milliers de tokens avant même la première question de l’utilisateur.

Les conséquences se manifestent sur trois plans : moins de place pour la conversation elle-même, un temps de traitement allongé par le volume à analyser, et un risque de confusion accru quand plusieurs outils se ressemblent. Trois pratiques y répondent. Restreignez d’abord avec allowed_tool_names, qui reste le levier le plus direct. Segmentez ensuite par cas d’usage plutôt que de maintenir une configuration unique : un agent de support client, un agent interne et une pipeline n’ont aucune raison de partager le même catalogue. Réévaluez enfin périodiquement, en regardant dans vos traces quels outils sont réellement appelés — il est fréquent d’en découvrir plusieurs qui n’ont jamais servi et qui coûtent du contexte à chaque requête.

Des descriptions qui font gagner en précision

Des descriptions soignées, au niveau du serveur comme des outils, réduisent mesurablement les appels erronés. Le contraste ci-dessous illustre ce qui sépare une description exploitable d’une description inutile.

# Bon : spécifique et actionnable
server_description="Base de connaissances produit. Recherche d'articles d'aide, FAQ et guides de dépannage pour les produits A, B et C."

# Mauvais : vague et générique
server_description="Base de données"

Le prompt système constitue le dernier étage de ce dispositif. Il vous permet d’exprimer des règles d’usage qu’aucune configuration ne peut porter, comme un ordre de priorité entre sources ou une exigence de confirmation.

Quand l'utilisateur pose une question technique, cherchez d'abord dans la base de connaissances interne (kb).
Si la réponse n'est pas trouvée, utilisez la recherche web en complément.
Ne modifiez jamais de ticket sans confirmation explicite de l'utilisateur.

Retenez toutefois que ces consignes orientent le comportement du modèle sans le contraindre : elles complètent la liste blanche, elles ne la remplacent jamais.

Points clés à retenir

• HTTPS est imposé par xAI, mais l’authentification est de votre responsabilité
• Stockez les tokens en variables d’environnement et renouvelez-les régulièrement
• Utilisez allowed_tool_names pour appliquer le principe du moindre privilège
• Surveillez la charge de contexte : chaque outil consomme des tokens
• Écrivez des descriptions précises pour améliorer la sélection d’outils par Grok