Comment donner à un agent IA un accès sécurisé aux données commerciales

L'architecture : l'agent est un client, le système est l'autorité

Commencez par la structure, car la plupart des erreurs sont des erreurs de structure. Une personne demande quelque chose à son agent. L'agent décide quels outils appeler. Chaque appel passe par une couche de permission qui appartient au système d'entreprise, et non à l'agent, et n'atteint un module tel que la finance ou le CRM qu'ensuite. L'agent ne touche jamais à la base de données, ne détient jamais de crédentiel de base de données et ne voit jamais un outil que sa personne ne pourrait pas utiliser.

Le principe sous-jacent est une phrase : l'agent agit avec l'autorité de la personne qu'il représente, et jamais plus. Tout le reste de cet article est un moyen de rendre cette phrase vraie sous pression, lorsque le modèle est erroné, lorsqu'un document qu'il lit contient des instructions, ou lorsqu'un jeton fuit.

Le Top 10 de l'OWASP pour les applications LLM nomme l'échec que cette architecture prévient : l'agence excessive, qu'elle décompose en fonctionnalité excessive (outils au-delà de ce que le travail nécessite), permissions excessives (plus d'accès en aval que nécessaire) et autonomie excessive (pas de vérification indépendante avant une action à fort impact). Ses atténuations ressemblent à une spécification pour la couche de permission : exécuter dans le contexte de l'utilisateur, minimiser les outils et leurs permissions, appliquer l'autorisation dans le système en aval plutôt que de se fier au modèle, et exiger l'approbation d'une personne pour des actions à fort impact.

Cinq contrôles, et où chacun se trouve

Les contrôles ne sont pas nouveaux ; ce sont les contrôles que vous appliquez déjà à une personne ayant accès au système, appliqués à un client qui agit pour cette personne. Le tableau indique ce que chacun répond, où il est appliqué et à quoi ressemble un échec lorsqu'il est manquant. La colonne de localisation est la plus importante. Un contrôle appliqué dans l'invite est une suggestion.

Identité : se connecter en tant que personne, via OAuth, jamais avec une clé partagée

La spécification d'autorisation du Model Context Protocol est précise à ce sujet. Un serveur distant agit comme un serveur de ressources OAuth 2.1 ; le client obtient un jeton via un flux d'autorisation standard avec PKCE ; le client doit indiquer pour quel serveur le jeton est destiné en utilisant le paramètre de ressource ; et le serveur doit valider que chaque jeton a été émis spécifiquement pour lui, en rejetant tout autre. La spécification interdit explicitement le passage de jeton, où un serveur accepte un jeton qu'il n'a pas émis et le transmet en aval, car cela détruit à la fois la piste d'audit et la frontière de confiance.

En pratique, cela signifie "connexion unique, aucun jeton à coller". La personne ajoute l'adresse de l'espace de travail à son agent, est redirigée vers une page de connexion normale, approuve la connexion, et l'agent reçoit un jeton qui l'identifie et ne fonctionne que pour cet espace de travail. Les recommandations d'Anthropic pour les connecteurs personnalisés dans Claude sont de passer en revue les portées demandées par un serveur, de les limiter lorsque cela est possible, et de se connecter uniquement à des serveurs de confiance. Un fournisseur qui vous demande plutôt de coller une clé API à l'échelle de l'entreprise dans une configuration d'agent a sauté le premier contrôle et rendu les quatre autres beaucoup plus difficiles.

Portée : filtrer avant d'offrir, vérifier à nouveau lors de l'exécution

Un agent découvre ce qu'il peut faire en demandant au serveur sa liste d'outils. Le bon design répond à cette question par personne : la liste que reçoit l'agent d'un comptable est différente de celle que reçoit l'agent d'un directeur, et aucune des deux n'inclut d'outils pour des modules que leur rôle ne peut pas voir. C'est le conseil d'OWASP pour minimiser la fonctionnalité mis en pratique, et cela a un second avantage : un modèle qui n'a jamais été montré un outil ne peut pas être convaincu de l'appeler.

Filtrer la liste ne suffit pas à lui seul, car les rôles changent, les sessions persistent et les clients mettent en cache. La même vérification doit être effectuée à nouveau à chaque appel, en fonction des autorisations de la personne à ce moment-là. Ci-dessous se trouve une liste d'outils dans la forme définie par le protocole, pour un rôle qui peut lire les factures mais ne peut pas enregistrer les paiements. L'outil absent est le point.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "searchInvoices",
        "description": "Search invoices by number, reference, contact, amount, status, date range.",
        "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "outstanding_only": { "type": "boolean" } } },
        "annotations": { "readOnlyHint": true } },
      { "name": "getInvoice",
        "description": "Read one invoice in full: status, totals, dates, contact and lines.",
        "inputSchema": { "type": "object", "properties": { "invoice_id": { "type": "string" } }, "required": ["invoice_id"] },
        "annotations": { "readOnlyHint": true } }
    ]
  }
}

// recordPayment, sendInvoiceReminders and deleteInvoice exist in the system.
// They are not in this list because this person's role cannot use them.
// If the agent calls one anyway, the server answers with a permission error.

