MCP en entreprise : connecter des agents à Confluence, Jira et Microsoft 365 en toute sécurité

Qu’est-ce que le Model Context Protocol ?

MCP est un protocole standard entre un agent IA et les outils qu’il utilise. Un serveur expose des capacités, comme chercher dans un wiki ou lire un ticket, et un client intégré à l’agent les découvre et les appelle. Plutôt qu’une intégration sur mesure par couple agent et outil, on s’appuie sur un seul protocole.

Pourquoi connecter des agents aux outils de l’entreprise est-il un sujet de sécurité ?

Une question d’intégration demande si l’agent peut atteindre Confluence. Une question de sécurité demande ce qu’il a le droit de lire une fois arrivé, pour le compte de qui, et ce que devient le texte qu’il rapporte. Avec un agent, l’appel d’outil est fait par un modèle, souvent en boucle, à partir d’un texte qui peut lui-même provenir d’une page récupérée.

Quatre préoccupations en découlent, et je les considère comme le vrai périmètre de tout projet MCP :

• Les droits d’accès : l’agent doit voir ce que la personne qui demande a le droit de voir, pas ce que le jeton partagé peut voir.
• L’injection de prompt par le contenu récupéré : une page de wiki ou un ticket sont des données, mais un modèle peut y lire des instructions.
• La classification des données : un contenu confidentiel ou secret ne doit pas circuler là où il ne doit pas aller, modèles externes compris.
• L’audit : il faut pouvoir reconstituer ce qui a été servi, à qui et pourquoi.

Quels sont les principaux risques et les contrôles correspondants ?

La plupart des défaillances que j’anticipe ne sont pas des défaillances du protocole. Elles viennent d’un compte de service aux droits larges, jamais limité à la personne qui demande. Le tableau associe chaque risque au contrôle que je cherche.

Comment ORBIT se connecte-t-il à Confluence, Jira et Microsoft 365 ?

ORBIT, la plateforme de contexte que j’ai construite, propose deux voies vers les outils externes. Les connecteurs natifs couvrent SharePoint et OneDrive, Confluence et Jira. Les connecteurs MCP couvrent Confluence et Jira, Microsoft 365, Google Workspace, Slack, GitHub, Linear, Obsidian et Figma, avec un assistant de démarrage en cinq étapes. Un worker les synchronise toutes les 60 minutes par défaut.

Les deux voies alimentent le même pipeline d’ingestion. Chaque page ou ticket passe par la détection des données personnelles, la classification et le découpage avant d’être servi. Le choix qui m’importe : l’agent ne parle jamais directement à Confluence, il parle à ORBIT, qui détient une copie synchronisée et classifiée.

Limite à énoncer : la connexion OAuth interactive pour Microsoft 365, Google et Linear via MCP est sur la feuille de route, pas livrée.

Comment ORBIT préserve-t-il droits d’accès et classification ?

La règle tient en une ligne dans le README : un contenu n’est servi que si sa classification est inférieure ou égale au plus bas de l’habilitation de l’utilisateur, de l’habilitation de l’agent et du plafond fixé sur la requête. Un agent agit pour le compte d’un membre du projet ; sans cela, il n’accède qu’à ce qui est ouvert à tout le projet.

NOVA, mon agent produit personnel, récupère le contexte ORBIT en tant que l’utilisateur : la même règle s’applique. Voici les mécanismes :

• Une échelle de classification de C0 (public) à C3 (secret), alignée sur la politique de l’organisation.
• Des listes d’accès sur les documents, fragments et éléments de mémoire. La mémoire dérivée hérite de la liste la plus restrictive et de la classification la plus haute de ses sources.
• Les exclusions pour accès ou classification sont journalisées mais caviardées pour qui n’y a pas accès (ni titre, ni extrait, ni identifiant) ; les agents ne reçoivent que des compteurs.
• Une détection des données personnelles à l’ingestion, et le contexte servi utilise toujours le texte caviardé.
• Des événements de révocation, comme document.acl_changed, member.removed et agent.revoked, dans le fil des changements et dans les webhooks signés.

Comment ORBIT traite-t-il l’injection de prompt dans le contenu récupéré ?

L’injection de prompt est le risque que MCP rend le plus visible : l’agent lit désormais des textes écrits par des inconnus. Je ne crois pas qu’un filtre unique suffise : ORBIT empile plusieurs défenses :

• À l’ingestion, chaque fragment reçoit un score. Au-dessus d’un seuil (0,6 par défaut), il est mis en quarantaine jusqu’à libération par un propriétaire.
• Au moment de servir, tout ce qui est remis aux agents est balisé comme donnée non fiable.
• Les sources de faible confiance subissent une pénalité de classement (0,15 par défaut) et remontent donc moins souvent.
• Une alerte d’empoisonnement se déclenche quand une source récente ou un agent propose un nombre inhabituel d’éléments (8 en 24 heures par défaut).

Qu’expose le serveur MCP d’ORBIT, et comment les serveurs tiers sont-ils contenus ?

ORBIT est aussi un serveur MCP, en streamable HTTP. Chaque agent détient une clé d’API rattachée à un projet, et seule son empreinte SHA-256 est stockée. Le serveur expose 12 outils, dont get_context, search_sources et propose_memory. Ce dernier crée une proposition qu’un humain doit valider : l’agent n’écrit donc pas directement dans la mémoire de confiance.

Pour les serveurs MCP tiers, ORBIT inverse la confiance habituelle. Seuls les serveurs des préréglages peuvent être lancés, depuis une liste autorisée, avec des arguments construits côté serveur. Ils s’exécutent dans un environnement isolé ne contenant que les identifiants du connecteur, avec délais et plafonds. Les secrets sont chiffrés et jamais réaffichés, et les images du backend embarquent des versions figées de Node.js et des serveurs MCP : aucun code n’est téléchargé à l’exécution. Un préréglage personnalisé existe, mais il est désactivé par défaut et réservé aux administrateurs.

ORBIT est-il prêt pour la production, et par où commencer ?

Non. ORBIT est une bêta publique, non validée pour un usage en production. Son README indique que le durcissement complet pour la production, avec authentification unique, authentification multifacteur, audit chaîné et sauvegardes, est encore en cours. Je n’ai aucun résultat mesuré à citer : ce qui précède décrit ce que le projet fournit, pas ses résultats. Son jeu de démonstration contient des contenus volontairement fictifs C2 (confidentiel) et C3 (secret), et le README met en garde : n’y mélangez jamais de vraies données.

Quel que soit l’outil retenu, voici l’ordre que je suivrais :

• Inventorier chaque serveur MCP et connecteur, avec un responsable nommé.
• Remplacer les comptes de service partagés par un accès pour le compte de la personne.
• Classifier le contenu avant l’agent et plafonner ce que les modèles externes reçoivent.
• Traiter tout texte récupéré comme une donnée non fiable, jamais comme des instructions.
• Autoriser les serveurs par liste et garder les serveurs personnalisés désactivés.
• Journaliser ce qui a été servi et pourquoi, et tester d’abord avec des données fictives.