Minimiser les données des agents IA pour des appels d'outils plus sûrs

Un agent IA ne devrait pas recevoir un dossier client simplement parce qu'il pourrait avoir besoin, plus tard, d'une seule information. Chaque appel d'outil a besoin d'un contrat plus limité : l'action, les champs minimum nécessaires pour l'exécuter et une sortie qui indique à l'agent ce qui s'est passé sans lui remettre une nouvelle masse de données client.

Les équipes divulguent généralement des données à la jonction entre un agent capable et une API interne pratique. Elles donnent à l'agent accès à une recherche client générale, renvoient toute la réponse et appellent cela un contexte utile. Ce choix transforme chaque prompt ultérieur, transcription, nouvelle tentative, trace de débogage et résultat d'outil en point de propagation du dossier.

La solution n'est pas un prompt de masquage astucieux. C'est une discipline de conception : cartographier chaque action avant de l'exposer, imposer une requête limitée à la frontière d'exécution et empêcher l'agent d'accéder aux réponses brutes des services amont.

L'autorisation d'un outil ne donne pas accès à tout le dossier

L'autorisation d'appeler une API et l'autorisation de voir tous les champs qu'elle peut renvoyer sont deux décisions différentes. Les équipes les confondent parce qu'un compte de service peut souvent lire un objet large, alors qu'un outil d'agent n'en nécessite qu'une petite partie.

Prenons un agent qui doit décider s'il faut envoyer un rappel de paiement. Le service d'envoi peut avoir besoin d'une adresse de destinataire, d'un identifiant de modèle et d'une référence de facture. L'agent lui-même peut n'avoir besoin que de eligible: true, d'un nom sûr à afficher et d'une référence d'action. Il n'a pas besoin de l'historique des paiements, des notes client, des informations fiscales ni de l'adresse utilisée en coulisses par l'expéditeur.

Un outil général get_customer crée une source de problèmes séduisante. Une fois qu'il existe, les prompts commencent à l'utiliser pour des tâches sans rapport, parce que cela semble moins coûteux que de créer un outil d'action adapté. Les équipes compensent alors avec des instructions comme « ne pas exposer les champs sensibles ». Les instructions ne suppriment pas les champs d'une réponse JSON.

Gardez ces trois questions séparées :

• Ce processus d'agent peut-il lancer cette action ?
• Quels champs l'exécuteur doit-il recevoir pour l'effectuer ?
• Quels faits l'agent doit-il recevoir une fois l'action terminée ?

Chaque question doit produire sa propre contrainte. Le contrôle d'accès répond à la première. La validation de la requête répond à la deuxième. La mise en forme de la réponse répond à la troisième. Un jeton API polyvalent et un point de terminaison JSON flexible ne répondent correctement à aucune de ces questions.

Cette distinction compte particulièrement lorsqu'un agent utilise plusieurs fois un outil. Une recherche large effectuée une seule fois peut sembler acceptable dans une démonstration. Dans une exécution réelle, l'agent peut la relancer après une nouvelle tentative, citer sa sortie dans une requête ultérieure ou la transmettre à un autre outil. Le premier champ inutile devient alors de nombreuses copies inutiles.

Construire la cartographie des données autour d'une action, pas d'une table

Une cartographie utile des données commence par un verbe et un effet externe. « Lire le client » n'est pas une action adaptée à cet objectif. « Confirmer qu'une facture est en retard » et « créer une étiquette d'expédition » sont des actions, car chacune a un destinataire, un objectif et un résultat attendu précis.

Pour chaque outil proposé, rédigez une petite fiche avant d'écrire le schéma :

La colonne consacrée à la recherche de confiance fait le travail difficile. Elle repère les informations dont l'exécuteur peut avoir besoin mais dont l'agent n'a pas besoin. Déplacez cette recherche derrière la frontière. L'agent envoie une référence de facture, puis un service que vous contrôlez résout le destinataire après avoir vérifié l'action.

Ne faites pas de invoice_ref une copie déguisée d'une adresse e-mail ou un identifiant composé contenant le nom du client. Les références opaques réduisent les divulgations accidentelles, mais ne rendent pas automatiquement un système privé. Si une référence permet à n'importe qui d'interroger un dossier client, elle a toujours besoin d'une autorisation, d'une expiration et d'une restriction d'audience.

Le Règlement général sur la protection des données de l'Union européenne énonce clairement le principe pertinent à l'article 5(1)(c) : les données personnelles doivent être adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité. C'est la notion de « finalité » qui conduit souvent les équipes d'ingénierie à relâcher leur vigilance. La finalité n'est pas « aider l'agent à accomplir son travail ». Il s'agit de l'opération précise réalisée à la frontière, comme envoyer un rappel ou ouvrir un dossier de support.

