Allowlist vs Blocklist für KI-Agenten: Warum Default-Deny sicherer ist

Idee in 30 Sekunden

Allowlist im Runtime legt fest, welche Tools der Agent aufrufen darf. Blocklist verbietet nur einen Teil der Tools aus einer bereits großen Menge.

Wann das nötig ist: wenn ein Agent Zugriff auf echte APIs, Write-Aktionen hat oder in Production regelmäßig neue Tools bekommt.

Problem

Viele Teams starten mit einer Blocklist: „Wir verbieten gefährliche Tools.“ Am Anfang wirkt das schnell und bequem. In Production bricht dieses Modell aber schnell.

Der Grund ist einfach: Jedes neue Tool wird automatisch verfügbar, wenn es nicht explizit blockiert wird. Der Zugriff wächst also per Default und nicht durch eine explizite Entscheidung.

Analogie: Das ist wie ein Büro ohne Liste erlaubter Türen, aber mit einer Liste „hier nicht reingehen“. Sobald ein neuer Raum auftaucht, ist er für alle offen, bis jemand daran denkt, ihn zu sperren.

Lösung

Die Lösung: Im Policy Layer default deny setzen und Tools nur über eine Allowlist erlauben. Die Blocklist bleibt als zusätzliche Notbremse für den Incident Mode, nicht als primäres Zugriffsmodell.

Der Policy Layer gibt für jeden Aufruf eine technische Entscheidung zurück: allow, deny oder approval_required. Diese Entscheidung wird bei jedem Schritt getroffen, nicht nur am Ende eines Runs. Das ist eine eigene Systemschicht und kein Teil des Prompts oder der Modelllogik.

Allowlist ≠ Blocklist

Das sind zwei unterschiedliche Kontrollansätze:

• Allowlist: Nur das, was explizit in der Policy steht, ist erlaubt.
• Blocklist: Alles ist erlaubt, außer dem, was explizit verboten ist.

Eins ohne das andere reicht nicht:

• ohne Allowlist erweitert sich der Zugriff über Releases fast unbemerkt
• ohne Blocklist ist es schwerer, ein konkretes Tool im Incident schnell abzuschalten

Beispiel:

• Allowlist: search.read, kb.read, refund.lookup
• Incident-Blocklist: browser.run temporär sperren wegen instabilem Vendor

Metriken für Tool-Zugriffskontrolle

Diese Metriken und Signale arbeiten bei jedem Agent-Schritt zusammen.

Wie das in der Architektur aussieht

Der Policy Layer (Tool Gateway) steht zwischen Runtime und Tools und ist die zentrale Zugriffskontrolle vor jedem Schritt. Jede Entscheidung (allow, deny, approval_required) wird im Audit Log erfasst.

Jeder Agent-Schritt läuft vor der Ausführung durch diesen Flow: Die Runtime führt eine Aktion nicht direkt aus, sondern erst nach Policy-Prüfung. Bei Write-Aktionen kann die Policy approval_required zurückgeben. Das ist ein separater Bestätigungs-Flow, der in diesem Diagramm nicht gezeigt wird (siehe Human approval).

Kurz zum Flow:

• Runtime erstellt den Tool-Call
• Policy Layer wendet default deny, danach Allowlist und Incident-Blocklist an
• allow -> Tool-Call wird ausgeführt
• deny -> Stop Reason wird zurückgegeben
• jede Entscheidung wird ins Audit Log geschrieben

In der Runtime wird deny in einen expliziten stop reason umgewandelt, der in Logs und Run-Response sichtbar ist.

Beispiel

Ein Support-Agent erhält eine Anfrage zum massenhaften Schließen von Tickets. Tool ticket.close_bulk ist nicht in der Allowlist, daher wird der Aufruf sofort blockiert.

Während eines separaten Incidents fügt das Team browser.run zur Incident-Blocklist hinzu. Auch wenn dieses Tool in der Allowlist steht, liefert der Policy Layer temporär deny("incident_deny").

Die Allowlist begrenzt den Basiszugriff, die Blocklist liefert schnelle Notfallkontrolle.

Im Code sieht das so aus

Im vereinfachten Schema oben sieht man den Haupt-Control-Flow. In der Praxis läuft die Prüfung zentral im Policy Layer vor jedem Schritt.

Beispiel für eine Allowlist-Konfiguration:

policy:
  default: deny
  allowlist:
    - search.read
    - kb.read
    - refund.lookup
incident_blocklist:
  - browser.run

