Firewall: Skills - OrcaRouter

Moderne Agenten installieren Fähigkeiten im Handumdrehen: einen Skill aus einer Registry, einen Community-MCP-Server, ein Plugin aus einer URL. Jede davon liefert ein Manifest, einen Satz von Tools und einen Satz angeforderter Berechtigungen — und jede ist ein Supply-Chain-Risiko in dem Moment, in dem ein Agent sie lädt. Ein Skill, der leise nach shell.exec und einem externen Netzwerk-Scope fragt, ist genau die Art von Sache, die bevor sie läuft geprüft werden sollte, nicht in einem Vorfall entdeckt. Die Skills-Governance der Firewall ist diese Prüfung. Jede installierbare Fähigkeit wird als workspace-bezogener Datensatz registriert, von einer deterministischen Risiko-Engine gescannt, einem Risikoband und einem Enforcement-Mode zugewiesen und — zur Laufzeit — reitet dieser Mode auf den Regel-Verdikten der Firewall obendrauf.

1. Was ein „Skill” hier ist

Ein Skill-Datensatz ist eine installierbare Agenten-Fähigkeit. Ein einziges Modell verallgemeinert drei Arten, sodass eine Scan-, Score- und Approval-Ebene alles steuert, was ein Agent selbst installiert:

Art	Was es ist
`skill`	Eine gepackte Fähigkeit — ein Manifest plus einen Satz von Tools und ein System-Prompt-Fragment.
`mcp_server`	Ein Bring-your-own-MCP-Server, registriert als gesteuertes Artefakt.
`plugin`	Eine Plugin-artige Erweiterung.

Jeder Datensatz hat außerdem eine Source — builtin, registry, private, byo_mcp oder auto_detected — die in die Vertrauensbewertung einfließt.

2. Der Scanner

Bei der Registrierung (und auf Abruf) führt der Scanner einen Satz deterministischer, abhängigkeitsfreier Durchläufe über das Manifest und die deklarierten Scopes aus. Jeder Durchlauf emittiert Findings mit einer Severity von info, warn oder error:

Durchlauf	Flaggt	Severity
prompt_injection	Manifest-Text, der versucht, Anweisungen zu überschreiben (`ignore previous instructions`, `you are now`, ein führendes `system:`…).	warn
tool_creep	Tool-Namen, die das Manifest nutzt, aber nicht in `allowed_tools` deklariert hat.	error
network_egress	HTTP(S)-Hosts im Manifest, die nicht in den Netzwerk-Scopes des Skills genehmigt sind.	warn
fs_write_unsafe	Ein Filesystem-Scope im Write-Mode auf einem Pfad außerhalb von `/tmp` (traversal-sicher).	error
data_scope	Sensible Daten-Scopes (`pii`, `financial`, `customer`).	info
unsigned	Ein `registry`-Skill ohne Signatur.	warn

Die Findings rollen sich zu einem Scan-Verdikt auf: jedes error → blocked; andernfalls jedes warn → flagged; andernfalls clean.

3. Risiko-Score & Bänder

Dieselben Findings speisen einen deterministischen Risiko-Score (0–100, additiv mit Obergrenzen pro Kategorie). Die schwersten Beitragenden sind gefährliche Fähigkeiten:

Fähigkeit	Gewicht
Shell-Ausführung	+30
Beliebige Code-Eval	+30
Filesystem-Write außerhalb von `/tmp`	+25
Secrets-Read	+25
Externer Netzwerk-Egress	+20

Tool-Creep-, Prompt-Injection-, Egress- und Data-Scope-Findings kommen obendrauf (jeweils gedeckelt), ein unsignierter Registry-Skill fügt +15 hinzu, und Mitigationen subtrahieren — ein signierter Skill ist −10, ein Manifest ohne Error-Findings −5. Der Score wird auf ein Band abgebildet:

Band	Score
`low`	0–25
`medium`	26–50
`high`	51–75
`critical`	76–100

Diese Gewichte sind durch einen Drift-Guard-Test fixiert — sie bewegen sich nicht ohne eine bewusste Spec-Änderung, sodass ein Band über jeden Workspace hinweg dasselbe bedeutet.

4. Enforcement-Mode

Band und Verdikt zusammen leiten einen Enforcement-Mode ab — was die Firewall tatsächlich tut, wenn ein Tool, das diesem Skill gehört, aufgerufen wird:

