Zum Hauptinhalt springen
Wenn zwei Regeln beide denselben Tool-Call matchen könnten, entscheidet die Firewall-Regel-Priorität, welche gewinnt. Eine Firewall-Policy ist eine geordnete Liste von Regeln — die Engine durchläuft sie in Prioritätsreihenfolge, stoppt bei der ersten, die matcht, und wendet ihr Verdikt an. Bringen Sie die Reihenfolge richtig, und eine breite Wache plus eine enge Ausnahme koexistieren sauber; bringen Sie sie falsch, und die breite Regel verschlingt die Ausnahme, die Sie herausschnitzen wollten. Diese Seite ist die fokussierte Referenz für die Ordnung. Für die vollständige Regelgrammatik siehe Firewall-Regeln; für die Verdikte, die eine Regel erzeugen kann, siehe Verdikte.

​
1. Die Reihenfolge: Priorität aufsteigend, erster Treffer gewinnt

Innerhalb einer Policy werden Regeln in priority ASC, id ASC-Reihenfolge ausgewertet:
  1. Niedrigere priority läuft zuerst. Eine Regel mit priority: 0 wird vor einer mit priority: 10 geprüft. Denken Sie daran als Warteschlangenposition, nicht als Stärkewert — die kleinere Zahl bekommt das erste Wort.
  2. Gleichstände werden über die Regel-ID gebrochen. Zwei Regeln auf derselben priority laufen in Erstellungsreihenfolge (aufsteigende Regel-ID), sodass die ältere Regel den Gleichstand gewinnt. Verwenden Sie distinkte Prioritäten, wenn die Reihenfolge tatsächlich zählt, statt sich auf den ID-Gleichstandsbrecher zu verlassen.
  3. Erster Treffer gewinnt. Die Engine stoppt bei der ersten Regel, deren Bedingungen alle halten, und wendet ihr Verdikt an. Weiter unten in der Liste stehende Regeln werden für diesen Aufruf nie konsultiert.
  4. Kein Treffer → das Default-Verdikt. Wenn nichts matcht, gilt das default_verdict der Policy — audit, sofern Sie es nicht geändert haben.
Eine Regel matcht nur, wenn jede deklarierte Bedingung zugleich hält: die Surface, das Tool-Namen-Glob, das optionale Skill-Glob, die optionalen Argument-Klauseln und der Egress-Scope (nur Egress-Regeln). Ein partieller Treffer ist kein Treffer, und die Auswertung rückt zur nächsten Regel vor.

​
2. Ein konkretes Beispiel: spezifisch vor breit

Die kanonische Ordnungsaufgabe ist, ein enges Allow ein breites Deny überleben zu lassen. Setzen Sie die spezifische Regel auf eine niedrigere Priorität, sodass sie zuerst erreicht wird: 
// Rule A — priority 10: trust this one exact tool.
{ "label": "allow safe shell", "priority": 10,
  "tool_name_glob": "shell.echo", "verdict": "allow" }

// Rule B — priority 20: block the rest of the shell family.
{ "label": "block shell family", "priority": 20,
  "tool_name_glob": "shell.*", "verdict": "deny" }
Ein Aufruf von shell.echo trifft zuerst Regel A (Priorität 10), matcht und wird erlaubt — die Engine erreicht Regel B nie. Ein Aufruf von shell.exec fällt durch A (das Glob matcht nicht), trifft Regel B und wird verweigert. Kippen Sie die Prioritäten, und das breite shell.*-Deny auf Priorität 10 würde shell.echo zuerst abfangen, und Ihr Allow auf Priorität 20 wäre toter Code. Die Faustregel: am spezifischsten zuerst, am breitesten zuletzt.
Verlassen Sie sich dafür nicht auf den ID-Gleichstandsbrecher. Wenn das Allow und das Deny dieselbe priority teilen, ist der Gewinner, welche Regel Sie zuerst erstellt haben — eine fragile Ordnung, die still umkippt, wenn Sie eine Regel löschen und neu erstellen. Geben Sie der spezifischen Regel eine niedrigere priority, und die Absicht ist explizit.

​
3. Reihenfolge verifizieren, bevor Sie sich darauf verlassen

Über Priorität auf Papier nachzudenken ist fehleranfällig, sobald eine Policy mehr als eine Handvoll Regeln hat. Die Test-Sandbox läuft die echte Engine gegen einen Beispiel-Tool-Call und sagt Ihnen nicht nur das Verdikt, sondern welche Regel gewann — sodass Sie bestätigen können, dass die erwartete Regel tatsächlich feuerte:
1

Den Test-Tab der Policy öffnen

Öffnen Sie in der Konsole die Policy und wechseln Sie zu Test (Developer+).
2

Einen Beispielaufruf einreichen

Geben Sie einen Tool-Namen (und Argumente, wenn Ihre Regeln sie inspizieren) ein und führen Sie ihn aus. Nichts wird dispatcht und nichts persistiert — es ist ein Dry-Run.
3

Die gematchte Regel lesen

