§ DOCUMENTATION
Policy-as-Code
Erstellen Sie Richtlinien als JSON oder YAML in Ihrem Repository, validieren Sie sie vor CI mit execlave policies lint, gleichen Sie sie serverseitig mit execlave policies sync ab und prüfen Sie jede Änderung über einen manipulationssicheren Versionsverlauf.
Warum Policy-as-Code
Wenn Richtlinien nur im Dashboard gepflegt werden, umgehen Änderungen denselben Review-Prozess, den Sie auf Anwendungscode anwenden. Eine einzige falsch konfigurierte Regel — zum Beispiel das Umschalten von enforcementMode von block auf log_only — kann den Wirkungsbereich Ihres Agenten still und heimlich erweitern, ohne Diff, ohne Reviewer und ohne automatisierten Test, der dies auffängt.
Execlaves Policy-as-Code-Workflow behandelt Policy-Bundles als erstklassige Quellartefakte: Code-Review, CI-Validierung und reproduzierbare Deployments für jede Richtlinienänderung. Dasselbe Schema, das die API durchsetzt, ist lokal verfügbar, sodass Fehler zur Lint-Zeit und nicht zur Laufzeit erkannt werden.
Policy-Bundles erstellen
Ein Policy-Bundle ist eine JSON- oder YAML-Datei, die eine Richtlinie deklariert. Die Struktur spiegelt den POST /api/v1/policies-Request-Body wider: Pflichtfelder sind name, policyType, enforcementMode und ruleDefinition. Optionale metadata-Schlüssel (owner, ticket, team) werden unverändert gespeichert und im Dashboard angezeigt.
Speichern Sie Bundles an beliebiger Stelle in Ihrem Repository — ein übliches Layout ist ein übergeordnetes policies/-Verzeichnis. Die CLI-Befehle akzeptieren einen Verzeichnispfad und verarbeiten rekursiv alle .json- und .yaml-Dateien darin.
| Feld | Erforderlich | Hinweise |
|---|---|---|
| name | ja | Lesbare Bezeichnung, muss innerhalb der Organisation eindeutig sein |
| policyType | ja | tool_call, prompt_injection, pii_detection, … |
| enforcementMode | ja | block, log_only, require_approval |
| ruleDefinition | ja | Objekt — Schema variiert je nach policyType |
| metadata | nein | Beliebige Schlüssel-Wert-Paare, gespeichert als JSONB |
execlave policies lint
execlave policies lint <path> validiert jede Bundle-Datei gegen das Richtlinien-JSON-Schema, bevor Sie einen Commit erstellen oder einen Pull Request öffnen. Bei jedem Fehler wird ein Nicht-Null-Exit-Code zurückgegeben, was es direkt für CI geeignet macht.| Was lint erkennt | Beispiel |
|---|---|
| Fehlende Pflichtfelder | ruleDefinition vollständig weggelassen |
| Unbekannter Richtlinientyp | policyType: "custom_type" nicht im Enum |
| Falscher Feldtyp | ruleDefinition.tools: String statt Array |
| Ungültiger enforcementMode | "allow" statt "block" / "log_only" / "require_approval" |
| Zusätzliche Top-Level-Schlüssel | Felder außerhalb des Schemas lösen additionalProperties-Fehler aus |
# Validate all policy bundles before committingexeclave policies lint ./policies/ # Output on success✓ production-guardrails.json — valid✓ data-access.yaml — valid2 bundles validated, 0 errors # Output on failure (exits non-zero — CI-friendly)✗ production-guardrails.json — invalid ruleDefinition.tools: must be array1 error foundexeclave policies sync — Dry-run & Anwenden
execlave policies sync <path> vergleicht deklarierte Bundles mit den aktiven Richtlinien in Ihrer Organisation und gibt den Plan aus. Es werden keine Änderungen angewendet, bis Sie --apply übergeben. Synchronisierte Richtlinien erhalten source: "cli-sync" in ihrem metadata-Feld zur Herkunftsverfolgung.# Dry-run (default) — prints plan, no changes appliedexeclave policies sync ./policies/ Plan: + create "Require approval for file writes" (production-guardrails.json) ~ update "Block PII exfiltration" (data-access.yaml) enforcementMode: "log_only" → "block" = no-op "Rate limit external calls" (already in sync) 2 changes pending. Re-run with --apply to apply.# Apply the planexeclave policies sync ./policies/ --apply Applied: ✓ created pol_01j... "Require approval for file writes" ✓ updated pol_02j... "Block PII exfiltration"Richtlinienverlauf & Metadaten
Jedes Richtlinien-Schreibereignis wird im manipulationssicheren Audit-Log aufgezeichnet. Den vollständigen Änderungsverlauf einer Richtlinie erhalten Sie über GET /api/v1/policies/:id/history. Die Antwort ist ältestes zuerst geordnet und enthält für jede Änderung den Akteur, den Zeitstempel und einen Diff auf Feldebene.
Da das Audit-Log ENABLE ALWAYS-Trigger verwendet, die UPDATE und DELETE verhindern, kann der Verlauf nachträglich nicht geändert werden — jeder Eintrag ist konstruktionsbedingt unveränderlich.
curl https://api.execlave.com/api/v1/policies/pol_01j.../history \ -H "Authorization: Bearer $EXECLAVE_API_KEY" # Response{ "data": [ { "eventType": "policy.updated", "actorId": "user_123", "changedAt": "2026-06-02T09:30:00Z", "diff": { "enforcementMode": { "from": "log_only", "to": "block" } } }, { "eventType": "policy.created", "actorId": "cli-sync", "changedAt": "2026-05-15T14:00:00Z", "diff": null } ]}