Créer une application interne n’a jamais été aussi peu coûteux. Le résultat, on le voit chez tous nos clients : une app admin, une app commerciale, une app ressources, une app marketing, une dataroom… chacune derrière le SSO de l’entreprise, avec des droits calqués sur l’organigramme. Construire ces applications, c’est devenu la partie facile.
La partie difficile arrive juste après : tout le monde veut y brancher son agent. Chaque collaborateur a désormais un Claude, un assistant, un copilote — et veut lui confier les clés de ses outils métier. C’est là que les ennuis commencent.
Les deux mauvaises réponses
La première tentation : un connecteur MCP par application. Chaque app expose son serveur, chaque employé configure N connecteurs. Les permissions restent justes… mais on multiplie les consentements, les magasins de tokens, les surfaces d’audit — et plus rien n’est révocable d’un geste quand quelqu’un quitte l’entreprise.
La seconde, plus dangereuse : l’agrégateur sur compte de service. Un seul connecteur, oui — mais derrière, un compte technique qui cumule les droits de tout le monde. Chaque agent hérite de l’union des permissions de toute l’entreprise, et le contrôle d’accès doit être réinventé (et maintenu, et oublié) dans une couche intermédiaire. C’est l’anti-pattern classique du « confused deputy ».
La réponse que nous publions
Cortex Gateway est un gateway MCP fédéré, open source (MIT), que nous publions et utilisons : un seul serveur MCP conforme à la spec (Streamable HTTP, OAuth 2.1) devant N applications. Les applications restent des services web ordinaires — chacune implémente un unique endpoint HTTP d’environ 120 lignes, sans bibliothèque MCP. Le gateway découvre leurs outils, les fusionne en un catalogue filtré par les scopes OAuth de l’appelant, et route chaque appel avec l’identité réelle de l’utilisateur.
Le principe tient en une phrase : le gateway ne décide rien. Il ne copie pas les permissions, il ne les synchronise pas, il ne les aplatit pas — il transporte l’identité, et chaque application continue d’appliquer ses propres règles à la vraie personne, exactement comme dans son interface web.
- Un connecteur pour toute l’entreprise — un consentement, une révocation centrale, un audit unique (pseudonymisé).
- Les scopes deviennent l’organigramme — le commercial voit les outils CRM, la finance voit la facturation, la direction voit tout en lecture. Zéro logique de rôle dans le gateway.
- Zéro lock-in — retirez le gateway, vos applications restent appelables en HTTP. C’est le même principe que notre doctrine zero lock-in, appliqué à l’infrastructure agentique.
Copilote aujourd’hui, agents autonomes demain
Le mode copilote — un humain qui instruit son agent — est le cas facile. La vraie question arrive vite : quand chaque collaborateur aura un agent réellement autonome comme assistant, « que peut-il faire et qui en répond » cesse d’être un détail d’ergonomie pour devenir une question de gouvernance.
Notre conviction : la bonne réponse restera ennuyeuse. L’agent emprunte l’identité de la personne, les applications continuent d’appliquer les droits de la personne, et chaque appel atterrit dans la piste d’audit. Passer des copilotes aux assistants autonomes n’ajoute alors rien de nouveau à sécuriser — c’est précisément pour cela que cette architecture nous semble être le bon socle.
Essayer, auditer, adopter
Le projet est conçu pour être vérifié plutôt que cru sur parole : une démo publique connectable depuis claude.ai en trente secondes, des claims sondables au curl, un AGENTS.md pensé pour que votre propre agent puisse auditer le dépôt. Donnez simplement l’URL à votre Claude — c’est l’exercice que nous recommandons.
→ Le site : cortex-gateway.dev
→ Le code (MIT) : github.com/wellknownmcp/cortex-gateway
Et si votre entreprise ressemble à la description du début — des apps métier derrière un SSO et des équipes qui veulent y mettre leurs agents — parlons-en : c’est exactement le type d’infrastructure que nous déployons.