Aller au contenu

Canaux agent

Un agent LLM lit des e-mails, appelle des outils, voit des schémas d’outils MCP et écrit en mémoire. Ce sont les canaux par lesquels arrivent l’injection indirecte, l’empoisonnement d’outils MCP et l’empoisonnement de mémoire. Le prompt de l’utilisateur, lui, est souvent parfaitement anodin.

monsys n’inspecte pas ces canaux en ligne et ne bloque rien (voir les trois invariants). Il consigne ce que l’agent a lu, haché et expurgé, et en tire deux signaux déterministes : des indicateurs d’injection et la dérive de schéma. Un humain juge.

Quatre événements typés sur un span de l’enveloppe SDK existante ; les champs exacts sont dans la spec de l’enveloppe.

Événement Quand
tool_call l’agent appelle un outil (nom + arguments)
tool_result un outil renvoie quelque chose que le modèle va lire
mcp_schema un serveur MCP présente une description et un schéma d’entrée
memory_write l’agent écrit en mémoire à long terme

Les SDK ont des helpers (span.tool_result(...), span.mcpSchema(...), s.MemoryWrite(...)). Le hub applique la même expurgation qu’aux prompts : les PII deviennent des jetons hachés étiquetés, et la base ne contient que le sha256 plus les métadonnées.

Sur tout ce que le modèle va lire (résultats d’outils, schémas, mémoire) tournent onze regex nommées. Pas de modèle, pas de score : une correspondance est une étiquette sur l’événement.

Indicateur Ce qu’il cherche
ignore_previous « ignore/disregard previous instructions »
role_override « you are now … », « new instructions: »
system_prompt_exfil « reveal/print the system prompt »
tool_invocation « call/invoke/run the … tool/function/api »
secrecy « do not tell the user »
hidden_html commentaire HTML contenant des instructions
zero_width caractères Unicode invisibles
markdown_exfil lien image avec querystring vers un domaine externe
shell_pipe curl … | sh
prompt_delimiters [INST], <<SYS>>, ### system
base64_blob longue séquence base64

Une correspondance crée une alerte ai_injection dans la boîte d’actions (critique pour tool_invocation, shell_pipe, markdown_exfil ou trois indicateurs ou plus ; sinon avertissement). L’alerte indique l’outil ou la source et renvoie à la trace. Vous décidez si la source est fiable ; monsys ne change rien à l’agent.

L’empoisonnement d’outil est par définition un changement de description. monsys garde par (app, serveur, outil) un sha256 canonique de la description

  • schéma d’entrée. S’il change :
  1. une ligne apparaît dans le journal des changements avec ancien et nouveau hash ;
  2. l’alerte ai_mcp_drift apparaît dans la boîte (et en push) ;
  3. le changement compte comme dérive de configuration dans le Trust Score (5 points par changement ouvert, maximum 30, pour tout le tenant) jusqu’à confirmation.

Vous confirmez dans le portail (IA → Canaux agent → Confirmer comme voulu) ou via POST /api/v1/ai/mcp-schemas/ack. Une mise à jour voulue d’un outil tient en un clic ; une mise à jour inattendue reste visible.

  • IA → Canaux agent : compteurs par type (30 jours), registre des schémas avec état de dérive, événements avec puces d’indicateurs.
  • Boîte d’actions et app : les alertes ai_injection et ai_mcp_drift.
  • Evidence pack : agent_events.jsonl (chaque événement avec hash et indicateurs) et mcp_schemas.json (registre + changements de la période), avec leurs sha256 dans le manifeste signé Ed25519.
  • API : GET /api/v1/ai/agent-channels/summary, GET /api/v1/ai/agent-events?indicators=1, GET /api/v1/ai/mcp-schemas.

Le Claude Connector est lui-même un canal agent. tools/list renvoie donc un _meta : le sha256 du catalogue canonique d’outils, une signature Ed25519 avec la clé du hub et l’entrée du journal de transparence (kind = mcp.tool_catalog). Qui conserve le hash peut prouver plus tard quelles descriptions d’outils Claude a vues ; un catalogue modifié est une nouvelle entrée publique.

Pas de pare-feu, pas de LLM juge, pas de blocage dans le chemin de requête et pas d’analyse de données d’entraînement. Pour de l’enforcement, branchez votre propre garde sur notre webhook ; monsys fournit la preuve qu’un auditeur peut vérifier sous AI Act art. 15 et NIS2 art. 21.