Gefährliche & nicht autorisierte Tool-Calls

Ein Agent, der prompt-injiziert, falsch konfiguriert oder einfach mit zu viel Spielraum ausgestattet wurde, kann Tools aufrufen, die er nie berühren sollte — oder ein legitimes Tool mit gefährlichen Argumenten aufrufen: shell.exec mit rm -rf /, eine Payment-API mit einem überhöhten Überweisungsbetrag, ein Datenbanktools, das auf das Produktionsreplikat abzielt. Das ist Agenten- Tool-Missbrauch, und er ist eines der folgenreichsten Risiken in agentischen Systemen, weil Tool-Calls reale Seiteneffekte haben, die oft irreversibel sind. Die Agent-Firewall hat drei geschichtete Verteidigungen. Sie können sie unabhängig oder in Kombination einsetzen.

1. Allowlisting: alles verweigern, was Sie nicht explizit erlaubt haben

Die stärkste Kontrolle ist eine Allowlist. Anstatt zu versuchen, jedes gefährliche Tool aufzuzählen, zählen Sie die Tools auf, die dieser Agent legitim benötigt — und verweigern alles andere. Das ist die Zero-Trust-Baseline. Eine Policy mit default_verdict: deny und expliziten allow-Regeln für jedes genehmigte Tool erreicht das. Beispiel: ein Agent, der nur aus einem CRM lesen sollte:

