Markdown-Ausgabe

AI-translated from English; not yet reviewed by a fluent editor.

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

> OpenRouter Armor klassifiziert vorgeschlagene Tool-Aufrufe anhand von Entwicklerregeln. Responses und Chat Completions können markierte Aufrufe zurückhalten; bei der Messages-Kompatibilität bleibt der Client verantwortlich.

By BIG CHANGE Editorial

Published: 2026-10-17T01:51:13.522Z
Updated: 2026-10-17T01:51:13.522Z
Canonical: https://bigchange.ai/blog/openrouter-armor-tool-call-screening-client-enforcement

![Conceptual charcoal illustration of a desktop monitor and idle keyboard; abstract code strokes and one orange pending-call shape appear on the unbranded screen.](https://bigchange.ai/api/media/file/openrouter-armor-call-screening-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual OpenRouter interface or tested security result is depicted.

OpenRouters [Armor-Beta](https://openrouter.ai/docs/guides/features/plugins/armor) 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](https://openrouter.ai/docs/guides/features/plugins/armor#example) 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](https://openrouter.ai/docs/guides/features/plugins/armor#example) 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](https://bigchange.ai/blog/mxc-agent-command-containment-guide) und [NVIDIAs OpenShell- und Sentry-Laufzeitkontrollen](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls), 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](https://openrouter.ai/docs/guides/features/plugins/armor), 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](https://bigchange.ai/blog/mxc-agent-command-containment-guide) 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](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) beschreibt Software-Zugriffskontrollen und einen optionalen Entwurf zur Hardware-Überwachung. Das ist verwandter Kontext, keine direkte Fortsetzung dieser OpenRouter-Funktion.

## Sources

- [OpenRouter-Armor-Dokumentation](https://openrouter.ai/docs/guides/features/plugins/armor) — Primäre Produktdokumentation, geprüft am 17. Oktober 2026. Belegt Beta-Status, Klassifikator- und Regelverhalten, API-Antwortformen, Fehler, eingeschränkte Kontexte, gemeldete Latenz und Beta-Abrechnung. Anbieterangaben, kein unabhängiger Test.
- [BIG CHANGE: Eine MXC-Richtlinie für agentengenerierte Befehle festlegen](https://bigchange.ai/blog/mxc-agent-command-containment-guide) — Frühere Berichterstattung über einen separaten Mechanismus zur Befehlseindämmung; nur als Kontext zur Beziehung zwischen den Beiträgen verwendet.
- [BIG CHANGE: NVIDIAs Plattform für Agentensicherheit](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) — Frühere Berichterstattung über separate Laufzeit-Zugriffskontrollen und einen optionalen Überwachungsentwurf; nur als Kontext zur Beziehung zwischen den Beiträgen verwendet.