Une cartographie révèle aussi les champs qui ne devraient jamais franchir la frontière, dans un sens comme dans l'autre. Les notes en texte libre méritent leur propre ligne. Elles contiennent régulièrement des e-mails copiés, des pièces d'identité, des identifiants, des informations de santé et la plainte non filtrée d'un client. Un champ générique notes n'a pas de signification délimitée et n'a donc pas sa place dans une requête d'outil courante.

Les schémas stricts bloquent les champs ajoutés par commodité avant l'exécution

Un schéma doit rejeter les champs dont l'action n'a pas besoin. Ignorer silencieusement les propriétés supplémentaires peut sembler plus souple, mais cela dissimule une fuite pendant les tests et laisse les développeurs croire que le champ a été transmis.

Supposons qu'un agent doive demander l'examen d'un remboursement. Ce contrat de requête n'autorise qu'une référence de dossier et un motif choisi. Il rejette les montants contrôlés par le client, les adresses et les notes arbitraires.

{
  "name": "request_refund_review",
  "description": "Create a review task for an existing support case.",
  "input_schema": {
    "type": "object",
    "additionalProperties": false,
    "required": ["case_ref", "reason_code"],
    "properties": {
      "case_ref": {
        "type": "string",
        "pattern": "^case_[A-Za-z0-9]{16}$"
      },
      "reason_code": {
        "type": "string",
        "enum": ["duplicate_charge", "service_not_received", "other"]
      }
    }
  }
}

Une requête contenant customer_email, shipping_address, amount ou conversation_text doit échouer lors de la validation et renvoyer explicitement un résultat tel que :

{
  "error": "invalid_request",
  "message": "Unexpected property: customer_email"
}

Cette erreur indique à l'agent qu'il doit respecter le contrat et au développeur qu'un champ indésirable a atteint la frontière. Ne répétez pas la valeur rejetée dans l'erreur. Les gestionnaires d'erreurs ont causé davantage de fuites que de nombreux parcours de production, car ils sérialisent toute la requête échouée à des fins de débogage.

La validation du schéma ne protège pas à elle seule les champs gérés par le serveur. Une requête peut contenir un case_ref d'apparence valide qui appartient à un autre compte, ou un reason_code valide associé à une référence d'action émise pour un autre agent. L'exécuteur doit associer la référence à son émetteur, à l'action prévue et à sa durée de vie. Considérez une référence d'action comme un ticket de retrait, pas comme une clé primaire publique de base de données.

Utilisez un générateur de requêtes lorsqu'un agent commence avec un contexte non fiable ou trop large. Le générateur doit extraire les champs autorisés et créer un nouvel objet. Ne prenez pas un objet volumineux pour supprimer ensuite quelques clés connues comme dangereuses. Le masquage fondé sur une liste de refus échoue dès qu'un nouveau champ apparaît, qu'un objet imbriqué change de forme ou qu'un développeur appelle l'outil avec un alias nommé autrement.

ALLOWED_REASONS = {"duplicate_charge", "service_not_received", "other"}

def build_refund_request(case_ref, reason_code):
    if not isinstance(case_ref, str) or not case_ref.startswith("case_"):
        raise ValueError("invalid case_ref")
    if reason_code not in ALLOWED_REASONS:
        raise ValueError("invalid reason_code")
    return {"case_ref": case_ref, "reason_code": reason_code}

Cette petite fonction évite une erreur fréquente : transmettre tout le dictionnaire case à une bibliothèque cliente parce que celle-ci accepte des arguments nommés arbitraires. L'objet renvoyé explicitement est banal. Aux frontières des données client, la banalité est une qualité.

La sortie d'un outil a besoin de son propre contrat

La sortie brute d'un outil fait partie du contexte de l'agent, même si l'outil ne reçoit jamais de données client en entrée. Considérez chaque réponse comme une information que l'agent peut citer, conserver, transformer ou envoyer à un autre système.

Après la création d'une expédition, la réponse d'un fournisseur peut contenir l'adresse complète du destinataire, son numéro de téléphone, les informations du compte transporteur, les données de l'étiquette, les détails de routage et des champs de diagnostic internes. L'agent n'a généralement besoin que d'une référence d'expédition et de savoir s'il peut dire au client que sa commande est en route.

Définissez séparément la réponse destinée à l'agent et le résultat destiné au service :

