Votre serveur MCP est sécurisé. Mais pas le grand livre qui se trouve derrière.

Dans un article récemment publié ici, sur Unite.AI, Gil Feig a présenté six bonnes pratiques pour créer un serveur MCP sécurisé. Elles sont judicieuses, et toute personne qui déploie un serveur MCP devrait les suivre. Son conseil d’attribuer à chaque intégration « son propre rôle précis, limité strictement aux autorisations nécessaires » est tout à fait pertinent. Il suppose également que le système à l’autre bout dispose de rôles précis. Cela révèle une hypothèse plus générale, rarement formulée : les systèmes situés derrière le serveur peuvent être sécurisés selon les mêmes normes.

Dans les logiciels d’entreprise, c’est souvent impossible. Je dirige l’équipe d’ingénierie qui développe une couche d’intégration connectée à 32 systèmes de comptabilité et de planification des ressources de l’entreprise (ERP), sur laquelle il est possible d’ajouter un serveur MCP. Nous voyons régulièrement des agents correctement authentifiés, dont les autorisations sont bien délimitées et dont les activités sont bien consignées de notre côté, écrire dans des systèmes qui n’ont aucun moyen de savoir qu’un agent est intervenu.

Cet article porte sur cette deuxième partie du problème : ce que proposent réellement les systèmes en amont, ce que vous pouvez contrôler depuis la couche d’intégration et où s’arrête ce contrôle.

Là où la spécification MCP passe le relais

La spécification d’autorisation MCP définit clairement ses propres limites. Le serveur MCP est un serveur de ressources OAuth pour ses clients. Lorsqu’il appelle une API en amont, il agit comme un client OAuth distinct et utilise un jeton distinct, émis par le système en amont. La transmission du jeton du client est explicitement interdite.

C’est la bonne approche. Cela signifie aussi que tout ce qui concerne l’appel au système en amont, notamment qui est autorisé à faire quoi et comment ces actions sont consignées, dépend entièrement de ce système. La spécification ne peut pas remédier à ce que le système en amont ne propose pas.

Il en va de même pour les recommandations de l’OWASP sur l’autonomie excessive des agents. Elles préconisent de limiter au strict nécessaire les autorisations détenues par les extensions d’un agent dans d’autres systèmes et d’exécuter les actions au nom de l’utilisateur pour lequel il agit. Ces deux recommandations sont judicieuses. Elles supposent toutes deux que l’autre système permet de définir des autorisations minimales et le contexte de l’utilisateur.

Ce que proposent réellement les systèmes en amont

Voici à quoi ressemblent, du point de vue d’un intégrateur, les 32 systèmes de comptabilité et ERP auxquels nous nous connectons.

Un tiers n’utilise pas OAuth

21 des 32 systèmes utilisent OAuth. Les 11 autres reposent sur des identifiants statiques : des clés d’API, un nom d’utilisateur et un mot de passe, ou une paire de jetons. Certaines de ces clés n’expirent jamais. L’un des systèmes largement utilisés indique dans sa documentation que ses jetons d’API ont une durée de validité illimitée tant que l’utilisateur existe.

Une longue durée de validité, peu de possibilités de révocation

OAuth est moins utile qu’on pourrait l’espérer. Un fournisseur émet des jetons d’actualisation dont la durée de validité est d’environ 20 ans. Ces identifiants sont conçus pour survivre à l’agent qui les utilise, au cadre logiciel sur lequel cet agent a été développé et, très probablement, à la personne qui a cliqué sur « Autoriser ». Dans un autre système, même les jetons d’accès n’expirent pas.

Et une fois qu’un identifiant est en circulation, la question est de savoir qui peut le désactiver. La norme prévue à cet effet, la révocation des jetons OAuth (RFC 7009), existe depuis 2013. Pourtant, dans environ quatre systèmes sur dix, l’intégrateur ne dispose d’aucun moyen technique pour révoquer les identifiants. Tous les systèmes reposant sur des clés d’API font partie de ce groupe. La seule possibilité restante consiste à demander au client de supprimer lui-même l’accès.

Des autorisations générales, aucune identité d’agent

