Das Anwenden einer Sicherheitshaltung ändert eine Workspace-Einstellung,
daher benötigen Schritt 2 und Schritt 5 die Rolle Developer. Der
Guardrail-Matches-Feed (Schritt 4) ist für jedes Mitglied offen; der
Firewall-Events-Feed benötigt ebenfalls Developer.
In 5 Schritten aktivieren
Einen API-Key erhalten
Falls Sie noch keinen haben, erstellen Sie einen Schlüssel — siehe
Einen API-Key erhalten. Geben Sie diesen
Schlüssel dem Agenten, den Sie absichern möchten. Alles unten bindet an
Ihren Workspace, sodass dieselbe Haltung jeden Schlüssel darin abdeckt.
Die Secure-Agents-Baseline anwenden
Öffnen Sie in der Konsole Firewall → Posture und wenden Sie das
balanced Autonomie-Level
an (Rolle Developer).In einer Transaktion setzt dies sowohl Ihre Firewall- als auch Guardrails-
Haltung: Tool-Calls werden auditiert und PII wird markiert, während die
destruktivsten Aktionen (wie destruktive Shell) verweigert werden — damit
Sie beobachten, bevor Sie breit durchsetzen. Es ist ein einzelner Schalter
mit Ein-Klick-Undo. (Für einen Durchlauf, der gar nichts blockiert, starten
Sie bei permissive.)Einen Request exakt wie zuvor senden
An Ihrem Aufruf ändert sich nichts. Verwenden Sie denselben Schlüssel,
dieselbe OpenAI-Form:Der Request geht durch. Unter
balanced wird er nicht blockiert — er wird
beobachtet. Die E-Mail wird markiert, und alle Tool-Calls, die Ihr Agent
macht, werden aufgezeichnet.Sehen, was Ihr Agent tatsächlich getan hat
Zwei Feeds, beide workspace-bezogen:
- Firewall → Events / Runs — jeder Tool-Call Ihres Agenten, sein Verdikt und welche Surface er getroffen hat (das Tool, das er angeboten hat, der Aufruf, den das Modell emittiert hat, ein MCP-Dispatch oder ein ausgehendes Ziel).
- Guardrails → Matches — jede Regel, die ausgelöst hat, wie die markierte E-Mail, gruppiert nach Guardrail und Aktion.
Zur Durchsetzung verschärfen
Sobald die Feeds richtig aussehen, wechseln Sie das Autonomie-Level zu
tight auf derselben Firewall → Posture-Seite (Rolle Developer).Jetzt ist die Durchsetzung live: PII wird maskiert, bevor das Modell es
sieht, Secrets werden aus Ihren Requests blockiert, und destruktive
Shell-Aufrufe und SSRF-Egress werden verweigert. Ein verweigerter Tool-Call
kommt als HTTP 400 firewall_blocked zurück; ein blockierter Prompt
kommt als HTTP 400 guardrail_blocked zurück — und ein Block kostet
kein Kontingent. Keine Anwendungsänderung — der allernächste Request
wird gesteuert.Was Sie gerade eingeschaltet haben
| Ebene | Unter balanced | Unter tight |
|---|---|---|
| Guardrails (Text) | PII markiert (nur Audit) | PII maskiert, Secrets blockiert |
| Firewall (Aktionen) | Auditiert; destruktive Shell verweigert | Standard-Deny; destruktive Shell + SSRF-Egress verweigert |
| Sichtbarkeit | Vollständig — Events + Matches | Vollständig — Events + Matches |
Zu streng gemacht?
Jede Autonomie-Änderung ist eine Transaktion mit Ein-Klick-Undo, sodass Sie direkt zu Ihrer vorherigen Haltung von der Firewall-Seite (oder der Undo-API) zurückrollen können. Sie können auch jederzeit ein weicheres Level (balanced
oder permissive) erneut anwenden.
Nächste Schritte
Die Secure-Agents-Baseline
Was jedes Autonomie-Level setzt und wie man vor dem Anwenden simuliert.
Enforcement-Modi
Observe → Shadow → Enforce, das sichere Rollout im Detail.
Guardrails
Eigene Content-Regeln über die Baseline hinaus verfassen.
Agent-Firewall
Tool-Allowlists, Argument-Prüfungen und Egress-Regeln verfassen.