{
  "status": "created",
  "shipment_ref": "ship_Q7J4K2P8",
  "customer_message_allowed": true
}

Le service d'exécution peut conserver ou transmettre la réponse détaillée du transporteur là où le personnel opérationnel en a besoin. Il ne devrait pas la renvoyer simplement parce que cela facilite le débogage. Si un opérateur a besoin d'un reçu, fournissez-lui une interface protégée. N'utilisez pas la transcription de l'agent comme base de données de dépannage.

Les réponses d'erreur doivent être traitées de la même manière. Une API amont peut renvoyer l'adresse rejetée, un numéro de compte ou une partie citée de la requête. Transformez ces informations en code d'erreur limité pour l'agent, comme recipient_unavailable, reference_invalid ou provider_retryable. Placez les détails de diagnostic protégés dans un système destiné aux opérateurs.

La spécification du Model Context Protocol définit les outils comme des fonctions appelables avec des entrées et des résultats structurés. Cette structure offre aux développeurs un emplacement clair pour imposer les types de réponse. Un outil qui renvoie un long texte ou un JSON arbitraire abandonne cet avantage. Un schéma de réponse limité facilite aussi les tests du comportement de l'agent, car sa décision suivante ne peut dépendre que de champs connus.

Évitez un champ nommé details sauf si vous pouvez en décrire précisément la structure et les règles de sensibilité. Cette sortie de secours vague devient permanente. Quelqu'un y placera le résultat brut pendant un incident, puis oubliera de le retirer.

Masquage, pseudonymes et secret sont des contrôles différents

Remplacer un nom par un jeton ne signifie pas que les données peuvent circuler sans risque. Un jeton stable qui peut être rapproché d'une base de données client reste une donnée personnelle dans la plupart des modèles de menace réalistes. Une référence d'action à usage unique, limitée à un appelant et à une courte durée de vie, offre un scénario de défaillance beaucoup plus restreint.

Le masquage supprime des valeurs connues d'un objet. Il aide lorsqu'un système interne doit afficher un dossier à un opérateur, mais il est fragile comme frontière principale pour les agents. Les noms de champs changent. Le contenu se déplace dans des structures imbriquées. Le texte libre contient des informations qu'aucune liste fixe de masquage ne peut trouver de façon fiable.

La pseudonymisation remplace un identifiant direct par un autre identifiant. Elle réduit l'exposition lorsque le destinataire ne peut pas résoudre la correspondance. Elle échoue lorsque le même agent peut appeler un outil de recherche général avec cet identifiant, lorsque le jeton apparaît dans plusieurs outils sans lien ou lorsque sa valeur porte elle-même une signification. acme-health-urgent-001 n'est pas opaque simplement parce qu'il ne contient pas de signe @.

Le secret vient du maintien des données de résolution et des identifiants du côté de confiance de la frontière. L'agent envoie une instruction limitée et un service ne résout les informations protégées que pour cette action autorisée. C'est cette distinction qui évite l'erreur courante consistant à transmettre un objet client « nettoyé » à un agent en pensant que le travail est terminé.

Vous devez aussi distinguer minimisation des données et autorisation. Un agent correctement autorisé peut tout de même recevoir trop de données. À l'inverse, un appelant non autorisé peut recevoir très peu d'informations, mais celles-ci peuvent quand même causer un préjudice. Appliquez les deux contrôles et testez-les séparément.

Des identifiants trop larges rendent les schémas limités moins crédibles

Un schéma de requête parfait ne peut pas compenser le fait qu'un agent détient un identifiant lui permettant d'appeler directement l'API sous-jacente. Si l'agent peut lire le secret ou l'utiliser depuis son environnement d'exécution, il peut contourner l'outil conçu avec soin et demander au fournisseur une réponse plus riche.

Placez les identifiants là où l'action s'exécute, pas là où le modèle raisonne. Après avoir validé la requête limitée, l'exécuteur injecte l'en-tête d'autorisation ou l'identité SSH. L'agent voit le résultat, pas le secret, un espace réservé ni une copie dans une variable d'environnement.

OAuth 2.0, décrit dans la RFC 6749, utilise des portées pour limiter l'accès accordé à un client. La portée est utile, mais de nombreuses implémentations la traitent comme un passe-partout valable pour tout un service. Une portée customers.read peut encore autoriser une recherche de dossier complet. Associez la portée de l'identifiant à des points de terminaison propres à l'action et à un filtrage des réponses. Sinon, la portée ne fait que limiter la grande collection dans laquelle l'agent peut effectuer des recherches.

