Zum Hauptinhalt springen
Ein langlaufender autonomer Agent ist das Schwerste zum Absichern. Er loopt stundenlang von selbst, wählt seine eigenen Tools, holt seine eigenen URLs und gibt die ganze Zeit Ihr Geld aus. Die Fehlermodi sind kein einzelner schlechter Prompt — sie sind eine Retry-Schleife, die über Nacht 400 $ verbrennt, ein Tool-Call, den Sie nie geprüft haben, ein Schlüssel, den Sie für ein einwöchiges Experiment geprägt haben und der sechs Monate später noch funktioniert. Dieses Rezept verdrahtet vier Kontrollen um genau diese Art von Agent. Sie konfigurieren alle davon in der Konsole (oder der REST-API) — der Agent ruft weiterhin https://api.orcarouter.ai/v1/... exakt wie zuvor auf.
Neu hier? Wenden Sie zuerst die balanced-Baseline an und beobachten Sie, was Ihr Agent tut, einen Tag lang. Diese Seite ist der nächste Schritt: Beobachtung in Durchsetzung zu verwandeln, für einen Agenten, den Sie nicht babysitten können.

​
1. Das Rezept für einen sicheren autonomen Agenten

Ein sicherer autonomer Agent braucht vier Dinge, die ein Chatbot nicht braucht:

Eine harte Kostenobergrenze

Eine cap_cost-Regel lehnt den Lauf ab, sobald seine kumulierten Ausgaben Ihre Obergrenze überschreiten — der Schutzschalter für eine Schleife, die nicht stoppt.

Spike-Erkennung

Die Anomalieerkennung lernt die normale Hour-of-week-Form des Agenten und flaggt Raten- und Kosten-Spikes, die an statischen Regeln vorbeischlüpfen.

Freigabe auf den gefährlichen Aufrufen

Ein pending_approval-Verdikt hält destruktive oder irreversible Tool-Calls für einen Menschen zurück, statt darauf zu vertrauen, dass der Agent vorsichtig ist.

Ein Schlüssel, der abläuft

Grenzen Sie den Schlüssel des Agenten auf ein Ablaufdatum und eine Credit-Obergrenze ein, sodass ein vergessenes Experiment nicht für immer laufen — oder ausgeben — kann.
Jedes bildet eine Firewall-Policy oder ein Schlüssel-Feld ab. Keines berührt Ihren Agenten-Code.

​
2. Die Kosten jedes Laufs begrenzen

Das Erste, was eine außer Kontrolle geratene Schleife sprengt, ist Ihr Budget. Eine cap_cost-Regel ist eine strikte Pre-Check-Kostenobergrenze: Wenn sie matcht, schätzt das Gateway die Kosten des Requests und lehnt vor dem Dispatch ab, sobald die kumulierten Ausgaben des Laufs die Obergrenze überschreiten würden — sodass ein über-budget Aufruf nie den Anbieter erreicht. Die Obergrenze ist run-bezogen. Das Gateway summiert die vorherigen Ausgaben über den ganzen Agentenlauf, sodass ein langer Lauf, der bereits den Großteil seines Budgets verbrannt hat, abgelehnt wird, selbst wenn der nächste einzelne Aufruf billig ist. Das macht ihn zu einem Schutzschalter statt zu einem Pro-Request-Limit. Fügen Sie Ihrer Firewall-Policy eine Wildcard-Regel hinzu: 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
Das begrenzt den Lauf auf 10 $ (cap_cost_cents ist in USD-Cent). Das Verdikt löst auf allow auf, solange unter Budget, und auf deny, sobald die Schätzung es überschreiten würde. Die meisten eingebauten Firewall-Templates (Coding, Support, RAG, Data, DevOps, Browser) liefern eine Pro-Lauf-Kosten-Cap genau wie diese — wenden Sie eine an und bearbeiten Sie die Obergrenze.
Die run-bezogene Akkumulation benötigt aktivierte Request-Log-Erfassung für den Workspace. Mit ihr aus liest der Vorab-Ausgaben-Rollup null und die Obergrenze degradiert nur auf Pro-Request — immer noch sicher, aber sie fängt kein langsames 500-Aufruf-Tröpfeln. Siehe Denial-of-Wallet.

​
3. Spikes gegen eine gelernte Baseline erkennen

Eine Obergrenze stoppt die Katastrophe; die Anomalieerkennung fängt das Seltsame ab, bevor es zu einer wird. Die Firewall lernt die normale Tool-Nutzungsform jedes Workspaces — einen gleitenden 14-Tage-Durchschnitt, gebucketet nach Hour-of-week, sodass Dienstag-14:00-Traffic gegen Dienstag-14:00-Historie verglichen wird, nicht gegen einen flachen Tagesmittelwert — und legt Abweichungen auf einem für Viewer lesbaren Feed offen:
Pro-Tool-Aufrufvolumen, bewertet gegen die gelernte Baseline. „143 db.query-Aufrufe in einer Stunde gegen eine Baseline von 8” sticht heraus, selbst wenn jeder einzelne Aufruf erlaubt ist.
Dieselbe Baseline, angewendet auf Ausgaben statt Anzahl — ein Lauf, der plötzlich weit mehr verbrennt, als diese Stunde es normalerweise tut.
Die Signatur eines autonomen Agenten, der im Wiederholen desselben kaputten Aufrufs feststeckt. Siehe Übermäßige Handlungsmacht.
Ein Tool-zu-Tool-Sprung, den dieser Workspace nie gemacht hat — die Form eines Agenten, der irgendwohin Neues geht.
Der Feed meldet Tool-Namen, redigierte Token-IDs und Zähler — niemals Roh-Argumente. Das Lesen ist für jedes Mitglied offen; ein Developer+ kann den Feed bis zu 7 Tage lang snoozen, während er ermittelt. Paaren Sie den Feed mit einer cap_cost-Regel, sodass ein Spike, der auch über-budget ist, gestoppt wird, nicht nur bemerkt.

