KI-Agenten absichern: Checkliste für den Produktivbetrieb

Eine Webanwendung würde kaum ohne Authentifizierung, Eingabevalidierung und Rate Limits veröffentlicht. Viele Teams veröffentlichen KI-Agenten dennoch ohne vergleichbare Schutzmaßnahmen. Der Agent funktioniert in der Demo und gelangt in den Produktivbetrieb. Erst bei den ersten Angriffsversuchen zeigt sich unvorhergesehenes Verhalten.

Die Checkliste erläutert, mit welchen Schutzmaßnahmen KI-Agenten vor dem Go-live abgesichert werden und wie sie umgesetzt werden.

Das Bedrohungsmodell für KI-Agenten

Die Sicherheitsrisiken von KI-Agenten sind nicht theoretisch. Die OWASP Top 10 for Agentic Applications 2026 erweitern das Bedrohungsmodell über den KI-Modell-Output hinaus um Goal Hijacking, Tool Misuse, Privilege Abuse, Memory und Context Poisoning sowie Cascading Failures. Diese Risiken wachsen, wenn ein Agent mit der Identität eines Nutzers oder persistentem Kontext systemübergreifend handeln kann.

Die Absicherung eines Agenten beginnt mit dem Verständnis der relevanten Bedrohungen. Diese Angriffe treten im Produktivbetrieb auf:

Sicherheitscheckliste für den Produktivbetrieb

Diese Schutzmaßnahmen sollten eingerichtet sein, bevor ein Agent echten Nutzern gegenübersteht. Zu jeder Schutzmaßnahme folgt eine konkrete Implementierungsanleitung.

1. Prompt Injection im Input blockieren

Jede Nutzernachricht sollte auf Injection-Versuche geprüft werden, bevor der Agent sie verarbeitet.

Wirksame Prompt-Injection-Erkennung geht über Keyword-Matching hinaus. Sie muss Folgendes erkennen:

• →Direktes Überschreiben von Anweisungen: „Ignoriere vorherige Anweisungen“ und Varianten
• →Encoding-Angriffe: Base64-codierte Anweisungen, hexadezimal codierte Payloads
• →Zeichenmanipulation: Typoglykämie (vertauschte Zeichen), Unicode-Substitution
• →Strukturelle Angriffe: Delimiter-Injection, Kontextmanipulation durch Formatierung

guardrails:
  input:
    - type: prompt_injection
      mode: block
      config:
        sensitivity: medium  # low, medium, or high

Wird eine Prompt Injection erkannt, wird der Agent nicht ausgeführt. Die Anwendung gibt eine Ablehnung aus und erfasst den Versuch zur Sicherheitsprüfung als Trace-Span.

2. Personenbezogene Daten schützen, bevor sie das KI-Modell erreichen

In Nutzereingaben können sensible Daten enthalten sein. Entscheidend ist, ob diese Daten die API des KI-Modell-Providers erreichen oder zuvor abgefangen werden.

Drei Modi stehen zur Verfügung:

guardrails:
  input:
    - type: pii
      mode: redact
      config:
        entities: [email, phone, ssn, credit_card, api_key]
  output:
    - type: pii_leakage
      mode: redact

Auch der Output-Guardrail ist wichtig. PII kann in Antworten des Agenten erscheinen, selbst wenn sie nicht im ursprünglichen Input enthalten war. Wenn ein Agent über Tools oder Retrieval auf Kundendaten zugreift, verhindert die PII-Erkennung im Output, dass sensible Informationen in Antworten sichtbar werden.

3. Offenlegung des System-Prompts verhindern

Ein System-Prompt enthält die Persönlichkeit des Agenten, Geschäftsregeln, Tool-Schemas und Betriebsanweisungen. Extrahiert ein Angreifer ihn, besitzt er einen Bauplan zur Manipulation des Agenten.

guardrails:
  output:
    - type: system_prompt_leakage
      mode: block

Jede Antwort des Agenten wird auf Fragmente geprüft, die dem System-Prompt entsprechen. Beginnt der Agent seine Anweisungen offenzulegen, wird die Antwort blockiert und durch eine sichere Nachricht ersetzt.

4. Den Agenten auf seinen Aufgabenbereich begrenzen

Sprachmodelle beantworten bereitwillig Fragen zu jedem Thema. Ein Support-Agent für Abrechnungsfragen sollte weder Kochtipps noch medizinische Empfehlungen geben. Topic Restriction hält den Agenten auf seine vorgesehene Aufgabe fokussiert.

guardrails:
  input:
    - type: topic_restriction
      mode: block
      config:
        allowed_topics:
          - billing and payments
          - subscription management
          - account settings
        off_topic_message: "I can only help with billing and account questions."
        model: connic/gpt-5.6-luna

Je nach Einsatzbereich lassen sich erlaubte oder blockierte Themen definieren. Die Prüfung nutzt einen schlanken LLM-Call zur Klassifizierung und benötigt daher einen KI-Modellparameter. Ein schnelles, günstiges KI-Modell hält Latenz und Kosten niedrig.

5. Output-Inhalte moderieren

Auch mit einem guten System-Prompt können Sprachmodelle unangemessene Inhalte erzeugen. Inhaltsmoderation im Output erkennt Toxizität, Belästigung, Hassrede und andere Verstöße gegen Richtlinien vor der Ausgabe.

guardrails:
  output:
    - type: moderation
      mode: block
      config:
        categories:
          - hate
          - harassment
          - violence
          - self_harm

6. Versuche zum Datenabfluss erkennen

