§ DOCUMENTATION

Runtime-Guardrails

Agentenspezifische Richtlinien zur Werkzeug-Aufrufsteuerung, PII- und Injection-Scan von Werkzeugausgaben sowie Agent-zu-Agent-Credential-Authentifizierung — Durchsetzung, die zur Aufrufzeit greift, nicht erst bei der Richtliniendefinition.

§ 01

Die zwei Laufzeit-Richtlinientypen

Execlave ergänzt zwei neue Richtlinientypen, die die Agentenausführung zur Laufzeit kontrollieren — nicht erst bei der Trace-Aufnahme. Beide werden über POST /api/v1/policies mit dem entsprechenden policyType-Wert erstellt.

policyType	Was geschützt wird	Wann aktiv
tool_invocation	Welche Werkzeuge ein Agent aufrufen darf — Erlaubnis/Sperre nach Werkzeugname	Vor der Werkzeugausführung
tool_output_scan	Die Ausgabe, die ein Werkzeug zurückgibt — gescannt auf PII und Prompt-Injection	Nach der Werkzeugrückgabe, bevor der Agent sie sieht

Beide Typen erfordern das Feature-Flag FF_RUNTIME_GUARDRAILS. Es ist in der verwalteten Cloud sowie in der Docker-Compose-Datei und dem Helm-Chart für Self-Hosting aktiviert.

§ 02

tool_invocation — Werkzeugaufrufe erlauben/sperren

Eine tool_invocation-Richtlinie ist eine agentenspezifische Erlaubnis-/Sperrliste für die MCP-Werkzeuge, die der Agent zur Laufzeit aufrufen darf. Execlave wertet die Richtlinie vor der Werkzeugausführung aus — wenn das Werkzeug auf der Sperrliste steht oder in der Erlaubnisliste fehlt (je nach Ihrer Standardaktion), wird der Aufruf blockiert und ein Audit-Ereignis erfasst. Es findet keine Werkzeugausführung statt.

curl -X POST https://api.execlave.com/api/v1/policies \  -H "Authorization: Bearer $EXECLAVE_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "name": "Restrict data-exfil tools for research-agent",    "policyType": "tool_invocation",    "enforcementMode": "block",    "agentId": "agt_01j...",    "ruleDefinition": {      "allowed_tools": ["web_search", "read_file"],      "denied_tools":  ["send_email", "upload_file", "execute_code"]    }  }'

Die ruleDefinition akzeptiert ein allow-Array, ein deny-Array und optional eine agentId, um die Richtlinie auf einen bestimmten Agenten zu beschränken. Werkzeuge auf der Sperrliste werden bedingungslos blockiert. Werkzeuge, die in keinem der Arrays aufgeführt sind, erben die Standardaktion der Richtlinie.

§ 03

tool_output_scan — PII & Injection-Prüfung

Eine tool_output_scan-Richtlinie fängt den Wert ab, den ein Werkzeug zurückgibt, bevor er zum Agenten gelangt. Execlave delegiert den Scan an den Processing-Service — dieselben Detektoren, die von Injection Detection und PII Detection verwendet werden, über die Endpunkte /scan/pii und /scan/injection.

Wenn PII (aus denied_pii_types) oder Injection in der Ausgabe eines Werkzeugs erkannt wird und die Richtlinie auf enforcementMode: "block" gesetzt ist, wird die Ausgabe unterdrückt, bevor sie den Agenten erreicht, und ein Block-Audit-Ereignis erfasst.

Prävention erfordert einen expliziten Aufruf. Übergeben Sie das Werkzeug-Ergebnis an enforceToolOutput() (JS) bzw. enforce_tool_output() (Python), nachdem das Werkzeug geantwortet hat und bevor Sie das Ergebnis an das Modell zurückgeben. Die Framework-Adapter rufen dies nicht automatisch auf — ein Werkzeug-Ergebnis, das Execlave nie erreicht, kann nicht blockiert werden. Ohne diesen Aufruf wirkt die Richtlinie rein detektivisch: Verstöße werden nachträglich aus den erfassten Traces protokolliert statt verhindert.

Der Scan ist latenzbegrenzt: Jeder Scan-Aufruf bricht standardmäßig nach 1 Sekunde ab (RUNTIME_GUARDRAIL_SCAN_TIMEOUT_MS). Wenn der Processing-Service nicht verfügbar ist, protokolliert Execlave eine Warnung und lässt die Ausgabe durch, anstatt den Agenten zu blockieren — ein Processing-Ausfall blockiert Workloads nicht hart.

curl -X POST https://api.execlave.com/api/v1/policies \  -H "Authorization: Bearer $EXECLAVE_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "name": "Scan DB-query output for PII before agent sees it",    "policyType": "tool_output_scan",    "enforcementMode": "block",    "ruleDefinition": {      "scan_pii": true,      "scan_injection": true,      "denied_pii_types": ["ssn", "credit_card"]    }  }'