Das Ergebnis benennt das Verdikt, die gematchte Regel (per Label/ID) und den Grund. Wenn eine breite Regel gewann, wo Sie eine enge erwarteten, senken Sie die priority der engen Regel und testen erneut.
Siehe Regeln testen für die volle Sandbox und Policies verwalten für das In-Place-Bearbeiten der Regelreihenfolge.

​
4. Skill-Enforcement reitet obendrauf

Regel-Priorität entscheidet das Verdikt der gewinnenden Regel — aber das ist nicht immer die endgültige Antwort. Wenn der Tool-Call einem gesteuerten Skill gehört, wird der Enforcement-Mode des Skills obendrauf auf das gewinnende Verdikt angewendet, nach der Erster-Treffer-Auflösung:
Skill-ModeEffekt auf das gewinnende Verdikt
allowKeine Änderung — das Regel-Verdikt steht.
quarantineEskaliert alles unterhalb von deny zu pending_approval; ein bestehendes Deny bleibt wie es ist.
blockErzwingt ein deny unabhängig vom Regel-Verdikt.
So kann ein quarantine-Skill das allow einer Regel in einen zurückgehaltenen Aufruf verwandeln, und ein block-Skill verweigert einen Aufruf selbst dann, wenn keine Regel seine Tools benennt. Quarantäne eskaliert nur — sie stuft ein Deny nie zu etwas Sanfterem herab. Deshalb bleibt ein als riskant auto-detektierter Skill quarantäniert, bis Sie ihn prüfen, egal wie permissiv Ihre Regeln sind.
Skill-Mode ist keine Regel, daher hat er keine priority und Sie können ihn nicht relativ zu Ihren Regeln neu ordnen. Er wertet immer nach dem gewählten gewinnenden Verdikt aus. Wenn der Mode eines gesteuerten Skills Aufrufe blockiert, die Sie erlaubt erwarteten, fixen Sie es auf dem Skill, nicht durch Hinzufügen einer höher-priorisierten Allow-Regel — die Regel kann den Mode nicht überschreiben.

​
5. Dinge, die nicht Erster-Treffer reiten

Ein paar Mechanismen sitzen außerhalb des Pro-Regel-Prioritätsdurchlaufs — wissen Sie, wo sie landen, sodass Sie nicht versuchen, sie zu ordnen:
Eine cap_cost-Regel unter ihrer Obergrenze wird als nicht-matchend behandelt, sodass die Auswertung zur nächsten Regel fortfährt, statt sie als Grant per Erster-Treffer gewinnen zu lassen. Über der Obergrenze löst sie auf ein deny auf. Sie kurzschließt nie eine niedriger-priorisierte Regel, nur weil sie erreicht wird.
Eine Sequenzregel matcht eine Kette von Aufrufen über ein Zeitfenster, sodass sie reaktiv von einem asynchronen Matcher durchgesetzt wird statt auf dem einzelnen Aufruf, der die Kette abschließt. Sie leuchtet den Events-Feed auf, gewinnt aber nicht den Erster-Treffer-Durchlauf für einen einzelnen Aufruf.
Shadow-Mode ändert nicht, welche Regel gewinnt — er stuft das gewinnende durchsetzende Verdikt auf audit herab (Grund mit Präfix [shadow] would …) nach der Erster-Treffer-Auflösung, sodass Sie die Wirkung einer Policy messen können, bevor sie den Traffic ändert.

​
6. Alles zusammensetzen

Für jeden Tool-Call ist die volle Auflösung:
  1. Die Policy auflösen — die an den aufrufenden Key angehängte, oder der Workspace-Default. Siehe Scope.
  2. Regeln in priority ASC, id ASC durchlaufen — erster Treffer gewinnt; kein Treffer → default_verdict.
  3. Skill-Enforcement anwenden — der Mode eines gesteuerten Skills reitet obendrauf auf dem gewinnenden Verdikt (block erzwingt deny, quarantine eskaliert).
  4. Shadow-Mode anwenden — wenn an, durchsetzende Verdikte auf audit herabstufen.
  5. Das Event aufzeichnen — Verdikt, Surface, Tool und gematchte Regel landen im Events-Feed.
Das Bearbeiten der Priorität einer Regel wird beim nächsten Aufruf für jeden an die Policy angehängten Key wirksam — kein Redeploy, keine Änderung im Agenten-Code. Führen Sie die Test-Sandbox nach dem Neu-Ordnen erneut aus, um den neuen Gewinner zu bestätigen, bevor Live-Traffic davon abhängt.

​
Wohin als Nächstes

Verdikte

Was jedes gewinnende Verdikt tatsächlich tut.

Glob-Syntax

Wie Tool-Namen-Matching entscheidet, ob eine Regel überhaupt ein Kandidat ist.

Regeln testen

Eine Policy dry-runnen und sehen, welche Regel gewinnt.

Tool-Allow-Listing

Das Default-Deny-Muster, das sich am stärksten auf Ordnung stützt.
Für die Matching-Sprache hinter einer Regel siehe die vollständige Firewall-Regeln-Referenz; dafür, wie Skills obendrauf schichten, siehe Firewall-Skills und Enforcement-Modi.