La plupart des clés statiques héritent simplement de tous les droits de l’utilisateur qui les a créées ; seuls quelques systèmes permettent de limiter une clé à des points de terminaison précis. De nombreux systèmes OAuth proposent des portées, mais elles sont souvent générales, du type « comptabilité, lecture et écriture ». Et, parmi les 32 systèmes, nous n’en avons trouvé aucun qui permette d’enregistrer, par l’intermédiaire de l’API, à la fois l’agent et la personne au nom de laquelle il agit pour une même transaction. Les agents externes apparaissent soit sous l’identité de l’utilisateur qui les a connectés, soit sous celle d’un utilisateur système générique. Il est révélateur que, lorsqu’un fournisseur intègre des agents à son propre produit, comme Microsoft l’a fait dans Business Central, il leur attribue des comptes utilisateur dédiés. C’est la même approche que je recommande ci-dessous, mais réservée aux agents du fournisseur.

Ce que la couche d’intégration peut imposer

Rien de tout cela ne signifie qu’il faut renoncer. Entre l’agent et le système de comptabilité, vous contrôlez presque tout :

• des identifiants propres à chaque agent pour accéder à votre couche
• vos propres portées, par exemple un accès en lecture seule aux factures
• un journal d’audit de chaque appel de l’agent, indiquant la personne au nom de laquelle il a agi
• des clés d’idempotence, afin qu’un agent qui réessaie une opération ne comptabilise pas deux fois la même facture
• des limites de débit propres à chaque agent
• des étapes d’approbation avant toute écriture

Aucune de ces mesures ne dépend des fonctionnalités prises en charge par le système cible. Il est possible dès aujourd’hui de mettre en place une couche de contrôle des accès efficace au niveau de l’intégration ; si vous utilisez des agents à proximité de données financières, vous devriez en créer une.

Où s’arrête ce contrôle

Ce que vous ne pouvez pas faire, c’est étendre cette couche au-delà des limites du système. Trois problèmes se posent alors.

Attribution

Dans le système comptable, l’écriture de l’agent apparaît au nom de la personne qui a autorisé la connexion, ou au nom d’un utilisateur technique. Toute personne qui audite ce système voit une écriture effectuée par cet utilisateur. Elle ne peut pas savoir si elle a été faite par une personne ou par un agent. Pour le grand livre, un agent qui enregistre 400 factures à 3 h du matin est indiscernable d’un directeur financier particulièrement consciencieux. Pour reconstituer les faits, il faut consulter les journaux de l’intégrateur, ce qui relève d’une chaîne de confiance différente de celle du système faisant foi. Pour une enquête ou un audit, c’est une position fragile.

La plupart des organisations ne sont pas mieux préparées. Selon une enquête de la Cloud Security Alliance, seuls 28 % des répondants ont déclaré pouvoir retracer de manière fiable les actions des agents jusqu’à une personne ou à un système dans tous les environnements, et 44 % utilisent ou prévoient d’utiliser des clés API statiques pour leurs agents.

Privilèges minimaux

Vous pouvez imposer qu’un agent ne lise que les factures. Mais si le système cible ne prend pas en charge les portées, les identifiants utilisés par votre couche conservent un accès complet. Quiconque les obtient contourne entièrement votre couche, ainsi que toutes les règles que vous y avez définies.

Révocation

Vous pouvez désactiver instantanément votre propre agent. Cela ne sert à rien si les identifiants du système cible lui-même sont compromis. Et pour les quatre systèmes sur dix qui ne disposent pas d’un point de terminaison de révocation, le coupe-circuit consiste à envoyer un e-mail au client.

La solution pragmatique : un utilisateur dédié à l’agent

La mesure la plus utile que vous puissiez prendre aujourd’hui n’a rien de spectaculaire. Créez un utilisateur dédié à l’agent dans le système cible et connectez l’agent uniquement par l’intermédiaire de cet utilisateur.

Cette solution fonctionne sur tous les systèmes qui permettent de créer des utilisateurs et offre trois avantages que la couche d’intégration ne peut pas apporter :