§ 04

A2A-Credential-Authentifizierung

Wenn ein Agent einen anderen aufruft, kann Execlave verlangen, dass der aufrufende Agent seinen verifizierbaren Credential vorlegt, bevor der nachgelagerte Agent fortfährt. Dies wird über das Feature-Flag FF_A2A_AUTH gesteuert, das in der verwalteten Cloud sowie in der Docker-Compose-Datei und dem Helm-Chart für Self-Hosting aktiviert ist.

Der verwendete Credential ist der exe_agt_-Credential, der über Agent Identity ausgestellt wird. Bei POST /api/v1/agents/authorize verifiziert Execlave den Agent-Credential des Aufrufers und erfasst eine a2a.authorize-Audit-Entscheidung — Gewährung oder Ablehnung des Agent-zu-Agent-Aufrufs mit vollständigem Nachweispfad.

A2A-Auth ist additiv: Der aufrufende Agent benötigt weiterhin einen gültigen API-Key oder JWT für den allgemeinen API-Zugriff. Der exe_agt_-Credential ergänzt diese Basis um eine verifizierbare Agentenidentität.

§ 05

Flags der Runtime-Guardrails

Beide Runtime-Guardrail-Funktionen werden durch Umgebungsflags gesteuert, die in der verwalteten Cloud sowie in der Docker-Compose-Datei und dem Helm-Chart für Self-Hosting aktiviert sind. Ist ein Flag nicht gesetzt oder hat es einen anderen Wert als true, ist die entsprechende Funktion inaktiv. Um eines in einer Self-Hosted-Installation abzuschalten, setzen Sie es für Backend und Worker auf false und starten beide neu.

Umgebungsvariable	Wirkung wenn aktiviert
FF_RUNTIME_GUARDRAILS	Aktiviert die Richtlinientypen tool_invocation und tool_output_scan
FF_A2A_AUTH	Aktiviert A2A-Credential-Verifikation auf /api/v1/agents/authorize

Die beiden Flags sind unabhängig — Sie können Werkzeugaufruf-Steuerung und Ausgaben-Scan aktivieren, ohne A2A-Auth zu aktivieren, und umgekehrt.

§ 06

Häufig gestellte Fragen

Was passiert, wenn der Processing-Service während eines Tool-Output-Scans nicht erreichbar ist?

Execlave versagt sicher. Wenn der Processing-Service (/scan/pii oder /scan/injection) nicht erreichbar ist, protokolliert Execlave eine Warnung und lässt den Tool-Output zum Agenten durch, anstatt ihn hart zu blockieren. So verhindert ein Ausfall des Processing-Services, dass Agent-Workloads zum Stillstand kommen. Die Warnung wird im Audit-Log erfasst, damit Sie beim Incident-Review ungeprüfte Ausgaben identifizieren können.

Kann ich in derselben tool_invocation-Richtlinie manche Werkzeuge erlauben und andere verbieten?

Ja. Die ruleDefinition einer tool_invocation-Richtlinie akzeptiert eine Erlaubnisliste und eine Sperrliste. Werkzeuge auf der Sperrliste werden unabhängig von der Erlaubnisliste blockiert. Werkzeuge, die auf keiner der beiden Listen stehen, erben die in der Richtlinie definierte Standardaktion — erlauben oder verbieten, je nach Ihrer Konfiguration. So können Sie eine präzise Erlaubnisliste, eine grobe Sperrliste oder eine Kombination aus beidem erstellen.

Ersetzt A2A-Authentifizierung die reguläre API-Key-Authentifizierung für Agent-zu-Agent-Aufrufe?

Nein — A2A-Authentifizierung ist eine zusätzliche Schicht über dem bestehenden Credential-System. Wenn FF_A2A_AUTH aktiviert ist, verlangt Execlave vom aufrufenden Agenten, seinen exe_agt_-Credential (ausgestellt über Agent Identity) am Endpunkt /api/v1/agents/authorize vorzuweisen. Der Aufrufer benötigt weiterhin einen gültigen API-Key oder JWT für den allgemeinen API-Zugriff. A2A-Auth ergänzt die Autorisierungsentscheidung um eine verifizierbare Agentenidentität und erfasst ein a2a.authorize-Audit-Ereignis.

Sind die Flags FF_RUNTIME_GUARDRAILS und FF_A2A_AUTH unabhängig voneinander?

Ja. FF_RUNTIME_GUARDRAILS steuert die Richtlinientypen tool_invocation und tool_output_scan. FF_A2A_AUTH steuert die A2A-Credential-Authentifizierung. Sie können beide unabhängig voneinander abschalten. Beide sind in der verwalteten Cloud sowie in der Docker-Compose-Datei und dem Helm-Chart für Self-Hosting aktiviert. Ist ein Flag deaktiviert (jeder andere Wert als true oder nicht gesetzt), ist das entsprechende Verhalten nicht aktiv.