Wie OpenRouter Armor Tool-Aufrufe prüft und wann der Client sie stoppen muss

OpenRouters Armor-Beta schaltet einen Regelklassifikator zwischen den vom Modell vorgeschlagenen Tool-Aufruf und die Anwendung, die ihn ausführen könnte. Für Agentenentwickler ist entscheidend, an welcher Stelle eine Entscheidung die Ausführung tatsächlich verhindert. Bei Chat Completions und Responses kann Armor einen markierten Aufruf zurückhalten. Im Claude-Code-Kompatibilitätsmodus der Messages-API bleibt der markierte tool_use in der Antwort; der Client muss seine Ausführung verweigern.

Die aktuelle Dokumentation beschreibt eine seit Oktober 2026 verfügbare Beta. BIG CHANGE hat die dokumentierten Anfrage- und Antwortverträge am 17. Oktober geprüft. Wir haben weder eine API-Anfrage gesendet noch einen Agenten ausgeführt oder dessen Sicherheitsleistung gemessen.

Die große Veränderung

• Was sich geändert hat: Ein OpenRouter-Agent kann seine vorgeschlagenen Tool-Aufrufe durch einen Klassifikator schicken, der Entwicklerregeln anwendet, bevor die Aufrufe die Anwendung erreichen. Im standardmäßigen Durchsetzungspfad wird die Ausführung eines markierten Aufrufs übersprungen und eine Begründung zurückgegeben, damit das Modell fortfahren kann.
• Warum das wichtig ist: Entwickler können Grenzen auf Handlungsebene in Prosa formulieren, einschließlich Ausnahmen für eng begrenzte erlaubte Arbeiten. Der Messages-Kompatibilitätsvertrag überlässt den entscheidenden Ausführungsschritt weiterhin dem Client: Ignoriert dieser eine Markierung, kann er den Aufruf trotzdem ausführen.
• Worauf zu achten ist: Teams müssen ihren Client auf den gewählten API-Ausgabemodus abstimmen, Regeln mit ihrem eigenen Datenverkehr testen und festlegen, wie Klassifikatorfehler behandelt werden sollen. Die Beta-Formate können sich ändern. Laut OpenRouter kann der Klassifikator sowohl zulässige Aufrufe blockieren als auch unzulässige übersehen.

Einen Aufruf vom Vorschlag bis zur Entscheidung verfolgen

OpenRouter hält nach eigener Aussage jeden vorgeschlagenen Tool-Aufruf zurück, bevor er an die Anwendung weitergeleitet wird. Das Entscheidungsmodell erhält den Aufruf, die Regeln und den bisherigen Gesprächsverlauf, schätzt die Übereinstimmung mit jeder Regel ein und führt die Ergebnisse zu flagged oder not_flagged zusammen. Ein nicht markierter Aufruf wird unverändert freigegeben. Im Durchsetzungsmodus wird ein markierter Aufruf zum Überspringen der Ausführung gekennzeichnet; das Modell erhält den Grund und kann einen enger gefassten Aufruf versuchen oder die Ablehnung erklären. Dies ist ein Klassifikatorurteil über die vorgeschlagene Handlung, kein Beweis dafür, dass ein späteres Tool oder der gesamte Agent sicher ist.

Die Regelstufen beantworten unterschiedliche Fragen. Ein Treffer für hard_deny blockiert unabhängig von einer Erlaubnisregel oder der Nutzeranfrage. Ein Treffer für soft_deny kann durch einen Treffer für allow oder dadurch aufgehoben werden, dass der Nutzer im Gespräch genau diese Operation für genau dieses Ziel verlangt. Eine allow-Regel blockiert niemals allein einen Aufruf. OpenRouter dokumentiert außerdem eine eingebaute weiche Ablehnung für eine vom Nutzer gesetzte und nicht aufgehobene Grenze. Entwickler hinterlegen Fakten wie ein vertrauenswürdiges Repository oder ein Bereitstellungsziel in environment; veraltete Fakten können die Präzision einer Regel verringern. Benannte Regelobjekte zeigen in Entscheidungen eine ID und einen Namen. Optionale Schwellenwerte liegen standardmäßig bei 0.6 für Verbotsregeln und 0.7 für Erlaubnisregeln.

