§ REFERENZARCHITEKTUR
Referenz-Deployment
Wie eine governte Produktionsflotte aus zwei Agenten von Anfang bis Ende aussieht: Stack, Autonomiestufen, Richtliniensatz, gemessene Durchsetzungskosten, SIEM-Routing und die Audit-Nachweise, die jede Kontrolle erzeugt.
Was diese Seite ist — und was nicht
Dies ist eine Referenzarchitektur, keine anonymisierte Kundenfallstudie. Das Szenario beruht darauf, wie wir Execlave selbst betreiben und testen; jede Fähigkeit und jede Zahl auf dieser Seite ist anderswo auf dieser Website dokumentiert — die Latenzwerte stammen aus den veröffentlichten, reproduzierbaren Benchmarks und nichts hier ist eine Schätzung. Wenn wir Kundenfallstudien veröffentlichen, werden sie als solche gekennzeichnet.
Szenario & Stack
Ein mittelgroßes Produktunternehmen betreibt zwei Produktionsagenten mit unterschiedlichen Risikoprofilen — die häufige Ausgangsform, die wir sehen.
| Komponente | Wahl | Warum |
|---|---|---|
| Support-Agent | LangChain (Python), kundenseitig | Verarbeitet Endbenutzereingaben — höchste Injection- und PII-Exposition. |
| Ops-Agent | OpenAI Agents SDK (Python), intern | Schreibt in interne Systeme — Werkzeugmissbrauch ist das Hauptrisiko. |
| Governance | Execlave Cloud (selbst gehostet verfügbar) | Beide Agenten mit je einem SDK-Aufruf instrumentiert. |
| Umgebungen | Produktion + Staging | Gleiche Richtlinien in beiden; in Staging werden verschärfte Richtlinien erneut getestet. |
| SIEM | Splunk oder Microsoft Sentinel | Verstöße landen in der bestehenden SOC-Warteschlange — siehe die Integrationsleitfäden. |
# Support-Agent — LangChain (Python)handler = ExeclaveCallbackHandler(exe, agent_id="support-bot")chain.invoke(input, config={"callbacks": [handler]}) # Ops-Agent — OpenAI Agents SDK (Python)add_trace_processor(ExeclaveTracingProcessor(exe, agent_id="ops-agent"))Autonomiestufen & Richtliniensatz
Jeder Agent deklariert eine Autonomiestufe; Execlave wendet das passende Kontrollpaket an. Richtlinien außerhalb der Stufe werden als auditierte Ausnahmen gekennzeichnet.
| Agent | Autonomiestufe | Was das bedeutet |
|---|---|---|
| support-bot | act_with_approval | Antwortet frei; ausgehende Aktionen (Erstattungen, E-Mails) werden mit 30-minütiger Freigabe-Gültigkeit zur menschlichen Bestätigung in die Warteschlange gestellt. |
| ops-agent | autonomous | Schreibt ohne Freigabe pro Aktion, innerhalb von Kostenobergrenzen, Werkzeug-Allowlist und Limits für externe Aufrufe. |
# Repräsentativer Richtliniensatz (4 von 19 verfügbaren Richtlinientypen) prompt_injection: # beide Agenten enforcement: block # 13-Sprachen-Scan, schweregrad-bewertetpii_detection: # Support-Agent enforcement: warn # 14 Kategorien, an der Grenze gehashttool_allowlist: # beide Agenten enforcement: block # send_email erfordert Freigabe; db_write für Support gesperrtcost_budget: # Organisation + pro Agent enforcement: block # Tageslimit pro Agent, Monatslimit pro Org, Burn-Rate-Alarm bei 80%Pro Richtlinie stehen vier Durchsetzungsmodi zur Verfügung — monitor, warn, require_approval, block — sodass dieselbe Richtlinie zunächst nur als Monitor ausgerollt werden und nach einer Woche sauberem Signal zu Block aufsteigen kann. Siehe Richtlinien für den vollständigen Katalog mit 19 Typen.
Was Durchsetzung zur Laufzeit kostet
Veröffentlichte, gemessene Werte — reproduzieren Sie sie mit den eingecheckten Harnesses (backend/scripts/bench-enforcement.ts, bench-enforce-e2e.ts).
| Metrik | Gemessen |
|---|---|
| In-Process-Richtlinienauswertung — p50 / p95 / p99 | 8.4 µs / 10.6 µs / ~21 µs |
| Auswertungsdurchsatz — einzelner Kern | ~96.000 Durchläufe/Sek. |
| Serverseitige Enforce-Entscheidung, inkl. DB — p50 / p95 / p99 | 2.1 ms / 2.9 ms / 3.9 ms |
| Semantische Stufe (modellgestützte Prüfungen) | noch nicht veröffentlicht — nie geschätzt |
Methodik, Umgebung und Vorbehalte finden Sie auf der Benchmarks-Seite. Die praktische Erkenntnis für dieses Deployment: Governance auf Muster-Ebene fügt in-process Mikrosekunden und serverseitig niedrige einstellige Millisekunden hinzu — klein genug, um im Anfragepfad beider Agenten zu sitzen.
Wenn etwas auslöst
Die operative Schleife, die diese Architektur erzeugt.
Ein Prompt-Injection-Versuch gegen support-bot wird zur Durchsetzungszeit blockiert und der Trace als policy_blocked markiert. Der Trace streamt ins SIEM, wo die Verstoß-Burst-Regel (ausgeliefert in den Splunk / Sentinel Leitfäden) einen Vorfall in der SOC-Warteschlange auslöst. Der Analyst folgt dem Incident-Response-Workflow: Pivot nach trace_id, Prüfung der Span-Zeitachse und des Agentenpasses, Verschärfen oder Bestätigen der Richtlinie und Anhängen des hash-verketteten Audit-Exports an den Vorfalldatensatz.
Welche Nachweise dieses Deployment erzeugt
Was Sie einem Prüfer übergeben — jedes Artefakt ordnet sich einer konkreten Kontrolle oben zu.
| Artefakt | Erzeugt durch |
|---|---|
| Signierter Compliance-Bericht (RSA-SHA256, offline verifizierbar) | GET /api/v1/compliance/report — 7 Frameworks einschließlich EU AI Act |
| Append-only, hash-verkettetes Audit-Log (Aufbewahrung bis zu 10 Jahre) | Jede Durchsetzungsentscheidung, Freigabe und Richtlinienänderung |
| Freigabedatensätze mit menschlicher Identität + Zeitstempel | act_with_approval-Aktionen auf support-bot |
| Nachweiszuordnung pro EU-AI-Act-Artikel | docs/compliance/eu-ai-act — Artikel für Artikel |
Vollständige Zuordnung mit Nachweis-Links pro Artikel: EU-AI-Act-Compliance. Um diese Architektur zu reproduzieren, beginnen Sie mit Erste Schritte und den Framework-Integrationen.