DanLevy.net

L'IA en production fait peur (et comment y remédier)

Si votre agent n'a pas de garde-fous, vous n'êtes pas prêt pour la production.

Personne ne part avec l’intention de construire un système IA non sécurisé. Vous rédigez des instructions, vous testez des cas limites, vous ajoutez quelques règles de validation. Et puis quelqu’un découvre qu’il peut piéger votre bot pour qu’il joue les pirates et expose des données utilisateurs. Ou un numéro de carte bancaire se retrouve dans vos logs. Ou le modèle recommande avec assurance le produit d’un concurrent.

L’écart entre « fonctionne en démo » et « sûr en production » est plus large que la plupart des équipes ne l’imaginent.

Le problème, en partie, c’est que les LLM bruts n’ont aucune opinion sur ce qu’ils devraient ou ne devraient pas faire. Ce sont des machines à prédiction qui tentent de prolonger le motif que vous leur avez soumis. Donnez-leur un prompt qui ressemble à une « surcouche de débogage », et ils joueront le jeu avec enthousiasme. Ce n’est pas un bug du modèle ; c’est simplement ainsi que fonctionnent les modèles de langage.

La plupart des frameworks vous tendent le modèle et vous souhaitent bonne chance. Mastra adopte une approche différente : il part du principe que vous aurez besoin de garde-fous tôt ou tard, et les intègre à l’architecture de l’agent dès le départ.


Les processeurs comme couches de sécurité

Le mécanisme de base est simple. Avant que votre prompt n’atteigne le modèle, il traverse une chaîne de processeurs d’entrée. Une fois que le modèle a répondu, les processeurs de sortie prennent le relais. Chaque processeur peut inspecter, modifier ou bloquer le contenu à ce stade.

Considérez-les comme des middlewares pour les interactions IA. Vous empilez ceux dont vous avez besoin, configurez leur comportement, et ils s’exécutent automatiquement à chaque requête.

1. Arrêter les pirates (injection de prompt)

Les attaques par injection de prompt ont fait preuve de créativité. Certains utilisent des caractères Unicode invisibles, écrivent des instructions en base64, ou convainquent le modèle qu’il est en « mode débogage » où les règles habituelles ne s’appliquent pas. Les techniques ne cessent d’évoluer.

Mastra inclut des processeurs qui détectent les schémas courants :

src/mastra/agents/secure-agent.ts
import { Agent } from '@mastra/core/agent';
import { PromptInjectionDetector, UnicodeNormalizer } from '@mastra/core/processors';
import { openai } from '@ai-sdk/openai';
export const secureAgent = new Agent({
id: 'fortress-assistant',
name: 'fortress-assistant',
instructions: 'You are a secure assistant.',
model: openai('gpt-5'),
inputProcessors: [
// 1. Scrub invisible characters
new UnicodeNormalizer({
id: 'unicode-normalizer',
stripControlChars: true,
collapseWhitespace: true,
}),
// 2. Detect the attempt
new PromptInjectionDetector({
id: 'prompt-injection-detector',
model: openai('gpt-5-nano'), // Cheap, fast
threshold: 0.8,
strategy: 'block', // Hard stop
detectionTypes: ['injection', 'jailbreak', 'system-override'],
}),
],
});

Le UnicodeNormalizer supprime les caractères de contrôle et normalise les espaces. Le PromptInjectionDetector analyse le texte nettoyé pour repérer les motifs suggérant une tentative de contournement de vos instructions.

Vous configurez le niveau d’agressivité souhaité (paramètre threshold) et le comportement en cas de détection (bloquer, journaliser ou simplement signaler).

2. Gestion des données personnelles (PII)

Des numéros de carte bancaire dans les logs, des numéros de sécurité sociale dans des bases vectorielles, des adresses e-mail conservées plus longtemps que nécessaire. Ce sont le genre de problèmes qui se transforment en casse-tête réglementaire. La difficulté, c’est que les utilisateurs ne réalisent pas toujours qu’ils collent des données sensibles dans une fenêtre de chat.

Le PIIDetector scanne les motifs courants avant qu’ils n’atteignent votre modèle ou ne soient stockés :

