Zum Hauptinhalt springen
Das Gateway sitzt zwischen Ihrem Agenten und jedem Modell, das er aufruft. Damit ist es der einzige Punkt, der jeden Aufruf unabhängig vom Anbieter sieht — jeden Prompt, jede Antwort, jeden Tool-Call und jeden ausgehenden Request, den Ihr Agent darüber leitet — egal, welches SDK den Aufruf ausgegeben hat. Dieser Engpass ist der richtige Ort für Inspektion und Durchsetzung. (Was es nicht sehen kann — ein Tool, das vollständig innerhalb Ihres Prozesses läuft und das Gateway nie überquert — wird in §4 behandelt.) Diese Seite erklärt genau, was das Gateway sehen kann und was nicht, wie die Erkennung funktioniert und wie Lücken geschlossen werden.

​
1. Warum das Gateway der richtige Inspektionspunkt ist

Die meisten Sicherheitskontrollen leben in der Anwendung: Library-Wrapper, Agenten-Framework-Hooks, providerspezifische SDKs. Diese Kontrollen haben einen fatalen strukturellen Fehler — sie brechen, sobald Sie einen zweiten Anbieter hinzufügen, das Framework wechseln oder einem Agenten erlauben, selbst einen neuen Skill zu installieren. Das Gateway hat keine dieser Nähte. Jeder Aufruf Ihres Agenten, unabhängig von Modell, Anbieter oder wie die Tool-Fähigkeit gelangte, passiert einen einzigen Punkt, bevor irgendetwas das Upstream erreicht. Das ist die einzige Ebene, auf der Sie eine Garantie abgeben können: wenn es passiert ist, hat das Gateway es gesehen. OrcaRouter nutzt diese Position für zwei unterschiedliche Durchsetzungsdurchläufe:
  • Guardrails prüfen Text — den Prompt, den Ihr Agent sendet, und die Antwort, die das Modell zurückgibt. Ein Guardrail-Block gibt HTTP 400 guardrail_blocked zurück und kostet kein Kontingent.
  • Die Firewall beurteilt Aktionen — die Tools, die ein Agent aufruft, die MCP-Server, die er erreicht, und die Netzwerkziele, die er meldet. Ein Firewall-Deny gibt HTTP 400 firewall_blocked auf der Inbound-Surface zurück, oder einen Tool-Fehler auf der MCP-Surface, damit das Modell die Ablehnung sehen und darauf reagieren kann.
Beide Ebenen werden einmal in Ihrem Workspace konfiguriert und an einen API-Key gebunden. Kein Redeploy. Keine SDK-Änderung. Ihr Agent ruft weiterhin https://api.orcarouter.ai/v1 exakt wie zuvor auf.

​
2. Die vier Durchsetzungs-Surfaces

Die Firewall wertet jeden Tool-Call gegen genau eine Surface aus — den Punkt im Aufruf-Lebenszyklus, an dem das Gateway ihn sieht.
SurfaceWas das Gateway sieht
inboundDie Tools, die Ihr Agent dem Modell auf dem Request anbietet — die Tool-Definitionen. Das Blockieren hier verhindert, dass das Modell überhaupt ein gefährliches Tool wählen kann.
responseDie tool_calls, die das Modell in seiner Antwort ausgibt — die gewählten Aktionen des Modells, bevor sie dispatcht werden.
mcpEin tools/call, der durch das Firewall-MCP-Gateway dispatcht oder über den SDK-Hook ausgewertet wird — der Aufruf zum Zeitpunkt des Dispatchs.
egressEin ausgehendes Netzwerkziel (Host / IP / CIDR), das ein Tool meldet — die SSRF- und Datenexfiltrations-Surface.
Guardrails fügen zwei weitere Textstages hinzu, die über die obigen Surfaces geschichtet werden: input (der Request-Prompt und die Nachrichten) und output (der Antworttext des Modells). Ein einzelner Request kann alle durchlaufen.

​
3. Erkennung bei der ersten Nutzung

