Ne faites pas confiance aux promesses de sécurité de votre LLM pendant toutes les exécutions

La plupart des garde-corps de sécurité LLM sont construits sur la base d'une hypothèse silencieuse : tout votre trafic destiné aux clients passe par un seul environnement d'exécution. Un processus. Un contrôle de sécurité en cours de processus. Fait.

Cette hypothèse prend fin au moment où vous déployez une pile polyglotte.

Il s'agit d'une description d'un modèle que nous appelons contrats de parité : une primitive de sécurité déployable pour les agents commerciaux LLM qui s'étendent sur plusieurs exécutions. Nous l'avons implémenté en production chez BrewHub PHL, un café de Philadelphie dont l'agent IA, Franklin, passe des commandes, facture le portefeuille des clients et émet des mutations de fidélité sans étape d'approbation humaine. L'article académique complet, le corpus de l'équipe rouge et l'exécuteur de test de parité sont open source sur github.com/BrewHubPHL/allergen-parity-corpus.

Le problème : les déploiements polyglottes rompent la sécurité du processus

L'architecture de BrewHub s'étend sur trois environnements d'exécution :

• Runtime 1 — Next.js sur Netlify (AWS Lambda) : point de terminaison de chat SSE orienté client, appels d'outils de Franklin, recalcul des prix
• Runtime 2 — Fonctions Netlify (AWS Lambda) : paiement au point de vente, traitement des paiements, gestionnaires de webhook Square
• Runtime 3 — Google Cloud Run (Python ADK) : six agents de flux de travail spécialisés : opérations, marketing, formation de barista, récupération de service, concierge, conteur de provenance

Chaque bibliothèque de sécurité LLM existante (Llama Guard, NeMo Guardrails, LlamaFirewall, MCP-Guard) suppose un environnement d'exécution à service unique. Leur garantie est une garantie in-process : si le trafic passe par ce runtime, la porte tient bon. C'est très bien pour les déploiements à exécution unique. C'est un handi...
[Courte citation de 8% de l'article original]