Ein subtiler, aber gefährlicher Angriff: Prompts veranlassen den Agenten, sensible Daten in URLs, Markdown-Bildern oder strukturierten Ausgaben zu codieren und an externe Server zu senden. Besonders gefährlich ist dies für Agenten mit Tool-basiertem Zugriff auf interne Daten.

guardrails:
  output:
    - type: data_exfiltration
      mode: block
      config:
        allowed_domains:
          - yourdomain.com
          - docs.yourdomain.com

Dies erkennt verdächtige URLs mit codierten Daten in Query-Parametern, auf externe Domains verweisende Markdown-Bild-Tags und Base64-codierte Datenblöcke in der Antwort. Die Liste erlaubter Domains stellt sicher, dass legitime Referenzen nicht blockiert werden.

7. Eigene Geschäftsregeln ergänzen

Jedes Unternehmen hat eigene Sicherheitsanforderungen, die integrierte Guardrails nicht vollständig abdecken können. Eigene Guardrails unterstützen beliebige Validierungslogik in Python.

from connic import GuardrailResult

REQUIRED_DISCLAIMERS = [
    "not financial advice",
    "consult a professional",
]

def check(content: str, context: dict) -> GuardrailResult:
    """Ensure financial responses include disclaimers."""
    agent_name = context.get("agent_name", "")
    if "finance" not in agent_name:
        return GuardrailResult(passed=True)

    content_lower = content.lower()
    has_disclaimer = any(d in content_lower for d in REQUIRED_DISCLAIMERS)

    if not has_disclaimer:
        return GuardrailResult(
            passed=False,
            message="Response must include a disclaimer.",
        )
    return GuardrailResult(passed=True)

Gängige eigene Guardrails blockieren Erwähnungen von Wettbewerbern, prüfen regulatorische Compliance-Hinweise, filtern interne Terminologie oder wenden domänenspezifische Validierungsregeln an.

8. Output-Relevanz prüfen

Manchmal liefert ein Agent zwar keine schädlichen Inhalte, beantwortet aber die eigentliche Frage nicht. Die Relevanzprüfung erkennt Goal Hijacking, bei dem ein Angreifer den Zweck des Agenten subtil umlenkt, sowie erfundene Inhalte abseits der eigentlichen Frage.

guardrails:
  output:
    - type: relevance
      mode: warn
      config:
        model: connic/gpt-5.6-luna

Der Warn-Modus zeigt zunächst die Häufigkeit irrelevanter Antworten. Ist die Rate inakzeptabel, folgt der Wechsel in den Block-Modus.

Alles zusammenführen

Eine vollständige Guardrail-Konfiguration für einen Support-Agenten im Produktivbetrieb:

version: "1.0"
name: customer-support
model: connic/gpt-5.6-terra
system_prompt: |
  You are a customer support agent for Acme Corp.
  Help customers with orders, billing, and product questions.
tools:
  - support.search_orders
  - support.search_retrieval
  - support.create_ticket

guardrails:
  input:
    - type: prompt_injection
      mode: block
      config:
        sensitivity: medium
    - type: pii
      mode: redact
      config:
        entities: [email, phone, ssn, credit_card]
    - type: topic_restriction
      mode: block
      config:
        allowed_topics: [orders, billing, products, returns]
        off_topic_message: "I can only help with Acme Corp products and orders."
        model: connic/gpt-5.6-luna
  output:
    - type: moderation
      mode: block
    - type: system_prompt_leakage
      mode: block
    - type: pii_leakage
      mode: redact
    - type: data_exfiltration
      mode: block
      config:
        allowed_domains: [acmecorp.com]
    - type: relevance
      mode: warn
      config:
        model: connic/gpt-5.6-luna

Observability: sehen, was erkannt wird

Ohne Protokollierung bleibt unklar, wie Sicherheitskontrollen reagieren. Jede Guardrail-Evaluation wird als Trace-Span aufgezeichnet. Zusammen ergeben die Aufzeichnungen einen vollständigen Audit-Trail.

Mit diesen Daten lassen sich Fragen beantworten wie: Wie häufig wird Prompt Injection versucht? Welche Agenten lösen die meisten PII-Schwärzungen aus? Sind Themenbeschränkungen zu aggressiv? Guardrails lassen sich so anhand realer Traffic-Muster abstimmen.

Mehrschichtige Absicherung über Guardrails hinaus

Guardrails bilden die Sicherheitsschicht der Runtime. Eine vollständige Sicherheitsstrategie umfasst jedoch weitere Schutzmaßnahmen:

Erste Schritte

Für eine neue Implementierung empfiehlt sich dieser Ansatz:

• 1.Mit der Grundkonfiguration starten. prompt_injection und pii im Input sowie moderation und system_prompt_leakage im Output decken die häufigsten Angriffsvektoren ab.
• 2.Zuerst den Warn-Modus verwenden. Die Markierungen sollten vor dem Wechsel zu Block beobachtet werden. So werden legitime Requests während der Abstimmung der Empfindlichkeit nicht abgelehnt.
• 3.Anhand des Traffics erweitern. Sobald reale Nutzungsmuster sichtbar sind, folgen Topic Restriction, Relevance Checking und eigene Guardrails auf Basis der tatsächlich beobachteten Risiken.
• 4.Trace-Daten regelmäßig prüfen. Häufig ausgelöste Guardrails und ihre Muster sollten untersucht werden. Empfindlichkeit und Modi lassen sich anpassen, sobald der Traffic besser verstanden ist.

Die vollständige Konfigurationsreferenz steht in der Guardrails-Dokumentation. Einen tieferen Einblick in die integrierten Guardrail-Typen bietet Guardrails für KI-Agenten: Sicherheit in Echtzeit.