Erkennung erfolgt am Gateway, bei der ersten Nutzung — nicht zur Installationszeit. Ein Tool, ein MCP-Server oder ein Skill, den ein Agent selbst installiert, wird beim ersten Mal abgefangen, wenn sein Aufruf das Gateway überquert. Das ist beabsichtigt: das Gateway ist der einzige Engpass, der jeden Anbieter, jeden Agenten und jeden Aufruf sieht, unabhängig davon, wie die Fähigkeit gelangte. Auf die Erkennung zur Installationszeit zu warten würde Fähigkeiten verpassen, die zur Laufzeit geladen werden.
Das bedeutet, dass ein neues Tool in der Discovered-Tools-Ansicht landet, sobald es in einem Request erscheint, auch wenn keine Regel es benennt. Aktivieren Sie den Observe-Mode, um jeden Tool-Call ohne passende Regel als Abdeckungslücke aufzuzeichnen — diese Ansicht treibt die Policy-Erstellung aus realem Traffic.

​
4. Was das Gateway nicht sehen kann

Die Inspektionsgarantie gilt für Aufrufe, die das Gateway überqueren. Sie erstreckt sich nicht auf ein Tool, das Ihr Agent vollständig innerhalb seines eigenen Prozesses ausführt — eines, das eine lokale Datei liest, eine Library-Funktion aufruft oder einen Subprozess ausführt, ohne jemals eine Nachricht an das Gateway zu senden. Das ist eine ehrliche Grenze, kein Design-Fehler. Das Designziel ist, das Gateway zum auditierten Pfad für die Aufrufe zu machen, die zählen — jene mit realen Konsequenzen:
Wo es läuftGateway sieht es?Wie die Lücke geschlossen wird
Modellvermittelter Tool-Call (das Modell emittiert tool_calls)Ja — response-SurfaceKeine Aktion nötig; bereits gesteuert.
MCP-Dispatch durch das Firewall-MCP-GatewayJa — mcp-SurfaceKeine Aktion nötig; bereits gesteuert.
Ihr Agent ruft POST /api/v1/firewall/evaluate vor dem Dispatchen aufJa — inline ausgewertetBereits gesteuert über den Evaluate-Hook.
Tool läuft in-process, kein Gateway-KontaktNeinMCP-Dispatch und netzwerkaufrufende Tools über das Gateway routen, anstatt sie direkt aus dem Agenten-Prozess aufzurufen.
Wenn Sie heute Tools haben, die in-process laufen und reale Konsequenzen haben, ist der Weg zur Abdeckung, sie als MCP-Server hinter dem Firewall-MCP-Gateway zu registrieren oder den Evaluate-Hook aus Ihrer Agenten-Schleife aufzurufen, bevor Sie dispatchen.

​
5. Rollensteuerung bei Inspektionsdaten

Der Zugang zu Inspektions-Surfaces ist innerhalb Ihres Workspaces rollengesteuert:
FähigkeitMindestrolle
Guardrail-Matches, Firewall-Policies und Discovered-Tools lesenMember
Firewall-Events- und Runs-Feeds lesenDeveloper
Guardrails, Firewall-Policies, Regeln erstellen oder ändernDeveloper
Compliance-Exporte, Firewall-Gateway-scoped Key-Klartext, is_firewall_gateway-Key-FlagAdmin
Ein Firewall-Gateway-scoped Token (der Schlüssel, der für /api/v1/firewall/evaluate und das MCP-Gateway verwendet wird) erfordert die Admin-Rolle zum Erstellen. Ein regulärer API-Key gibt auf diesen Routen 403 zurück.

​
6. Weiterführende Themen

Der Control-Stack

Der vollständige Request-Pfad — Schlüssel, Guardrails, Modell, Firewall, Audit — in einem Diagramm.

Geteilte Verantwortung

Was das Gateway absichert und was in Ihrer Anwendung bleibt.

Agent-Firewall

Policies verfassen, Surfaces konfigurieren und Tool-Calls im Detail steuern.
Das Gateway ist der einzige Inspektionspunkt für jeden Aufruf, der es überquert — konfigurieren Sie Ihre Policies einmal, und jeder Anbieter, jeder Agent und jeder Tool-Call ist abgedeckt.