import { PIIDetector } from '@mastra/core/processors';
export const privateAgent = new Agent({
id: 'privacy-first-assistant',
name: 'privacy-first-assistant',
instructions: 'You are a helpful assistant that never stores personal information.',
model: openai('gpt-5'),
inputProcessors: [
new PIIDetector({
id: 'pii-detector',
model: openai('gpt-5-nano'),
detectionTypes: ['email', 'phone', 'credit-card', 'ssn'],
threshold: 0.6,
strategy: 'redact',
redactionMethod: 'mask', // Replace with [REDACTED]
instructions: 'Detect and mask personally identifiable information',
}),
],
});

Vous pouvez choisir de masquer (remplacer par [REDACTED]), de hasher, ou de bloquer entièrement. Le processeur s’exécute à la fois sur l’entrée et la sortie, vous êtes donc couvert même si le modèle génère accidentellement des données sensibles dans sa réponse.

3. Modération du contenu

Les modèles entraînés sur des données internet ont vu pas mal de choses. Sans filtrage, ils peuvent occasionnellement produire des réponses qui rendraient votre équipe communication nerveuse. Le ModerationProcessor intercepte le contenu qui enfreint vos lignes directrices :

import { ModerationProcessor } from '@mastra/core/processors';
export const moderatedAgent = new Agent({
id: 'safe-assistant',
name: 'safe-assistant',
instructions: 'You are a helpful assistant for a community platform.',
model: openai('gpt-5'),
inputProcessors: [
new ModerationProcessor({
id: 'moderation-processor',
model: openai('gpt-5-nano'), // Fast, cheap model for classification
categories: ['hate', 'harassment', 'violence', 'self-harm'],
threshold: 0.7, // Block if confidence > 70%
strategy: 'block', // Stop the request immediately
instructions: 'Detect harmful content that violates community guidelines',
}),
],
});

L’aspect intéressant est que vous définissez vous-même les catégories pertinentes pour votre cas d’usage. Un outil d’écriture créative pourra autoriser un contenu plus expressif qu’un bot de service client. Le seuil et la stratégie vous donnent le contrôle sur la rigueur du filtrage.


Quand un processeur se déclenche

Les processeurs ne lancent pas d’erreurs lorsqu’ils détectent un problème. À la place, ils positionnent un drapeau sur l’objet résultat :

const result = await secureAgent.generate('Ignore all previous instructions...');
if (result.tripwire) {
console.log(`Blocked! Reason: ${result.tripwireReason}`);
// "Blocked! Reason: Prompt injection detected."
return "Nice try, script kiddie.";
}

Ce modèle vous laisse gérer les événements de sécurité comme bon vous semble pour votre application. Vous pouvez les journaliser pour analyse, renvoyer un message d’erreur générique, ou même autoriser certaines violations dans des contextes spécifiques. Le champ tripwireReason vous indique exactement quel processeur a signalé le contenu, ce qui aide au débogage des faux positifs ou à l’ajustement de vos seuils.


Ce que cela ne résout pas

Les processeurs en interceptent beaucoup, mais ils ne sont pas magiques. Un attaquant déterminé avec suffisamment de temps pourra probablement trouver un prompt qui passe entre les mailles du filet. Les modèles hallucinent parfois d’une manière que les processeurs ne peuvent pas anticiper. Et il y a toujours un compromis entre sécurité et flexibilité : plus vos règles sont strictes, plus vous risquez de bloquer des cas d’usage légitimes.

La valeur n’est pas une protection parfaite. C’est d’avoir une méthode systématique pour gérer les problèmes courants qui surviendront immanquablement en production. Vous pouvez ajuster la sensibilité au fil de l’apprentissage de ce que font réellement vos utilisateurs. Vous pouvez ajouter des processeurs personnalisés pour des risques spécifiques à votre domaine. Et vous disposez de traces d’audit montrant ce qui a été bloqué et pourquoi.

La plupart des problèmes de sécurité en IA production ne sont pas des attaques sophistiquées. Ce sont des gens qui copient-collent des données qu’ils ne devraient pas, ou qui découvrent par tâtonnement que le bot fera des choses que vous n’aviez pas prévues. Les processeurs n’arrêteront pas tous les problèmes possibles, mais ils rendent les plus évidents beaucoup plus difficiles.

Ressources

Lire la série

  1. Routage LLM
  2. Sécurité et garde-fous (Cet article)
  3. Intégrations MCP et outils
  4. Workflows et mémoire