• L’attribution dans le système faisant foi. Les écritures apparaissent au nom de « l’agent fournisseurs », et non de la directrice financière qui a cliqué sur « connecter » il y a six mois.
• Une possibilité de révocation, même sans API dédiée. Le client peut désactiver l’utilisateur dans l’interface, ce qui fonctionne même sur les systèmes dépourvus de point de terminaison de révocation.
• Des privilèges minimaux partiels. Lorsque le système dispose d’un modèle de rôles, l’utilisateur de l’agent peut souvent être limité aux modules dont il a réellement besoin.

Les coûts sont bien réels. Quelqu’un doit créer l’utilisateur manuellement lors de l’intégration, ce qui ajoute des contraintes au pire moment. Environ la moitié des systèmes facturent chaque utilisateur supplémentaire, de quelques euros par mois pour les outils destinés aux petites entreprises à plus d’une centaine d’euros pour un ERP complet. Plusieurs autres plafonnent le nombre d’utilisateurs selon la formule choisie ; un utilisateur de plus peut donc obliger toute l’entreprise à passer à une formule plus chère. Et un compte de service dont personne n’est responsable devient un risque en soi, qui alimente la prolifération des identités non humaines déjà évoquée par Unite.AI. Comme tout autre compte, il doit avoir un responsable et une date de révision.

Cette solution ne règle pas non plus le problème des portées dans les systèmes qui n’en proposent pas. Mais elle rétablit l’attribution et la révocation dans le système que les auditeurs consultent réellement.

La solution structurelle : l’identité déléguée

La solution adéquate existe déjà sur le papier. L’échange de jetons OAuth 2.0 (RFC 8693) distingue l’usurpation d’identité de la délégation. Avec la délégation, l’agent conserve sa propre identité et le jeton indique, au moyen de la revendication « act », qu’il agit pour le compte d’une personne.

Appliqué à la comptabilité, cela signifierait que :

• le grand livre enregistre que cet agent a effectué une écriture pour le compte de cette personne
• les portées sont accordées pour chaque délégation, et non pour chaque utilisateur
• une délégation peut être révoquée sans toucher au compte de la personne

À ma connaissance, aucun des 32 systèmes ne prend en charge une fonctionnalité de ce type. Pour l’instant, cela reste donc une orientation, pas une option. Il s’agit donc d’une demande à adresser aux fournisseurs de logiciels comptables et d’ERP plutôt que d’une tâche pour les intégrateurs : les agents écrivent déjà dans vos grands livres, et vos API devraient pouvoir l’indiquer.

Que faire avant qu’un agent n’intervienne dans un grand livre

Si vous connectez des agents à des systèmes comptables ou ERP, voici une courte liste de vérifications :

1. Cartographiez le modèle d’identifiants de chaque système cible. S’agit-il d’OAuth ou d’une clé statique ? Quelle est la durée de validité des identifiants ? Sont-ils assortis de portées et pouvez-vous les révoquer ?
2. Créez malgré tout votre propre couche de contrôle des accès. L’identité propre à chaque agent, les portées, l’idempotence et les approbations relèvent de votre responsabilité, quelles que soient les fonctionnalités du système cible.
3. Utilisez un utilisateur dédié à l’agent partout où le système le permet. Acceptez le travail supplémentaire à l’intégration et le coût de la licence comme le prix à payer pour assurer l’attribution.
4. Veillez à ce que votre propre piste d’audit soit infalsifiable. Pour de nombreux systèmes, ce sera le seul moyen de prouver qu’un agent est intervenu.
5. Consignez le risque résiduel. Lorsqu’un système n’offre ni gestion des périmètres ni mécanisme de révocation, dites-le à votre client et consignez-le dans votre propre registre des risques.

C’est à la frontière que tout se joue

Sécuriser votre serveur MCP est nécessaire, mais cela ne suffit pas. La sécurité d’un agent qui écrit dans un registre se joue à la frontière entre votre couche et le système de référence. Aujourd’hui, ce sont les systèmes, et non vous, qui définissent cette frontière.

La bonne nouvelle, c’est que la lacune est clairement définie. Les normes existent. Ce qui manque, c’est leur prise en charge par les systèmes qui tiennent les registres.