Sécuriser un agent IA nécessite six contrôles : identité délimitée, permissions d’outils à moindre privilège, tokenisation des PII, détection d’injection de prompt, un kill switch et une piste d’audit. Chacun ferme un mode de défaillance distinct — l’identité pour savoir quel agent a fait quoi, les permissions pour qu’un agent compromis ne puisse pas appeler n’importe quoi, la tokenisation pour qu’une fuite ne ressemble pas à l’agent faisant simplement son travail, la détection d’injection pour qu’une entrée manipulée ne puisse pas détourner un appel d’outil, un kill switch pour pouvoir arrêter un agent sans attendre sa coopération, et une piste d’audit pour qu’il y ait des preuves quand quelque chose tourne mal. Voici ce que fait chacun, où il vit, et sur quel plan il est disponible.
Sécuriser un agent IA signifie fermer six modes de défaillance distincts à l’exécution — identité, accès aux outils, exposition des données, instructions manipulées, contrôle prioritaire de l’opérateur et preuve — avec des contrôles qui se situent en dehors du propre raisonnement de l’agent. Une instruction de system prompt disant à un agent ce qu’il ne doit pas faire n’est pas un contrôle ; c’est une demande dont le modèle peut être détourné. Chaque élément ci-dessous est appliqué à un niveau où l’agent n’a pas voix au chapitre.
Dans l’ordre où la plupart des équipes les mettent en place — l’identité et la couche de décision en premier, puisque tout le reste dépend de savoir quel agent on observe.
POST /v1/credentials/issue, vérifiable via /.well-known/jwks.json) est le socle gratuit — illimité sur tous les plans. Une identité plus complète — vérification de propriété, manifestes signés déclarant ce qu’un agent peut faire, et délégations délimitées depuis un compte humain — c’est VeriSwarm Passport, à partir du plan Pro. Plan : identifiants de base gratuits ; Passport à partir de Pro. Comment fonctionne la vérification d’identité des agents.POST /v1/suite/guard/tool-permissions) vous permettent de définir une liste d’autorisation par outil plutôt que de faire confiance au propre jugement de l’agent sur ce qu’il devrait appeler. Plan : Max (Guard).[VS:EMAIL:a1b2c3]) avant de franchir la limite d’un outil, pas après. VeriSwarm Guard exécute cela sur POST /v1/suite/guard/pii/tokenize, appuyé sur un moteur de détection NER basé sur Presidio, et Guard Proxy l’applique de façon transparente à chaque appel d’outil MCP sans modification du code de l’agent. Plan : Max (Guard). Les trois vecteurs que cela ferme.POST /v1/suite/guard/scan) vérifie le texte non fiable avant qu’il n’atteigne une étape capable d’agir dessus, en combinant détection de motifs structurels et un classificateur ML DeBERTa. Plan : Max (Guard). Comment fonctionne l’analyse.POST /v1/suite/guard/kill/{agent_id}) bloque toute vérification de décision et émission d’identifiant ultérieure pour cet agent, quoi que dise son propre prompt. Il se situe entièrement en dehors du raisonnement de l’agent — on ne demande pas à l’agent de s’arrêter, il est refusé au niveau de la politique la prochaine fois qu’il tente d’agir. Plan : Max (Guard). Comment fonctionne réellement le kill switch.Il est tentant de lire une liste de six éléments comme six choses à acheter. Ce n’est pas ainsi que se répartissent les plans. La couche de décision qui sous-tend tous les contrôles — VeriSwarm Gate — est gratuite : notation de confiance complète, 5 000 vérifications autoriser/examiner/refuser par jour, ingestion d’événements illimitée, et émission illimitée d’identifiants de base. Vous pouvez établir une identité et commencer à noter le comportement de l’agent sans carte enregistrée. Ce qui est réservé, c’est la couche d’application — les permissions d’outils de Guard, la tokenisation, la détection d’injection et le kill switch, plus le registre consultable et exportable de Vault — qui relève de Max. L’identité Passport plus complète (vérification, manifestes, délégations) se situe sur Pro, entre les deux. Ne laissez pas un fournisseur laisser entendre que le plan gratuit est une démo bridée ; pour une grande partie des agents internes à faible rayon d’impact, l’identité plus la couche de décision suffisent à elles seules.
Les six contrôles ne sont pas des interrupteurs indépendants — ils alimentent une seule décision. L’identité indique au moteur de politique quel agent fait la demande. La notation de confiance, alimentée par le flux d’événements auquel Guard et Gate écrivent tous deux, lui indique comment cet agent s’est comporté. Les permissions d’outils, la tokenisation des PII et la détection d’injection sont les points d’application où une requête donnée avance ou est stoppée. Le kill switch est le contrôle prioritaire qui l’emporte sur tout le reste. La piste d’audit est ce qui vous permet de reconstituer, après coup, pourquoi une requête donnée a été autorisée ou refusée. Cette décision — allow, review, or deny — est la couche de confiance qui sous-tend les six contrôles. Ce qu’est réellement une couche de confiance.
Identité délimitée (savoir quel agent il s’agit, et qui en est responsable), permissions d’outils à moindre privilège (restreindre les outils qu’il peut appeler et sous quelles conditions), tokenisation des PII (retirer les données sensibles avant qu’elles ne franchissent la limite d’un outil), détection d’injection de prompt (repérer les instructions manipulées avant qu’elles ne déclenchent un appel d’outil), un kill switch (un contrôle prioritaire de l’opérateur qui se situe en dehors du propre raisonnement de l’agent), et une piste d’audit (un enregistrement immuable de ce que l’agent a réellement fait). Aucun des six ne remplace un autre — un agent avec une identité parfaite et sans kill switch n’est jamais qu’à un mauvais prompt d’un incident.
La couche de décision qui sous-tend les six est gratuite : la notation de confiance de VeriSwarm Gate, les décisions de politique autoriser/examiner/refuser (5 000 vérifications/jour), l’ingestion d’événements illimitée, et l’émission illimitée d’identifiants portables de base (jetons d’identité JWT, vérifiables via JWKS) ne coûtent rien. La couche d’application — les permissions d’outils de Guard, la tokenisation des PII, la détection d’injection et le kill switch, plus le registre d’audit consultable et exportable de Vault — est une fonctionnalité du plan Max. La vérification d’identité plus complète avec manifestes signés et délégations (Passport) se situe sur Pro. Vous pouvez connecter l’identité et commencer à noter le comportement sur le niveau gratuit ; l’application est là où le plan payant commence à travailler.
Non. Une instruction de system prompt est une demande dont le modèle peut être détourné — c’est exactement ce qu’exploite l’injection de prompt. Tous les contrôles de cette liste, sauf l’identité, opèrent en dehors du propre raisonnement du modèle : les permissions d’outils sont vérifiées avant l’exécution d’un appel, la tokenisation des PII s’exécute sur le texte indépendamment de ce que l’agent avait l’intention de faire, et le kill switch refuse au niveau de la politique quoi que dise le prompt de l’agent. Le schéma est le même pour les quatre contrôles d’application — déplacer la vérification vers un niveau avec lequel le modèle ne peut pas négocier.
L’identité et la couche de décision (Gate) constituent le plancher — déployer sans elles vous prive de tout moyen de savoir quel agent a fait quoi, ou d’agir face à un schéma de mauvais comportement une fois que vous le constatez. Les quatre autres évoluent avec ce que l’agent peut réellement faire. Un agent interne en lecture seule sans exposition de PII a une surface de risque bien plus mince qu’un agent qui appelle une API de paiement et manipule des données clients — mais dès qu’un agent peut appeler un outil externe ou toucher des données sensibles, les permissions d’outils et la tokenisation des PII cessent d’être optionnelles. Le kill switch et la piste d’audit sont suffisamment peu coûteux, en termes d’ingénierie, qu’il y a rarement une bonne raison de les négliger une fois que Guard et Vault sont déjà connectés.
Les garde-fous d’un framework (callbacks LangChain, validateurs de tâches de CrewAI, un try/except personnalisé autour d’un appel d’outil) s’exécutent dans le même processus que l’agent et dépendent de la bonne exécution du propre chemin de code de l’agent. Les six contrôles présentés ici sont externes à ce processus — VeriSwarm se situe entre l’agent et les outils/décisions qu’il tente de prendre, de sorte qu’un bug ou une injection réussie dans la propre logique de l’agent ne désactive pas non plus le contrôle qui la surveille. C’est la même raison pour laquelle un pare-feu n’est pas implémenté comme un simple paramètre à l’intérieur de l’application qu’il protège.
Chaque contrôle ferme un mode de défaillance distinct, donc en omettre un laisse ce mode spécifique ouvert. Omettez l’identité et vous ne pourrez pas attribuer un incident à un agent spécifique ni révoquer uniquement l’accès de cet agent. Omettez les permissions d’outils et un agent compromis pourra appeler tout ce pour quoi il détient des identifiants. Omettez la tokenisation des PII et une fuite de données ressemblera à l’agent faisant simplement son travail. Omettez la détection d’injection et une entrée manipulée pourra déclencher un appel d’outil non autorisé avant que quiconque ne l’examine. Omettez le kill switch et il n’y aura pas de moyen rapide d’arrêter un agent qui se comporte mal, à part lui retirer ses identifiants. Omettez la piste d’audit et vous n’aurez aucune preuve de ce qui s’est passé, ce qui compte autant pour le post-mortem que pour l’incident lui-même.
La notation de confiance de Gate, les vérifications de décision et l’émission d’identifiants de base ne coûtent rien. Ajoutez les contrôles d’application de Guard et le registre exportable de Vault lorsque le rayon d’impact d’un agent le justifie.