Séparez l'autorité selon l'effet produit. Un agent qui peut créer un brouillon ne devrait pas aussi pouvoir l'envoyer. Un agent qui peut demander l'examen d'un remboursement ne devrait pas pouvoir effectuer le remboursement. Cette séparation réduit la tentation d'ajouter un identifiant administratif généraliste pour faire fonctionner un seul parcours.

Pour les équipes macOS qui utilisent Sallyport, l'application conserve les identifiants API et SSH dans son coffre chiffré et exécute l'action HTTP ou SSH sans les divulguer à l'agent. Cette organisation n'est utile que si l'appel reste lui-même limité : un jeton protégé peut toujours autoriser une requête trop large.

Un parcours de support montre où les données se propagent

Une fuite courante commence par une demande raisonnable : permettre à un agent de support de préparer une réponse à une livraison échouée. La première implémentation expose get_order(order_id), qui renvoie la commande, le profil client, l'adresse de livraison, le statut du paiement, l'historique du support et les événements du transporteur. L'agent a besoin de l'événement du transporteur et de l'autorisation d'envoyer une seule mise à jour approuvée.

L'agent appelle la recherche et reçoit le dossier complet. Il transmet ensuite certains détails à un outil de rédaction de message. Le prompt de rédaction contient alors l'adresse et l'historique, même si ni l'un ni l'autre ne contribue au message. Un appel d'outil échoué envoie le prompt entier dans un journal d'erreurs. Un ingénieur copie cette erreur dans un ticket pour l'analyser. La réponse large d'origine est devenue quatre problèmes distincts de conservation.

Construisez le parcours autrement. Donnez à l'agent une action assess_delivery_update qui accepte order_ref. Le service d'exécution vérifie les droits de l'appelant, récupère la commande en interne, lit le statut du transporteur, applique la règle de contact et ne renvoie que ceci :

{
  "status": "contact_allowed",
  "event_code": "delivery_delayed",
  "approved_template": "delivery_delay_notice",
  "order_ref": "ord_9VJ3R6M1"
}

L'agent peut décider si la situation justifie le message approuvé. Une action distincte send_approved_delivery_update accepte order_ref et approved_template. Elle n'accepte ni adresse e-mail ni texte libre. Le service résout le destinataire et génère le modèle après avoir vérifié le consentement et l'état de la commande.

Cette conception semble plus restrictive parce qu'elle l'est. C'est précisément le but. L'agent ne peut pas réutiliser par hasard un profil client pour une autre tâche et un outil ultérieur ne peut pas recevoir ces données accidentellement.

Ne répondez pas à cela par un argument général selon lequel « l'outil a besoin de souplesse ». La souplesse doit rester dans le code applicatif de confiance, où vous pouvez la tester, la relire et auditer son traitement des données. Donner cette souplesse à un agent au moyen d'objets de requête et de réponse larges reporte le coût sur chaque prompt et chaque système en aval.

Les écrans d'approbation ne peuvent pas inspecter tous les champs cachés

L'approbation protège contre les actions non autorisées, mais elle ne peut pas contrôler correctement des charges utiles surdimensionnées. Une personne voit un résumé court, prend une décision sous contrainte de temps et approuve l'action. Si le service dissimule une adresse ou un historique inutile dans la requête, l'approbation n'a rien fait pour limiter la divulgation.

L'approbation crée aussi une mauvaise incitation lorsqu'elle remplace la conception de l'outil. Les développeurs continuent d'ajouter des champs parce que « l'utilisateur approuve chaque appel ». L'écran d'approbation finit par contenir trop de détails pour être lu, ou trop peu pour être évalué. Les utilisateurs approuvent des actions répétées qui semblent anodines sans remarquer qu'une requête contient un nouveau champ.

Affichez l'action et ses paramètres délimités dans l'interface d'approbation, mais imposez la liste autorisée avant l'affichage de cette interface. La personne chargée d'approuver doit choisir si elle autorise send approved delivery update for ord_9VJ3R6M1, et non inspecter manuellement un dossier client sérialisé.

Utilisez une approbation à chaque appel pour les effets qui méritent l'attention d'une personne à chaque exécution. Ne l'utilisez pas comme scanner de données personnelles. La personne qui voit l'approbation n'a ni le temps ni le contexte nécessaires pour déterminer si chaque champ imbriqué était utile.

Un bon test de revue est simple : retirez l'approbateur du scénario. Le contrat de l'outil empêcherait-il toujours les données inutiles de quitter le service de confiance ? Si la réponse est non, la frontière ne fait pas assez son travail.