decision = policy.evaluate(tool, user_context, mode="normal")

if decision.outcome == "approval_required":
    if not approval.ok():
        audit.log(run_id, decision.outcome, reason=decision.reason, tool=tool)
        return stop(decision.reason)
    else:
        audit.log(run_id, "approval_granted", reason="human_approved", tool=tool)

elif decision.outcome == "deny":
    audit.log(run_id, decision.outcome, reason=decision.reason, tool=tool)
    alerts.notify_if_needed(run_id, decision.reason, tool=tool)
    return deny(decision.reason)

result = tool.execute(args)
decision = Decision.allow(reason="policy_ok")
audit.log(run_id, decision.outcome, reason=decision.reason, tool=tool, result=result.status)
return result

So sieht es während der Ausführung aus

Szenario 1: Tool nicht in der Allowlist (deny)

1. Runtime erstellt einen Aufruf für ticket.close_bulk.
2. Policy Layer prüft die Allowlist.
3. Entscheidung: deny (tool_not_allowed).
4. Audit: decision=deny, tool=ticket.close_bulk, reason=tool_not_allowed.
5. Aktion wird nicht ausgeführt.

---

Szenario 2: Incident-Block (incident_deny)

1. Runtime erstellt einen Aufruf für browser.run.
2. Das Tool ist in der Allowlist, aber Incident Mode ist aktiv.
3. Policy Layer prüft die Blocklist und gibt deny (incident_deny) zurück.
4. Audit: decision=deny, tool=browser.run, reason=incident_deny.
5. Run wird ohne Tool-Aufruf gestoppt.

---

Szenario 3: Erlaubter Aufruf (allow)

1. Runtime erstellt einen Aufruf für kb.read.
2. Policy Layer prüft die Regeln: allow.
3. Tool wird ausgeführt.
4. Audit: decision=allow, tool=kb.read, result=ok.
5. Ergebnis wird an die Runtime zurückgegeben.

Typische Fehler

• Blocklist als primäres Zugriffsmodell verwenden
• default deny für neue Tools nicht nutzen
• Wildcards wie * ohne enge Grenzen erlauben
• „universelle“ Tools wie workflow.run_anything behalten
• nur allow loggen, aber deny/approval_required nicht loggen
• Zugriff im Prompt oder UI prüfen statt im Policy Layer

Ergebnis: Der Zugriff wirkt kontrolliert, wächst aber real mit jedem Release.

Selbstcheck

Schneller Allowlist-Policy-Check vor dem Production-Rollout:

FAQ

Q: Kann man Production nur mit Blocklist betreiben?
A: Für Production nein. Blocklist ist als Notfallmechanismus nützlich, das Basismodell sollte aber default deny + allowlist sein.

Q: Womit startet man bei der Allowlist?
A: Starte mit einem minimalen read-only Tool-Set. Write-Aktionen separat hinzufügen, mit expliziten Bedingungen und Approval.

Q: Ist eine Wildcard-Allowlist (crm.*) okay?
A: Nur in engen Fällen und mit regelmäßigem Review. Sonst wird Wildcard schnell zu verstecktem Default-Allow. Zum Beispiel erlaubt crm.* auch crm.delete_all_contacts, wenn dieses Tool im nächsten Release erscheint.

Q: Wo sollten diese Prüfungen implementiert werden?
A: Im zentralen Policy Layer (Tool Gateway), nicht im Prompt und nicht in UI-Logik.

Q: Was tun, wenn ein Tool dringend abgeschaltet werden muss?
A: In die Incident-Blocklist aufnehmen, Grund im Audit Log festhalten und danach zur permanenten Allowlist-Policy zurückkehren.

Wo das im Gesamtsystem passt

Allowlist/Blocklist ist eine Ebene von Agent Governance. Zusammen mit RBAC, Budgets, Approval und Audit bildet sie ein einheitliches System zur Ausführungskontrolle.

Verwandte Seiten

Als Nächstes zum Thema:

• Agent Governance Überblick — Gesamtmodell für Agent-Kontrolle in Production.
• Zugriffskontrolle (RBAC) — wie Rollen, Permissions und Tenant Scope kombiniert werden.
• Budget Controls — wie Run-Kosten auf Runtime-Ebene begrenzt werden.
• Human approval — wie Bestätigungen für riskante Aktionen hinzugefügt werden.
• Audit Logs für Agenten — wie Policy-Entscheidungen in Incidents analysiert werden.