Zum Hauptinhalt springen
Wenn ein Agent quer über ein Dutzend MCP-Tools loslegt, ist die Frage, die im Nachhinein zählt, nie „ist dieses eine Tool sicher” — es ist „was hat der Agent tatsächlich aufgerufen, was hat die Firewall entschieden, und welche Regel hat diesen Aufruf gemacht”. OrcaRouter beantwortet das von einem Ort: dem mcp-Audit-Log. Jeder tools/call, den das MCP-Gateway auf der mcp-Oberfläche auswertet, landet als Firewall-Event — Verdikt, Tool, gematchte Regel und der Agentenlauf, der ihn ausgestellt hat — sodass Sie eine Session live überwachen oder sie später rekonstruieren können. Diese Seite ist das fokussierte How-to zum Lesen dieses Trails. Für das Gateway selbst, das Verdikt-Vokabular und das Regel-DSL siehe Firewall und Firewall: MCP-Server.
Jeder Lesevorgang hier wird aus der Konsole konfiguriert (oder der REST-API mit Ihrer Session/Ihrem Access-Token — UserAuth) und ist rollengesteuert. Nur /v1/*-Relay-Aufrufe und die Firewall-Gateway-Routen tragen einen sk-orca-...-förmigen Key.

​
1. Was das mcp-Audit-Log aufzeichnet

Jeder MCP-Tool-Call erzeugt ein Firewall-Event auf der mcp-Oberfläche. Das Event trägt, was Sie brauchen, um „wer hat was aufgerufen, und was hat die Policy getan” zu beantworten — und nichts, was es nicht sollte (Tool-Argumente sind redigiert, siehe §4).
verdict (allow / audit / deny / sanitize / pending_approval / observe), surface (mcp hier), policy_name, rule_label und ein menschenlesbarer reason. Ein quarantine-Flag markiert einen Aufruf, der zurückgehalten wurde, weil der besitzende Skill im Quarantäne-Modus ist.
tool_name (namespaced <server>.<tool>), skill_name, wenn der Aufruf einem registrierten Skill zugeschrieben werden kann, model_name und token_name.
agent_run_id, conversation_id und request_id — die Keys, die Sie verwenden, um die Aufrufe einer Session zu gruppieren oder von einer Anfrage in jeden Aufruf zu bohren, den sie aufgefächert hat.
Ein gap-Flag markiert einen observe-Modus-Aufruf, den Ihre angehängte Policy gesehen, aber keiner Regel gematcht hat — das Signal, das die Discovered-Tools-Ansicht verwendet, um Tools an die Oberfläche zu bringen, die Ihre Policy noch nicht abdeckt.

​
2. Den Feed lesen

Der Events-Tab in der Konsole ist die primäre Ansicht. Um dieselben Daten programmatisch zu ziehen, listen Sie Events mit Ihrem Access-Token und filtern Sie auf die mcp-Oberfläche: 
# Console route (UserAuth). Reading events requires Developer+.
curl "https://api.orcarouter.ai/api/workspace/firewall/events?surface=mcp&verdict=deny,pending_approval" \
  -H "Authorization: Bearer <your-access-token>"
Der verdict-Filter akzeptiert einen einzelnen Wert oder einen kommagetrennten Satz (das „denies + holds”-Preset oben). Ein Beispiel-Event: 
{
  "created_at": 1700000000,
  "surface": "mcp",
  "tool_name": "github.create_issue",
  "verdict": "deny",
  "policy_name": "Coding agent",
  "rule_label": "no writes to prod org",
  "reason": "rule matched: no writes to prod org",
  "agent_run_id": "run_8f3a",
  "model_name": "claude-sonnet-4-5",
  "token_name": "ci-agent"
}
Um die vollständige Auffächerung einer Anfrage zu rekonstruieren — jedes Tool, das das Modell unter einer einzigen Relay-Anfrage aufgerufen hat — bohren Sie per Request-ID hinein: 
curl "https://api.orcarouter.ai/api/workspace/firewall/events/by-request/<request_id>" \
  -H "Authorization: Bearer <your-access-token>"
Für eine Rollup-Ansicht auf Session-Ebene statt roher Zeilen treffen Sie GET /api/workspace/firewall/events/aggregate?group_by=run (oder group_by=session) — eine Zeile pro Agentenlauf mit einer Aufschlüsselung pro Verdikt, distinkten Tools und First/Last-Seen. Die Trace-Endpunkte (/trace/runs, /trace/by-run) rekonstruieren den Aufruf-Baum des Laufs.

​
3. Server-Governance-Audit-Zeilen

Events pro Aufruf sagen Ihnen, was der Agent getan hat. Ein zweiter, kleinerer Trail sagt Ihnen, was Sie an der Governance eines Servers getan haben — und dort lebt die Rug-Pull-Geschichte. Wenn ein Probe feststellt, dass der beworbene Tool-Satz eines registrierten Servers gedriftet ist, und ein Admin ihn neu baselinier oder quarantänisiert, wird diese Entscheidung in das Workspace-Audit-Log geschrieben:
Audit-AktionGeschrieben, wenn
firewall_mcp_schema_changedEin Probe findet, dass der Live-Tool-Satz vom genehmigten gedriftet ist.
firewall_mcp_schema_approvedEin Admin baselinier auf den neuen Tool-Satz neu.
firewall_mcp_schema_quarantinedEin Admin quarantänisiert (und deaktiviert) einen gedrifteten Server.
Jede Zeile trägt die Server-ID, den Namen und die Tool-Anzahl — nie Tool-Argumente oder Credentials. Dies ist der forensische Trail hinter der Rug-Pull-Abwehr: ein Server, den Sie am Montag genehmigt haben, kann nicht still am Freitag ein shell.exec-Tool wachsen lassen, ohne hier eine Zeile zu hinterlassen.
Firewall-Policy-, Regel- und Einstellungs-Änderungen schreiben neben diesen ihre eigenen Audit-Zeilen. Wenn ein Plattform-Admin die Änderung macht, landet sie auch im zentralen Admin-Audit-Log (GET /api/admin/audit-logs, nur Admin); die Bearbeitung eines regulären Mitglieds bleibt im Workspace-Trail.

​
4. Argumente werden standardmäßig redigiert

Der Event-Stream ist so gebaut, dass er von Ihrem Team lesbar ist, ohne Secrets zu leaken. Tool-Call-Argumente werden nie wortwörtlich gespeichert — ein Event trägt höchstens eine gekappte, redigierte args_summary, und der rohe Argument-Hash, der für die Anomalie-Gruppierung verwendet wird, verlässt nie den Server.
Weil Events diesen sanitisierten Argument-Snapshot tragen, sind die events-, aggregate- und trace-Endpunkte Developer+ gated — ein Mitglied mit Viewer-Rolle kann Policies und entdeckte Tools lesen, aber nicht die Tool-Call-Provenienz eines anderen Mitglieds. Planen Sie Ihre Rollen entsprechend.

​
5. Live-Monitoring: Anomalien

Im Nachhinein zu lesen ist die eine Hälfte; die andere ist, während es passiert benachrichtigt zu werden. Der Anomalie-Feed beobachtet MCP (und jede andere Oberfläche) auf Verhalten, das von der gelernten Baseline des Workspaces abbricht — Raten- und Kosten-Spikes gegen ein Stunde-der-Woche-Profil, Retry-Loops und neuartige Tool-Pfade — und bringt sie an die Oberfläche, ohne dass Sie eine einzige Regel schreiben. 
# Anomaly feed is open to any Member.
curl "https://api.orcarouter.ai/api/workspace/firewall/anomalies?window=5m" \
  -H "Authorization: Bearer <your-access-token>"
Ein lautes Signal kann gesnoozt werden (bis zu 7 Tage), sodass es aufhört, den Feed zu überfüllen, ohne dauerhaft stillgelegt zu werden. Der Anomalie-Read ist Member-offen — breiter als der Event-Stream — weil er das Signal trägt, nicht die Argumente.
Paaren Sie den Feed mit dem Shadow-Modus: rollen Sie eine verschärfte Policy als audit-only aus, beobachten Sie die Beinahe-denies im Events-Stream (reason mit [shadow] would … präfixiert) und befördern Sie sie, sobald der Feed ruhig ist.

​
6. Aufbewahrung und Löschung

Firewall-Events laufen automatisch ab — sie sind kein permanenter Speicher, sie sind ein rollendes Monitoring-Fenster. Workspace-Audit-Zeilen (der Server-Governance-Trail in §3) werden bis zu 180 Tage aufbewahrt. Und wenn ein Nutzer gelöscht wird, kaskadiert der Grace-then-Scrub-Zyklus durch Firewall-Events und -Matches, sodass der Tool-Call-Trail eines ausgeschiedenen Nutzers nicht herumliegt.
Data-Residency- und Aufbewahrungs-Controls leben in der Compliance-Ebene. Das mcp-Audit-Log erbt die Aufbewahrungshaltung des Workspaces; Sie konfigurieren sie nicht pro Server.

​
7. Wohin als Nächstes

MCP-Sicherheitsübersicht

Die gesamte MCP-Governance-Oberfläche — Gateway, Verdikte, Skills, Egress.

Rug-Pull-Abwehr

Die Drift-Events in §3, von Ende zu Ende: erkennen, neu baselinieren, quarantänisieren.

MCP-Tools per Allow-List freigeben

Verwandeln Sie, was das Audit-Log zeigt, in eine Default-Deny-Policy.

Firewall: MCP-Server

Die vollständige Feld- und Routen-Referenz.
Neu beim Modell? Siehe Wie OrcaRouter prüft dafür, wo Events im Auswertungspfad emittiert werden, und Übermäßige Handlungsmacht für die Bedrohung, die ein sauberer Audit-Trail Ihnen hilft, früh zu erwischen.