Mode	Effekt zur Laufzeit
`allow`	Der Skill erlegt nichts Eigenes auf; die Regel-Verdikte entscheiden.
`quarantine`	Alles unterhalb eines deny zu `pending_approval` eskalieren — die Tools des Skills laufen erst, nachdem ein Mensch genehmigt.
`block`	Ein `deny` auf die Tools des Skills erzwingen.

Die Ableitung nimmt das strengere von zwei Signalen: das Band (low/medium → allow, high → quarantine, critical → block) und das Scan-Verdikt (blocked → block, flagged → quarantine). Ein einzelnes error-Finding, das das Verdikt blocked macht, wird quarantänieren-oder-blockieren, selbst wenn das numerische Band low ist — die vorsichtige Richtung. Ein Operator kann den Mode explizit setzen; bei einem Re-Scan rastet der Mode immer nur strenger ein, lockert nie ein block oder quarantine, das Sie gesetzt haben.

5. Vertrauenssignale

Zwei Signale jenseits des statischen Scans bestimmen mit, wie ein Skill behandelt wird:

Signierte Publisher. Ein Skill, der eine Signatur von einem vertrauenswürdigen Publisher trägt, wird als vertrauenswürdiger behandelt (die Signing-Mitigation senkt seinen Risiko-Score); ein unsignierter Registry-Skill wird bestraft. Sie verwalten, welchen Publishern Ihr Workspace vertraut.
Ressourcen-Reputation. Die Stellung eines Skills kann durch sein Live-Verhalten über die Zeit angepasst werden — Denials und Anomalien erhöhen sein Risiko, saubere Serien senken es — sodass ein Artefakt, das in Produktion fehlt sich verhält, in Richtung quarantine driftet, selbst wenn sein Manifest sauber gescannt wurde.

6. Auto-detektierte Fähigkeiten

Der Scanner läuft nicht nur, wenn Sie etwas von Hand registrieren. Wenn ein Agent eine Fähigkeit selbst installiert und ihre Tools zum ersten Mal das Gateway überqueren, auto-detektiert die Firewall sie (abseits des heißen Pfads, asynchron), synthetisiert ein Manifest aus dem, was sie beobachtet hat, und führt dieselbe Scan-, Score- und Mode-Ableitung aus — mit source = auto_detected.

Auto-detektierte Fähigkeiten werden quarantäniert, bis sie geprüft sind. Alles Auto-detektierte, das andernfalls zu allow aufgelöst würde, wird auf quarantine heruntergesetzt (und critical bleibt block), bis ein Mensch es prüft. Eine Fähigkeit, die niemand genehmigt hat, bekommt keinen Freifahrtschein nur weil sie harmlos gescannt wurde — sie läuft erst, nachdem Sie sie angeschaut haben.

7. Runtime-Enforcement

Wenn ein Tool-Call die Firewall-Engine erreicht, wird er einem besitzenden Skill zugeordnet, dann wird der Mode des Skills auf das Regel-Verdikt obendrauf angewendet:

Attribution. Der Aufruf wird einem Skill über seine deklarierten allowed_tools zugeordnet, dann über das mcp_server-Namespace-Präfix, dann über ein workspace-weites restriktivstes durchsetzendes Fallback.
Regel-Verdikt. Die Regeln der Policy laufen wie üblich — und der skill_name_glob einer Regel lässt Sie eine Regel auf bestimmte Skills scopen.
Mode-Override. Ein block-Skill erzwingt ein deny; ein quarantine-Skill eskaliert alles unterhalb von deny zu pending_approval; allow lässt das Verdikt unangetastet.

Skill-Attribution failt closed. Wenn ein Tool nicht zugeordnet werden kann (ein DB-Fehler ohne Cache oder ein undeklariertes Tool unter einer kuratierten Source), wird der Aufruf zur Prüfung zurückgehalten statt erlaubt. Und der Skill-Mode ist unabhängig vom Shadow-Mode — ein quarantänierter oder blockierter Skill wird weiterhin durchgesetzt, selbst während eine Policy im Shadow-Rollout ist.

8. Lebenszyklus

Register — POST /skills validiert und scannt synchron und gibt den Skill plus seine Findings und sein Verdikt zurück. Der Mode wird abgeleitet (oder Ihr expliziter Mode wird respektiert).
Update — scannt das neue Manifest neu; der Mode rastet bei einem verschlechterten Scan strenger ein, lockert aber nie Ihr gespeichertes block/quarantine.
Rescan — POST /skills/:id/rescan führt den Scan erneut aus; wenn das Verdikt neu zu flagged oder blocked degradiert, emittiert es ein Firewall-Event, sodass der Drift in Ihrem Feed auftaucht.
Delete — Soft-Delete und gibt den Name-Slot zur Neuregistrierung frei.