Une réponse de liste d'outils dans la forme définie par la spécification MCP, avec des noms d'outils du module de comptabilité Sois. La spécification indique également que les clients doivent considérer les annotations telles que readOnlyHint comme non fiables, à moins que le serveur ne soit de confiance, ce qui est une raison de plus pour que ce soit le serveur, et non l'annotation, qui applique la règle.

Injection de prompt : les données peuvent répondre

La menace spécifique aux agents est que les données qu'ils lisent peuvent contenir des instructions. Un e-mail d'un client se terminant par une ligne demandant à l'agent de transmettre la liste des fournisseurs à une adresse externe ; un document lui demandant de marquer chaque facture comme payée. Le modèle peut ou non se conformer, et aucune invite ne peut garantir qu'il ne le fera pas, c'est pourquoi l'injection d'invite est en tête de la liste OWASP et pourquoi Anthropic et OpenAI mettent en garde à ce sujet dans leurs conseils de connecteur.

The defence is the architecture, not the model. An agent that is only offered the tools its person can use cannot forward what its person cannot see. A call to mark invoices paid is checked by the system against the person's permissions, not against the model's belief that it was asked to. Consequential tools are marked so that the client asks a person first: ChatGPT currently requires manual confirmation in a conversation before write actions, and OpenAI's guidance is to keep approval on for tools that modify data; Claude asks for approval per tool and advises reserving "allow always" for trusted servers. And the log records the attempt, so an injection that was blocked is visible afterwards rather than silent.

Budget et journaux : rendre le travail de l'agent aussi vérifiable que celui d'une personne

Le budget est important pour deux raisons. La première est évidente : le coût. Un agent qui reçoit un résultat vague continuera à appeler des outils jusqu'à ce que quelque chose l'arrête, et l'OWASP considère la consommation illimitée comme un risque en soi. La seconde, plus subtile, est le rayon d'explosion : un plafond par intégration limite ce qu'un agent compromis ou confus peut faire avant qu'une personne ne s'en aperçoive. Lorsque l'agent de la personne effectue le raisonnement, le coût de l'IA lui incombe ; lorsque l'agent du système le fait, le plafond doit être fixé par intégration et visible par action.

Les journaux transforment tout cela d'une promesse en quelque chose que vous pouvez auditer. Chaque appel doit enregistrer pour qui l'agent a agi, quel outil, les entrées, le résultat et le temps, au même endroit où le système enregistre ce que les gens ont fait. Le test est de savoir si un responsable financier peut découvrir ce que l'agent a fait au compte d'un client le mois dernier aussi facilement qu'il le peut pour un collègue. La spécification MCP demande aux clients d'enregistrer l'utilisation des outils pour l'audit ; un système d'entreprise ne doit pas compter sur le client pour cela, car le client n'est pas le système d'enregistrement.

Une liste de contrôle que vous pouvez appliquer à n'importe quel système

Apportez-les à n'importe quel fournisseur, y compris nous. Chacun est un oui ou un non, et chacun a un test plutôt qu'une question à poser.

1. L'agent se connecte en tant que personne nommée via OAuth, sans clé d'entreprise à coller. Test : connectez-vous depuis un client MCP externe et regardez ce que la page de connexion demande.
2. La liste des outils varie selon le rôle. Test : connectez-vous en tant qu'utilisateur restreint et en tant qu'administrateur et comparez ce qui est proposé à l'agent.
3. La vérification est répétée lorsque l'outil s'exécute. Test : retirez une autorisation d'un utilisateur connecté en cours de session et essayez à nouveau l'action.
4. L'accès échoue de manière sécurisée. Test : appelez un outil que le rôle ne devrait pas avoir et confirmez que vous obtenez un refus, pas un résultat.
5. Les dépenses peuvent être plafonnées par intégration et vues par action. Test : définissez un petit plafond et regardez-le se lier.
6. Chaque action est enregistrée contre la personne, with inputs and result, where the system logs everything else. Test: read the log for a run you just did.
7. Les outils conséquents sont marqués pour confirmation donc le client demande à une personne. Test : demandez à l'agent d'envoyer de l'argent ou de supprimer un enregistrement et confirmez que vous êtes d'abord interrogé.

Sois est un système conçu pour passer cette liste, et la forme en haut de l'article est sa forme. Un espace de travail est un serveur MCP ; tout client MCP se connecte en ajoutant l'adresse de l'espace de travail et en se connectant une fois via OAuth ; les outils sont filtrés par rôle avant d'être proposés et vérifiés à nouveau lorsqu'ils s'exécutent ; l'accès échoue par défaut ; les dépenses peuvent être plafonnées par intégration ; chaque action est enregistrée ; et les réseaux construits sur la plateforme ont leur propre base de données, stockage, domaines et clés. Exécutez la liste de contrôle contre cela de toute façon. La valeur d'une liste de contrôle est qu'elle ne prend la parole de personne.

Questions que les gens posent

Cet article est révisé lorsque les produits qu'il décrit changent. Prochaine révision prévue : 4 décembre 2026.