​
4. Die gefährlichen Aufrufe für einen Menschen zurückhalten

Sie können nicht jeden Aufruf prüfen, den ein autonomer Agent macht — aber Sie können ihn dazu bringen, vor der Handvoll, die zählt, anzuhalten und zu fragen. Ein pending_approval-Verdikt hält einen Tool-Call out-of-band zurück:
  1. Der Agent gibt sagen wir einen payments.transfer-Aufruf aus. Die Regel matcht und die Engine gibt HTTP 400 firewall_approval_pending mit einer Approval-ID zurück — der Aufruf erreicht das Tool nie.
  2. Ein Prüfer löst es aus der Konsole auf (Developer+), oder Ihr eigenes System löst es über einen HMAC-signierten Webhook-Callback an POST /api/v1/firewall/approvals/:id/callback auf.
  3. Der Agent pollt GET /api/v1/firewall/approvals/:id; sobald genehmigt, reicht er den ursprünglichen Aufruf mit einem einmal nutzbaren X-OrcaRouter-Firewall-Approval-Header erneut ein, und das Gateway lässt ihn dieses eine Mal durch.
Eine Regel, die Schreibvorgänge auf eine destruktive Surface zurückhält: 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
Rollen Sie dies zuerst im Shadow-Mode aus — pending_approval stuft auf audit herab, sodass Sie sehen, welche Aufrufe zurückgehalten würden, ohne Ihren Agenten tatsächlich zu blockieren. Schalten Sie Shadow aus, wenn der Feed richtig aussieht.

​
5. Dem Agenten einen Schlüssel geben, der abläuft

Die Kontrolle, die jede Policy überlebt, ist der Schlüssel selbst. Ein autonomer Agent sollte einen eingegrenzten Schlüssel bekommen, nicht Ihren Default. Setzen Sie diese Felder, wenn Sie ihn prägen (Konsole → Keys, oder die Token-API):
FeldSetzen Sie es aufWarum
expired_timeeinen Unix-ZeitstempelDas Experiment endet; der Schlüssel stirbt mit ihm. -1 bedeutet nie — verwenden Sie das hier nicht.
credit_limit_usdeine Dollar-ObergrenzeEine Ausgaben-Cap auf dem Schlüssel, unabhängig von der Run-Cap. 0 bedeutet unbegrenzt.
firewall_policy_idIhre Policy obenBindet die cap_cost- + Approval-Regeln an diesen Schlüssel.
allow_ipsdie Egress-IPs des AgentenEin geleakter Schlüssel ist von überall sonst nutzlos.
Setzen Sie auch einen environment-Tag, sodass der Schlüssel — und alles, was er in Events und Matches tut — diesem Agenten zurechenbar ist. Ein ablaufender, credit-begrenzter, IP-gepinnter Schlüssel ist die letzte Linie: Selbst wenn jede Policy irgendwie umgangen würde, ist der Blast-Radius durch Zeit und Dollar begrenzt.
Die Schlüsselkonfiguration ist eine Konsolen- / Token-API-Aktion und rollengesteuert. Das Lesen des Klartextes eines Firewall-Gateway-Keys erfordert Admin+.

​
6. Alles zusammensetzen

Ein gehärteter autonomer Agent landet bei einer Firewall-Policy und einem eingegrenzten Schlüssel:
EbeneKontrolleFängt
Budgetcap_cost-Regel, run-bezogenAußer Kontrolle geratene Schleifen, Denial-of-Wallet
VerhaltenAnomalie-Feed (rate / burn / retry / novel)Das Seltsame-aber-Erlaubte
Vertrauenpending_approval auf destruktiven ToolsIrreversible Aktionen
ScopeAblaufender, credit-begrenzter, IP-gepinnter SchlüsselVergessene oder geleakte Schlüssel
Verfassen Sie die Budget- und Approval-Regeln zusammen, setzen Sie eine Pro-Lauf-Cap mit Firewall-Regeln und lesen Sie den Rest der Firewall-Referenz für Surfaces, Verdikte und Observability. Für die verwandten Bedrohungen, gegen die sich dieses Rezept verteidigt, siehe Übermäßige Handlungsmacht, Gefährliche Tool-Calls und Denial-of-Wallet.

​
7. Nächste Schritte

Einen MCP-Agenten härten

Einen Agenten steuern, der Tools durch MCP-Server erreicht.

Exfiltration stoppen

Egress-Regeln für einen Agenten, der seine eigenen URLs holt.

Enforcement-Modi

Observe → shadow → enforce, das sichere Ausrollen.

Firewall-Regeln

Die Matching-Sprache hinter jeder Regel oben.