API-Referenz

Workspace-bezogen; Listen-Reads sind für jedes Mitglied offen (und redigieren secret-tragende Felder), alles andere erfordert Developer+.

Methode & Pfad	Rolle	Zweck
`GET /api/workspace/firewall/skills`	Member	Skills auflisten (redigiert; filter nach `?kind=` und `?source=`).
`GET /api/workspace/firewall/skills/:id`	Developer+	Vollständiger Skill-Datensatz.
`POST /api/workspace/firewall/skills`	Developer+	Registrieren + scannen (409 bei doppeltem Namen).
`PUT /api/workspace/firewall/skills/:id`	Developer+	Aktualisieren + neu scannen.
`POST /api/workspace/firewall/skills/:id/rescan`	Developer+	Neu scannen; emittiert bei Degradation ein Event.
`DELETE /api/workspace/firewall/skills/:id`	Developer+	Soft-Delete.

Ein Register/Update/Rescan gibt zurück:

{
  "skill": { "id": 7, "name": "creepy", "risk_band": "high", "mode": "quarantine", "...": "..." },
  "findings": [
    { "kind": "tool_creep", "target": "shell.exec", "severity": "error" }
  ],
  "scan_verdict": "blocked"
}

Namen sind pro Workspace artübergreifend eindeutig — ein skill namens github und ein mcp_server namens github kollidieren im selben Workspace. Wählen Sie distinkte Namen pro Artefakt.

FAQ

Wie unterscheidet sich das von der Regel-DSL?

Regeln gaten Tool-Calls nach Name und Argumenten. Skills gaten die Fähigkeiten, die ein Agent lädt — das Paket, sein Manifest und seine angeforderten Berechtigungen — bevor irgendeines seiner Tools läuft. Der Mode des Skills reitet dann auf allem obendrauf, was die Regeln entscheiden, sodass die beiden komponieren: Eine Regel kann http.fetch generell allowen, während ein quarantänierter Skill, der es besitzt, trotzdem zurückgehalten wird.

Was hindert einen bösartigen Skill daran, ein sauberes Manifest zu deklarieren?

Mehrere Dinge. Tool-Creep-Erkennung flaggt Tools, die genutzt, aber nicht deklariert sind; die Auto-Detektion scannt neu aus dem, was tatsächlich das Gateway überquert hat, nicht nur aus dem behaupteten Manifest; der Mode rastet bei einem Re-Scan strenger ein (nicht lockerer); Ressourcen-Reputation driftet ein fehlverhaltendes Artefakt über die Zeit in Richtung quarantine; und die Attribution failt closed, wenn ein Tool nicht an einen deklarierten Skill gebunden werden kann.

Muss ich jeden Skill manuell registrieren?

Nein. Registrieren Sie die, die Sie vorab genehmigen wollen; der Rest wird bei der ersten Nutzung auto-detektiert und quarantäniert, bis Sie ihn prüfen. Schalten Sie den Observe-Mode ein, um alles, was ein Agent installiert, ohne Blockieren ans Licht zu bringen, und ziehen Sie dann aus echten Daten an.

Siehe auch

Sie möchten tiefer in die Agentensicherheit einsteigen? Die Leitfäden Secure Your Agents (Zero Trust) ordnen dieses Feature in einen Zero-Trust-Workflow ein.

Secure-Agents-Baseline

Wenden Sie mit einem Schalter eine Zero-Trust-Haltung auf jede Agentenfähigkeit an.

Agentische Guardrails

Guardrails, gebaut für autonome, tool-nutzende Agenten.

​1. Was ein „Skill” hier ist

​2. Der Scanner

​3. Risiko-Score & Bänder

​4. Enforcement-Mode

​5. Vertrauenssignale

​6. Auto-detektierte Fähigkeiten

​7. Runtime-Enforcement

​8. Lebenszyklus

​API-Referenz

​FAQ

​Siehe auch

Secure-Agents-Baseline

Agentische Guardrails

1. Was ein „Skill” hier ist

2. Der Scanner

3. Risiko-Score & Bänder

4. Enforcement-Mode

5. Vertrauenssignale

6. Auto-detektierte Fähigkeiten

7. Runtime-Enforcement

8. Lebenszyklus

API-Referenz

FAQ

Siehe auch