Das dokumentierte Responses-Beispiel gibt einem bash-Tool eine harte Verbotsregel für git push. Mit output_mode: "custom_item" wird ein markierter Push durch ein openrouter:armor_blocked-Element mit Aufruf und Begründung ersetzt, gefolgt von der Modellantwort. Das Beispiel zeigt die laut Dokumentation zurückgegebene Serviceantwort; es ist kein von BIG CHANGE durchgeführter Test.

Den Ausgabevertrag vor der Tool-Ausführung wählen

Bei Chat Completions und Responses entfernt der standardmäßige text-Modus einen blockierten Aufruf und setzt eine <openrouter_armor_blocked>-Markierung in den Assistententext. Die Responses-API unterstützt auch custom_item; dabei wird das typisierte Blockierungselement dort zurückgegeben, wo ein function_call erschienen wäre. Laut Dokumentation soll dieses Element unverändert in der nächsten Responses-Eingabe zurückgesendet werden; ein separates function_call_output dafür soll nicht erstellt werden. safeguard_results erfasst die Entscheidungen nach Aufruf-ID.

Die Messages-API hat ein wesentlich anderes Standardverhalten, wenn die Anfrage safeguards enthält: claude_code_compatibility lässt den markierten tool_use in content[] stehen und fügt dessen flagged-Ergebnis zu safeguard_results hinzu. Die Anwendung muss dieses Ergebnis lesen und die Ausführung des Aufrufs verweigern. OpenRouter warnt ausdrücklich, dass ein Messages-Client, der die Entscheidung ignoriert, eine markierte Tool-Nutzung ausführen wird. Wer den Client nicht kontrollieren kann, kann in Messages output_mode: "text" anfordern, damit OpenRouter den Aufruf zurückhält. Wird von einer API ein von ihr nicht darstellbarer Ausgabemodus verlangt, antwortet sie mit 400.

Der automatische Modus von Claude Code über OpenRouters Ori-Metaharness nutzt den Messages-Vertrag ohne zusätzlichen Armor-Plugin-Eintrag. Laut Dokumentation lehnt Claude Code markierte Aufrufe ab, schreibt ein Fehlerergebnis ins Transkript und lässt das Modell fortfahren. Ein Anthropic-Endpunkt mit Unterstützung für seinen Klassifikator kann außerdem eine durchgereichte Entscheidung liefern; an anderen Endpunkten bewertet Armor. Das ist das dokumentierte Integrationsverhalten, keine Behauptung, dass jeder Drittanbieter-Client es korrekt umsetzt.

Einen eng begrenzten Regelsatz konfigurieren und prüfen

Für einen eigenen Agenten sieht die Armor-Anleitung einen armor-Eintrag in plugins vor, mit versioniertem classifier_context (v: 1), auto_mode-Regeln und optionalen Umgebungsfakten. Beginnen Sie mit der Handlung und der geschützten Ressource, die die Regel erkennen soll. Wählen Sie anschließend eine harte Ablehnung für ein Verbot, das auch bei Zustimmung des Nutzers gelten soll, oder eine weiche Ablehnung, wenn genaue Zustimmung oder eine benannte Erlaubnis es berechtigt aufheben können. Die Dokumentation empfiehlt, die Handlung statt nur einer bestimmten Befehlsschreibweise zu beschreiben und Umgebungsfakten aktuell zu halten.

Der standardmäßige enforce-Modus handelt nach den Entscheidungen. audit meldet dieselben Entscheidungen, gibt aber jeden Aufruf frei, auch markierte. Damit lassen sich echter Datenverkehr untersuchen und Regeln vor der Durchsetzung anpassen; es ist kein Schutzmodus. Audit lässt sich nicht mit claude_code_compatibility kombinieren. Lesen Sie in beiden Modi safeguard_results: not_flagged bedeutet erlaubt, flagged bezeichnet eine passende Regel, unavailable bedeutet, dass die Bewertung fehlgeschlagen ist, und skipped bezeichnet ein nicht bewertetes anbietereigenes Tool. Beim Streaming trifft das Entscheidungsobjekt am Ende der Antwort ein. Ein Client mit Messages muss daher darauf warten, bevor er eine Tool-Nutzung ausführt.

