DanLevy.net

Produktions-KI ist beängstigend (und so behebt man es)

Wenn dein Agent keine Guardrails hat, bist du nicht bereit für die Produktion.

Niemand will bewusst ein unsicheres KI-System bauen. Du schreibst Anweisungen, testest Randfälle, fügst ein paar Validierungsregeln hinzu. Dann findet jemand heraus, dass er deinen Bot dazu überreden kann, als Pirat zu roleplayen und Benutzerdaten preiszugeben. Oder eine Kreditkartennummer landet in deinen Logs. Oder das Modell empfiehlt selbstbewusst ein Konkurrenzprodukt.

Die Kluft zwischen »funktioniert in der Demo« und »sicher in der Produktion« ist größer, als die meisten Teams erwarten.

Ein Teil des Problems ist, dass rohe LLMs keine Meinung darüber haben, was sie tun oder lassen sollen. Sie sind Vorhersagemaschinen, die versuchen, jedes begonnene Muster fortzusetzen. Gib ihnen einen Prompt, der wie »System-Override-Modus« aussieht, und sie spielen fröhlich mit. Das ist kein Fehler im Modell; es ist einfach die Funktionsweise von Sprachmodellen.

Die meisten Frameworks reichen dir das Modell und wünschen dir viel Glück. Mastra verfolgt einen anderen Ansatz: Es geht davon aus, dass du irgendwann Guardrails brauchst, und baut sie von Anfang an in die Agentenarchitektur ein.


Prozessoren als Sicherheitsschichten

Der grundlegende Mechanismus ist unkompliziert. Bevor dein Prompt das Modell erreicht, durchläuft er eine Kette von Eingabeprozessoren. Nachdem das Modell geantwortet hat, kommen die Ausgabeprozessoren zum Zug. Jeder Prozessor kann den Inhalt in seiner Phase inspizieren, modifizieren oder blockieren.

Stell sie dir als Middleware für KI-Interaktionen vor. Du stapelst die, die du brauchst, konfigurierst ihr Verhalten, und sie laufen bei jeder Anfrage automatisch.

1. Die Piraten stoppen (Prompt Injection)

Prompt-Injection-Angriffe werden immer kreativer. Leute verwenden unsichtbare Unicode-Zeichen, schreiben Anweisungen in Base64 oder überreden das Modell, dass es sich im »Debug-Modus« befindet, in dem normale Regeln nicht gelten. Die Techniken entwickeln sich ständig weiter.

Mastra enthält Prozessoren, die gängige Muster erkennen:

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. Unsichtbare Zeichen entfernen
new UnicodeNormalizer({
id: 'unicode-normalizer',
stripControlChars: true,
collapseWhitespace: true,
}),
// 2. Den Versuch erkennen
new PromptInjectionDetector({
id: 'prompt-injection-detector',
model: openai('gpt-5-nano'), // Günstig, schnell
threshold: 0.8,
strategy: 'block', // Hartes Stopp
detectionTypes: ['injection', 'jailbreak', 'system-override'],
}),
],
});

Der UnicodeNormalizer entfernt Steuerzeichen und reduziert Leerraum. Der PromptInjectionDetector analysiert die bereinigte Eingabe auf Muster, die darauf hindeuten, dass jemand versucht, deine Anweisungen zu überschreiben.

Du konfigurierst, wie aggressiv die Erkennung sein soll (der Parameter threshold) und was passieren soll, wenn sie auslöst (block, log oder nur markieren).

2. Umgang mit PII

Kreditkartennummern in Logs, Sozialversicherungsnummern in Vektordatenbanken, E-Mail-Adressen, die länger als nötig gespeichert werden. Das sind die Arten von Problemen, die zu regulatorischen Alpträumen werden. Die Herausforderung ist, dass Benutzer nicht immer merken, dass sie sensible Daten in ein Chat-Fenster einfügen.