Les journaux d'audit doivent prouver les actions sans devenir une autre base de données

Vous avez besoin de preuves lorsqu'un agent agit au nom d'un client. Vous n'avez pas besoin d'une archive permanente de charges utiles complètes, lisible par l'agent, pour obtenir ces preuves.

Enregistrez le nom de l'action, le processus ou la session à l'origine de l'appel, l'horodatage, le résultat, la décision d'autorisation et une référence de corrélation. Si vous avez besoin d'une preuve d'intégrité de la charge utile, enregistrez le condensat cryptographique d'une représentation canonique protégée plutôt que la représentation elle-même. Conservez les noms des champs acceptés, pas leurs valeurs sensibles.

Par exemple, un événement d'audit peut conserver cette structure :

{
  "action": "send_approved_delivery_update",
  "session_ref": "sess_4KH8N2",
  "order_ref_digest": "sha256:8e4c...",
  "accepted_fields": ["order_ref", "approved_template"],
  "outcome": "sent",
  "authorized_by": "per_call"
}

Un condensat n'efface pas comme par magie les risques liés à la vie privée. Si l'entrée vient d'un petit ensemble connu, un attaquant peut deviner les valeurs et comparer les hachages. Utilisez une référence interne protégée lorsque les opérateurs doivent récupérer les détails et limitez l'accès au système qui conserve le dossier d'origine. Ne considérez jamais un simple hachage d'adresse e-mail comme anonyme.

Conservez les diagnostics opérationnels séparément du résultat d'outil visible par l'agent. Le personnel de support peut avoir besoin d'un accès protégé au corps d'une erreur amont pendant une courte période. L'agent n'en a pas besoin. Cette séparation facilite aussi la suppression et la conservation, car les dossiers bruts ne s'accumulent pas dans chaque journal.

Sallyport projette les sessions d'agent et les appels individuels depuis un journal d'audit chiffré, chaîné par hachage et insensible à l'écriture ; sa commande sp audit verify peut vérifier la chaîne hors ligne sans clé du coffre. La vérification d'intégrité indique si un événement enregistré a été modifié. Votre schéma d'événement doit tout de même déterminer si ce registre contient trop de données client dès le départ.

Tester la frontière avec un partage volontairement excessif

Une revue de confidentialité qui ne teste que les appels valides du parcours nominal ne voit pas le comportement à l'origine de la plupart des divulgations accidentelles. Testez ce qui se passe lorsqu'un agent envoie un objet complet, lorsqu'un service amont renvoie un champ inattendu et lorsqu'une exception survient au milieu d'une requête.

Utilisez une fixture contenant de fausses valeurs sensibles reconnaissables, puis vérifiez qu'elles ne franchissent pas la frontière de l'agent. Elle doit inclure des champs imbriqués et du texte libre, car les exemples plats permettent au code de masquage de réussir trop facilement.

{
  "case_ref": "case_Ab92Kx71LmQ4Rt8P",
  "reason_code": "duplicate_charge",
  "customer": {
    "email": "[email protected]",
    "address": "17 Example Lane",
    "payment_note": "card ending 4242"
  },
  "conversation_text": "Customer says their medical appointment depends on delivery."
}

Le résultat attendu est un échec de validation qui ne mentionne que la propriété inattendue. Inspectez ensuite quatre endroits : la réponse visible par l'agent, les journaux de l'application, les enregistrements de suivi des erreurs et les événements d'audit. Les développeurs valident souvent la requête mais oublient que leur middleware d'exception a enregistré le corps original.

Ajoutez aussi des tests de contrat pour la sortie. Simulez une réponse amont qui contient un objet client complet et vérifiez que l'outil n'émet que ses champs documentés. Faites-le chaque fois que le client du fournisseur évolue. Une mise à jour de SDK peut ajouter des champs de réponse sans que personne ne touche au prompt de l'agent.

Enfin, exécutez un test de transcription. Donnez à l'agent une tâche normale, capturez toutes les entrées et sorties d'outils qu'il reçoit, puis recherchez les valeurs de la fixture. Ce test détecte l'interpolation accidentelle dans les prompts et les textes de débogage que les tests de schéma peuvent manquer.

Le premier élément à repenser est généralement l'outil de recherche général. Remplacez-le par une action qui produit un véritable effet externe ou renvoie une décision limitée. Si le nouveau contrat semble trop étroit pour être pratique, c'est souvent le signe que le système comptait sur l'agent pour transporter des données dont il n'avait jamais besoin.