OpenRouter nennt on_error: "block" als Standard bei Zeitüberschreitung, Fehlern oder einer für den Klassifikator zu großen Anfrage; on_error: "log" gibt den Aufruf frei. Im Claude-Code-Kompatibilitätsmodus wird ein unavailable-Aufruf bei sichtbarer Entscheidung freigegeben. Anbietereigene Server-Tools werden standardmäßig übersprungen, sofern evaluate_native_tools sie nicht zur Bewertung aus dem nativen Pfad herauszwingt. Diese Einstellungen und der tatsächliche Tool-Pfad gehören in die Integrationsprüfung eines Teams; ein Armor-Eintrag allein belegt nicht, dass jedes Tool bewertet wurde.

Kosten, Geschwindigkeit und Abdeckungsgrenzen der Beta

OpenRouter berichtet, die Bewertung habe 279 Millisekunden im Median und 334 Millisekunden am 90. Perzentil hinzugefügt, wenn der Claude-Code-kompatible Regelsatz geladen war. Dies sind vom Anbieter gemeldete Messwerte unter der genannten Bedingung, kein Benchmark eines bestimmten Agenten oder jedes Regelsatzes. Jeder Aufruf wird vor Freigabe oder Blockierung einmal bewertet. Während der Beta wird die Bewertung nicht berechnet; OpenRouter will Preise vor der allgemeinen Verfügbarkeit bekannt geben. Die Dokumentation legt keinen künftigen Tarif fest.

Das Entscheidungsmodell kann falsch positive Ergebnisse und übersehene Verstöße produzieren, weil es Prosaregeln anhand von Prosaargumenten beurteilt. Die Dokumentation empfiehlt Audit-Entscheidungen für echten Datenverkehr und die Anpassung einzelner Regelschwellen. Armor-Bewertungen werden für HIPAA-, Zero-Data-Retention- oder datenregionsbeschränkte Anfragen noch nicht unterstützt. Eine Anfrage mit aktiviertem Plugin erhält in einem solchen Kontext 403; eine Claude-Code-Anfrage gibt den Aufruf stattdessen als unavailable frei, und Claude Code greift auf die lokale Bewertung im automatischen Modus zurück. Die Beta-Warnung umfasst auch Änderungen an Konfigurationsfeldern, safeguard_results und dem Elementtyp openrouter:armor_blocked.

Armor prüft vorgeschlagene Aufrufe bei der Übergabe vom Modell an die Anwendung. Damit ist es ein anderer Mechanismus als Microsofts MXC-Befehlseindämmung und NVIDIAs OpenShell- und Sentry-Laufzeitkontrollen, die Einschränkungen um eine Arbeitslast oder deren Zugriff legen. Bei Armor ist die unmittelbare Implementierungsfrage, ob das gewählte Antwortformat einen markierten Aufruf zurückhält oder der Client ihn stoppen muss.

Quellen und weiterführende Lektüre

• OpenRouter-Armor-Dokumentation, abgerufen am 17. Oktober 2026. Primärquelle für Beta-Status, Klassifikatorablauf, Regelvorrang, API-Antwortverträge, Fehlerverhalten, ausgeschlossene Datenschutzkontexte, gemeldete Latenz und Beta-Abrechnung. Dies sind dokumentierte Angaben von OpenRouter; BIG CHANGE hat das Plugin nicht ausgeführt.
• BIG CHANGE über Microsoft MXC erklärt richtlinienbasierte Eindämmung von agentengenerierten Befehlen. Der Beitrag beschreibt eine eigene Durchsetzungsebene, keine frühere Phase von Armor.
• BIG CHANGE über NVIDIA OpenShell und Sentry beschreibt Software-Zugriffskontrollen und einen optionalen Entwurf zur Hardware-Überwachung. Das ist verwandter Kontext, keine direkte Fortsetzung dieser OpenRouter-Funktion.