[
  {
    "priority": 10,
    "label": "allow crm reads",
    "tool_name_glob": "crm.get*",
    "verdict": "allow"
  },
  {
    "priority": 20,
    "label": "allow crm search",
    "tool_name_glob": "crm.search",
    "verdict": "allow"
  },
  {
    "priority": 9999,
    "label": "deny everything else",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]

Jeder Aufruf an shell.exec, db.delete, payment.transfer — ob absichtlich ausgestellt oder durch eine injizierte Anweisung ausgelöst — trifft den *-Catch-All und gibt einen HTTP 400 firewall_blocked-Fehler zurück. Der Agent sieht einen strukturierten Tool-Fehler und kann nicht wiederholen (der Block ist als skip-retry markiert), sodass er die Verweigerung nicht umschleifen kann.

Setzen Sie das default_verdict Ihrer Policy auf deny für volle Allowlist-Durchsetzung. Mit dem Standard-audit-Verdikt werden nicht gematchte Aufrufe erlaubt und geloggt, aber nicht blockiert — nützlich beim Rollout, aber für sich allein keine Sicherheitskontrolle.

Glob-Muster ermöglichen es Ihnen, ganze Tool-Familien mit einer Regel zu erlauben. Die häufigen Muster:

Muster	Was es abdeckt
`crm.*`	Alle Tools im `crm`-Namespace
`*.read`	Jedes Read-Verb-Tool über alle Server
`db.query`	Genau dieses eine Tool
`*`	Alles (für Ihren Catch-All-Deny verwenden)

Tool-Matching ist First-Match-Wins in aufsteigender Prioritätsreihenfolge. Setzen Sie Ihre spezifischen allow-Regeln bei niedrigen Prioritätsnummern und den Catch-All-deny bei einer hohen.

2. Argument-Validierung: das Tool erlauben, den gefährlichen Aufruf blockieren

Eine Allowlist auf Tool-Namen ist grob — sie blockiert shell.exec vollständig. Manchmal möchten Sie ein Tool erlauben, aber einschränken, wie es aufgerufen werden kann. Argument-Klauseln ermöglichen es Ihnen, auf spezifische Felder innerhalb der Tool-Call-Argumente zu matchen, mit JSONPath und einem Satz von Operatoren. Beispiel: shell.exec erlauben, aber rm -rf blockieren

{
  "priority": 10,
  "label": "block destructive rm",
  "tool_name_glob": "shell.exec",
  "args_match": {
    "clauses": [
      {
        "path": "$.command",
        "op": "regex",
        "value": "rm\\s+-[^\\s]*r[^\\s]*f|mkfs|dd\\s+if=|:\\(\\)\\{.*\\}"
      }
    ]
  },
  "verdict": "deny"
}

Diese Regel löst nur aus, wenn shell.exec aufgerufen wird und das $.command-Argument dem destruktiven Befehls-Regex matcht. Ein normaler shell.exec-Aufruf mit einem sicheren Befehl fällt zur nächsten Regel durch (oder zum Standard-Verdikt). Setzen Sie diese Regel bei einer niedrigeren Prioritätsnummer als jede allgemeine allow shell.exec-Regel, damit sie zuerst auslöst. Der vollständige Satz von Argument-Operatoren:

Operator	Verwenden wenn
`eq`	Exakter Match auf einem skalaren Wert (String oder Zahl)
`contains`	Substring-Match — z. B. `$.query` `contains` `DROP TABLE`
`regex`	RE2-Muster-Match — sicher auf dem Hot-Path, kein Backtracking
`in`	Wert muss in einem gegebenen Array sein — z. B. nur bestimmte Umgebungen erlauben
`cidr_match`	IP-Adresse in einem CIDR-Block — nützlich für Egress-Zielprüfungen
`gt` / `lt`	Numerischer Vergleich — z. B. `$.amount` `gt` `10000` für Zahlungslimits

Alle Klauseln in einem args_match-Block werden mit AND verknüpft. Wenn ein Pfad in den Argumenten des Aufrufs nicht existiert, wertet die Klausel zu false aus und die Regel löst nicht aus — der Aufruf fällt zur nächsten Regel oder dem Default durch. Zahlungsschutz-Beispiel — jeden Zahlungs-Tool-Call mit einem Betrag über einem Schwellenwert verweigern:

{
  "priority": 5,
  "label": "cap payment amount",
  "tool_name_glob": "payment.*",
  "args_match": {
    "clauses": [
      { "path": "$.amount_cents", "op": "gt", "value": 100000 }
    ]
  },
  "verdict": "deny"
}

3. Human-in-the-Loop: hochriskante Aufrufe zur Freigabe zurückhalten

Für Tools, die genuinely notwendig, aber hochriskant sind — einen Deployment auslösen, eine Rückerstattung genehmigen, eine Massen-E-Mail senden — können Sie eine menschliche Genehmigung verlangen, bevor der Aufruf durchgeführt wird. Das pending_approval-Verdikt hält den Aufruf zurück und gibt eine firewall_approval_pending-Antwort an den Agenten zurück:

{
  "priority": 20,
  "label": "hold deployment calls for review",
  "tool_name_glob": "deploy.*",
  "verdict": "pending_approval"
}

Der Agent (oder Ihr Framework) pollt die Approval-ID. Ein Prüfer genehmigt oder lehnt von der Konsole oder über einen Webhook-Callback ab. Wenn genehmigt, reicht der Agent den ursprünglichen Aufruf mit dem einmal nutzbaren Approval-Token erneut ein, und das Gateway lässt ihn einmalig durch. pending_approval ist mit Argument-Klauseln kompatibel — Sie können nur die Aufrufe zurückhalten, die einen Schwellenwert matchen, und routinemäßige durchlassen:

[
  {
    "priority": 10,
    "label": "hold large deploys",
    "tool_name_glob": "deploy.release",
    "args_match": {
      "clauses": [
        { "path": "$.environment", "op": "eq", "value": "production" }
      ]
    },
    "verdict": "pending_approval"
  },
  {
    "priority": 20,
    "label": "allow staging deploys",
    "tool_name_glob": "deploy.*",
    "verdict": "allow"
  }
]

4. Wie ein blockierter Aufruf aussieht

Ein verweigerter Aufruf auf der Inbound-Surface (Tool in der Anfrage angeboten) gibt HTTP 400 mit dem Fehlercode firewall_blocked zurück. Die Antwort enthält strukturierte metadata — das gematchte Regel-Label, den Reason-Code und Risikofaktoren — und ist als skip-retry markiert, sodass eine Schleife nicht denselben verweigerten Aufruf hämmern kann. Ein Aufruf, der auf der Response-Surface blockiert wird (das Modell hat bereits tool_calls emittiert), gibt einen Tool-Fehler zurück, der für das Modell sichtbar ist, damit es reagieren kann — ein anderes Tool wählen, den Benutzer fragen oder stoppen — anstatt abzustürzen.

5. First-Match-Wins-Reihenfolge

Die Prioritätsreihenfolge ist wichtig. Die Engine geht Regeln in aufsteigender Prioritätsreihenfolge durch und stoppt beim ersten Match. Ein häufiges Muster:

Priorität	Regel	Verdikt
5	`shell.exec` + destruktiver Regex	`deny`
10	`shell.*` (allgemein)	`allow`
20	`crm.*`	`allow`
9999	`*` (Catch-All)	`deny`

Priorität 5 löst vor Priorität 10 aus — also wird shell.exec mit einem destruktiven Befehl verweigert, obwohl es ein allgemeines allow für shell.* gibt. Ohne den Deny bei niedriger Priorität würde die allow shell.*-Regel zuerst gewinnen.

6. Sicher mit Shadow-Mode ausrollen

Bevor Sie eine neue Policy auf Durchsetzung umstellen, schalten Sie den Shadow-Mode ein. Die Policy wertet jeden Tool-Call aus und loggt das Verdikt exakt wie in Produktion, aber jedes durchsetzende Verdikt (deny, pending_approval, sanitize) wird auf audit herabgestuft — nichts wird blockiert. Der Grund im Event-Log wird mit [shadow] would deny vorangestellt, damit Sie den Einfluss in den Events- und Runs-Ansichten messen können. Sobald Sie bestätigt haben, dass die Policy auf das auslöst, was Sie erwarten — und nichts, was Sie nicht beabsichtigt haben — schalten Sie den Shadow-Mode aus. Der nächste Aufruf wird durchgesetzt.

Das tight-Autonomie-Level wendet das block_destructive_shell-Preset automatisch an. Wenn Sie schnell eine Haltung wollen, ohne Regeln zu schreiben, wenden Sie tight von der Konsole an und es liefert eine Deny-Policy für destruktive Shell-Aufrufe in einem Schritt. Sie können dann Ihre eigenen Allowlist-Regeln darüber schichten. Siehe Autonomie-Level.

7. Verwandte Bedrohungen

Agenten-Tool-Missbrauch kommt selten isoliert vor. Ein nicht autorisierter Tool-Call ist oft die Konsequenz eines anderen Angriffsvektors:

Prompt-Injection — ein Angreifer bettet Anweisungen in abgerufene Inhalte ein, die den Agenten auf Tools lenken, die er nie aufrufen sollte.
Übermäßige Handlungsmacht — dem Agenten wurde mehr Tool-Zugang gewährt, als seine Aufgabe erfordert, was jede Injection oder Fehlkonfiguration sofort gefährlich macht.
Das Bedrohungsmodell — wie Tool-Missbrauch in die vollständige Angriffsfläche für agentische Systeme passt.

Die Agent-Firewall ist die Durchsetzungsebene; das Least-Privilege-Prinzip (enge Tool-Allowlists, Scoped Keys) ist die Designhaltung, die sie wirksam macht.

Firewall-Regeln-Referenz

Die vollständige Matching-Sprache — Tool-Globs, Argument-Klauseln, alle Operatoren, Verdikte und die API.

Firewall-Übersicht

Policies, Surfaces, Autonomie-Level, HITL-Freigabe und Observability.

​1. Allowlisting: alles verweigern, was Sie nicht explizit erlaubt haben

​2. Argument-Validierung: das Tool erlauben, den gefährlichen Aufruf blockieren

​3. Human-in-the-Loop: hochriskante Aufrufe zur Freigabe zurückhalten

​4. Wie ein blockierter Aufruf aussieht

​5. First-Match-Wins-Reihenfolge

​6. Sicher mit Shadow-Mode ausrollen

​7. Verwandte Bedrohungen

Firewall-Regeln-Referenz

Firewall-Übersicht

1. Allowlisting: alles verweigern, was Sie nicht explizit erlaubt haben

2. Argument-Validierung: das Tool erlauben, den gefährlichen Aufruf blockieren

3. Human-in-the-Loop: hochriskante Aufrufe zur Freigabe zurückhalten

4. Wie ein blockierter Aufruf aussieht

5. First-Match-Wins-Reihenfolge

6. Sicher mit Shadow-Mode ausrollen

7. Verwandte Bedrohungen