Guardrails für KI-Agenten: Sicherheit in Echtzeit

KI-Agenten sind leistungsfähig. Sie entwerfen E-Mails, fassen Dokumente zusammen, rufen APIs auf und treffen Entscheidungen. Gleichzeitig übernehmen sie jedes Risiko, das mit dem Betrieb eines Sprachmodells im Produktivbetrieb einhergeht: Prompt Injection, PII-Leaks, themenfremde Antworten, die Offenlegung des System-Prompts und Outputs, die gegen festgelegte Inhaltsrichtlinien verstoßen.

Ein Produktivstart ohne verbindliche Prüfungen ist keine Sicherheitsstrategie. Prüfungen in der Runtime müssen zwischen Nutzern und Agenten liegen und jeden Input sowie Output prüfen, bevor Schaden entsteht. Genau das leisten Connic Guardrails.

Auch das Threat Model reicht inzwischen über KI-Modell-Outputs hinaus. Die OWASP Top 10 for Agentic Applications 2026 umfassen inzwischen Goal Hijacking, Tool-Missbrauch, Identity- und Privilege-Missbrauch, Memory Poisoning und kaskadierende Fehler. Connic verbindet die Echtzeitprüfung von Input und Output mit eingeschränkten Tools, Approvals, Iterationslimits und Traces, damit Teams diese Risiken über den gesamten Agenten-Run hinweg abdecken können.

Warum Agenten Guardrails brauchen

Klassische Software ist deterministisch. Wenn ein Entwickler eine Funktion schreibt, die zwei Zahlen addiert, addiert sie zwei Zahlen. Sprachmodelle verhalten sich anders. Derselbe Prompt kann je nach Kontext, Temperatureinstellung und Formulierung des Nutzers sehr unterschiedliche Outputs liefern.

Diese Unvorhersehbarkeit erzeugt im Produktivbetrieb konkrete Risiken:

Connic Guardrails decken diese Fälle ab. Sie bilden eine konfigurierbare Schicht um den Agenten, prüfen Inhalte in Echtzeit und greifen ein, bevor Schaden entsteht.

Weiterführende Quellen: OWASP Top 10 for Agentic Applications 2026.

So funktionieren Guardrails

Guardrails liegen in der Ausführungspipeline jedes Agenten-Runs. Sie prüfen Inhalte an zwei Stellen: bevor der Agent den Input verarbeitet und nachdem er eine Antwort erzeugt hat.

Input-Guardrails prüfen die unveränderte Nutzernachricht, bevor der Agent sie sieht. Erkennt ein Guardrail einen Prompt-Injection-Versuch, wird die Nachricht blockiert und der Agent gar nicht erst ausgeführt. Erkannte PII lassen sich direkt maskieren, sodass der Agent eine bereinigte Version erhält.

Output-Guardrails prüfen die Antwort des Agenten, bevor sie den Nutzer erreicht. Enthält die Antwort Fragmente des System-Prompts, toxische Inhalte oder Muster für Datenexfiltration, fängt das Guardrail sie ab. Der Nutzer erhält stattdessen eine sichere Ablehnungsnachricht.

Drei Aktionsmodi

Jede Guardrail-Regel arbeitet in einem von drei Modi. Damit lässt sich präzise steuern, wie strikt eine Prüfung reagieren soll:

10 integrierte Guardrail-Typen

Unsere Plattform liefert Guardrail-Typen für die häufigsten Sicherheitsanforderungen an Agenten im Produktivbetrieb. Jeder Typ kann den Input, den Output oder beides prüfen.

Konfiguration in YAML

Guardrails werden in der YAML-Konfiguration des Agenten definiert. Jede Regel legt Typ, Modus und optionale Parameter fest. Input und Output-Guardrails werden getrennt konfiguriert, sodass sich in jeder Phase unterschiedliche Prüfungen anwenden lassen.

guardrails:
  input:
    - type: prompt_injection
      mode: block
    - type: pii
      mode: redact
      config:
        entities: [email, phone, ssn]
    - type: topic_restriction
      mode: block
      config:
        allowed_topics: [support, billing]
        off_topic_message: "I can only help with support and billing questions."
  output:
    - type: moderation
      mode: block
    - type: system_prompt_leakage
      mode: block
    - type: pii_leakage
      mode: redact
    - type: relevance
      mode: warn

Diese Konfiguration blockiert Prompt Injection beim Input, maskiert PII in Nutzernachrichten, beschränkt den Agenten auf Support und Billing und prüft den Output anschließend auf Verstöße gegen Moderation, Offenlegung des System-Prompts, PII in der Antwort und Abweichungen bei der Relevanz.

Custom Guardrails schreiben

Wenn die integrierten Typen nicht ausreichen, lassen sich Custom Guardrails in Python schreiben. Im guardrails/-Verzeichnis des Agenten wird dafür ein Modul angelegt, das eine check()-Funktion exportiert. Sie erhält den geprüften Inhalt und ein Kontext-Dictionary mit Metadaten zum aktuellen Run.

from connic import GuardrailResult

COMPETITORS = ["acme corp", "rival inc", "other platform"]

def check(content: str, context: dict) -> GuardrailResult:
    content_lower = content.lower()
    for name in COMPETITORS:
        if name in content_lower:
            return GuardrailResult(
                passed=False,
                message="I'm not able to discuss other platforms.",
                details={"matched": name},
            )
    return GuardrailResult(passed=True)

Anschließend wird das Modul in der YAML-Konfiguration referenziert:

guardrails:
  output:
    - type: custom
      name: competitor_mentions
      mode: block

Vollständige Observability mit Traces

Jede Guardrail-Prüfung wird als OpenTelemetry-Trace-Span erfasst. Der Trace zeigt vollständig, was geprüft wurde, was bestanden hat und was blockiert oder maskiert wurde.

Damit lassen sich Fragen beantworten wie: Wie oft wird Prompt Injection versucht? Welche Agenten lösen die meisten PII-Maskierungen aus? Sind Themenbeschränkungen zu aggressiv? Die Daten sind für jeden Run vorhanden.

Externe Provider

Mehrere integrierte Guardrail-Typen unterstützen externe Provider für eine genauere Erkennung. Die Standard-Engine lässt sich durch einen spezialisierten Service ersetzen, ohne die Guardrail-Konfiguration zu ändern:

Beispiele aus der Praxis

Diese Guardrail-Konfigurationen verwenden Teams im Produktivbetrieb:

Erste Schritte

Guardrails lassen sich in wenigen Minuten zu einem bestehenden Agenten hinzufügen:

• 1.Die YAML-Konfiguration des Agenten um einen guardrails-Abschnitt mit den benötigten Regeln ergänzen
• 2.Den Agenten bereitstellen. Die Guardrails werden bei der nächsten Ausführung automatisch aktiv
• 3.Im Connic-Dashboard den Tab Traces prüfen, um die Guardrail-Spans jeder Ausführung zu sehen
• 4.Einzelne Ausführungen öffnen, um ausgelöste Guardrails und blockierte Anfragen genauer zu untersuchen

Als Ausgangspunkt eignen sich Prompt-Injection- und PII-Erkennung, weil sie die häufigsten Angriffsvektoren abdecken. Themenbeschränkungen, Moderation und eigene Prüfungen können folgen, sobald belastbare Traffic-Muster vorliegen.

Die vollständige Konfigurationsreferenz und alle Optionen stehen in der Guardrails-Dokumentation. Für den Einstieg in Connic lässt sich mit dem Quickstart-Leitfaden ein erster Agent bereitstellen und anschließend um weitere Schutzmaßnahmen ergänzen.