Der PIIDetector scannt nach gängigen Mustern, bevor sie dein Modell erreichen oder in den Speicher geschrieben werden:

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', // Durch [REDACTED] ersetzen
instructions: 'Detect and mask personally identifiable information',
}),
],
});

Du kannst wählen zwischen Schwärzung (Ersetzen durch [REDACTED]), Hashen oder komplettem Blockieren. Der Prozessor läuft sowohl auf Eingabe als auch auf Ausgabe, sodass du auch abgesichert bist, falls das Modell in seiner Antwort doch sensible Daten generiert.

3. Inhaltsmoderation

Modelle, die mit Internetdaten trainiert wurden, haben einiges gesehen. Ohne Filterung können sie gelegentlich Antworten produzieren, die deiner PR-Abteilung den Angstschweiß auf die Stirn treiben. Der ModerationProcessor fängt Inhalte ab, die gegen deine Richtlinien verstoßen:

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'), // Schnelles, günstiges Modell zur Klassifizierung
categories: ['hate', 'harassment', 'violence', 'self-harm'],
threshold: 0.7, // Blockieren bei Konfidenz > 70 %
strategy: 'block', // Anfrage sofort stoppen
instructions: 'Detect harmful content that violates community guidelines',
}),
],
});

Das Interessante ist, dass du selbst festlegst, welche Kategorien für deinen Anwendungsfall relevant sind. Ein kreatives Schreibwerkzeug erlaubt vielleicht ausdrucksstärkere Inhalte als ein Kundendienst-Bot. Der Schwellwert und die Strategie geben dir die Kontrolle darüber, wie streng die Filterung sein soll.


Wenn etwas auslöst

Prozessoren werfen keine Fehler, wenn sie ein Problem erkennen. Stattdessen setzen sie ein Flag im Ergebnisobjekt:

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.";
}

Dieses Muster ermöglicht es dir, Sicherheitsereignisse so zu behandeln, wie es für deine Anwendung sinnvoll ist. Du kannst sie zur Analyse protokollieren, eine generische Fehlermeldung zurückgeben oder bestimmte Verstöße in bestimmten Kontexten sogar erlauben. Das Feld tripwireReason verrät dir genau, welcher Prozessor den Inhalt markiert hat – hilfreich beim Debuggen von Fehlalarmen oder beim Justieren deiner Schwellwerte.


Was das nicht löst

Prozessoren fangen eine Menge ab, aber sie sind kein Wundermittel. Ein entschlossener Angreifer mit genug Zeit wird wahrscheinlich einen Prompt finden, der durchrutscht. Modelle halluzinieren gelegentlich auf eine Weise, die Prozessoren nicht vorhersagen können. Und es gibt immer einen Trade-off zwischen Sicherheit und Flexibilität: Je strenger deine Regeln, desto wahrscheinlicher blockierst du legitime Anwendungsfälle.

Der Wert liegt nicht im perfekten Schutz. Sondern darin, eine systematische Methode zu haben, um die häufigen Probleme zu handhaben, die in der Produktion garantiert auftreten werden. Du kannst die Empfindlichkeit anpassen, während du lernst, was deine Benutzer tatsächlich tun. Du kannst benutzerdefinierte Prozessoren für domänenspezifische Risiken hinzufügen. Und du hast Audit-Trails, die zeigen, was blockiert wurde und warum.

Die meisten Sicherheitsprobleme in der Produktions-KI sind keine ausgeklügelten Angriffe. Es sind Leute, die Daten kopieren und einfügen, die sie nicht sollten, oder die durch Versuch und Irrtum entdecken, dass der Bot Dinge tut, die du nicht beabsichtigt hast. Prozessoren werden nicht jedes mögliche Problem stoppen, aber sie machen die offensichtlichen deutlich schwieriger.

Ressourcen

Die Serie lesen

  1. LLM-Routing
  2. Sicherheit & Guardrails (Dieser Beitrag)
  3. MCP- & Tool-Integrationen
  4. Workflows & Memory