Sicherheitsmodell¶

Umfassende Sicherheitsarchitektur, die Zero-Trust, richtliniengesteuerten Schutz fuer KI-Agenten gewaehrleistet.

Andere Sprachen¶

Inhaltsverzeichnis¶

Ueberblick¶

In Entwicklung — optionale ausgehende Zugriffe: Ein Betreiberprofil bindet HTTP-Werkzeuge an benannte Operationen, Ziele, Zugangsdatenquellen und eine einzelne Ausführung. Bestehende Projekte bleiben ohne Aktivierung unverändert. Die Übersicht beschreibt Grenzen und Einrichtung; der Kontrollkatalog trennt Implementierung von aufbewahrten Prüfnachweisen.

Eindaemmungsabdeckung: 1.21.0 ergaenzt ausgewaehlte Docker-/gVisor-Effektgrenzen, exakte Genehmigungen fuer vorbereitete Aufrufe, geschuetzte Journale an den abgedeckten Einstiegspunkten und unabhaengige Worker-Eigentuemerschaft. Siehe den Eindaemmungs-Leitfaden fuer implementierte Pfade und Deployment-Annahmen. Die nachfolgende Architektur und Stufenkonfiguration sind kein Nachweis einer vollstaendigen Durchsetzung auf allen Pfaden. Firecracker-Oneshot-Befehle, Parser, MCP-stdio, PTY-Sitzungen und verwaltete CLI-Worker verwenden einen versionierten Gast-Transport und unabhaengige VMM-Eigentuemerschaft. Verwaltete VMs erhalten ausschliesslich von der Runtime ausgestellte Tool-/Inferenz-Capabilities. Isolierte Browser-Ausfuehrung bleibt nicht verfuegbar. Firecracker-Setup beschreibt die Deployment-Anforderungen fuer Gast und Host; Docker-Tests validieren kein VM-Deployment.

Symbiont implementiert eine sicherheitsorientierte Architektur, die fuer regulierte und hochsichere Umgebungen entwickelt wurde. Das Sicherheitsmodell basiert auf Zero-Trust-Prinzipien mit umfassender Richtliniendurchsetzung, mehrstufiger Sandbox und kryptographischer Auditierbarkeit.

Sicherheitsprinzipien¶

• Zero Trust: Alle Komponenten und Kommunikationen werden verifiziert
• Defense in Depth: Mehrere Sicherheitsschichten ohne Single Point of Failure
• Richtliniengesteuert: Deklarative Sicherheitsrichtlinien zur Laufzeit durchgesetzt
• Vollstaendige Auditierbarkeit: Jede Operation mit kryptographischer Integritaet protokolliert
• Least Privilege: Minimale fuer den Betrieb erforderliche Berechtigungen

Mehrstufige Sandbox¶

Die Laufzeitumgebung liefert drei nummerierte Host-Isolationsstufen (Stufe 1 → Stufe 3), das benannte landlock-Backend und ein Hosted-Execution-Backend (E2B). Die nummerierten Stufen bilden eine monoton zunehmende Isolationsleiter. Weder landlock noch E2B ist ein Peer auf dieser Leiter: Landlock ist ein Daemon-freies, kernel-durchgesetztes Backend fuer einmalige Befehle, Parser und den verwalteten CLI-Kindprozess, dokumentiert unter Landlock (native Worker); E2B laeuft auf Drittanbieter-Infrastruktur und wird unten separat dokumentiert.

graph TB
    A[Risk Assessment Engine] --> B{Risk Level}

    B -->|Low Risk| C[Tier 1: Docker]
    B -->|Medium Risk| D[Tier 2: gVisor]
    B -->|High Risk| E[Tier 3: Firecracker]

    A -.->|Opt-in via DSL| H[Hosted: E2B]

    subgraph "Tier 1: Container Isolation"
        C1[Container Runtime]
        C2[Resource Limits]
        C3[Network Isolation]
        C4[Read-only Filesystem]
    end

    subgraph "Tier 2: User-space Kernel"
        D1[System Call Interception]
        D2[Memory Protection]
        D3[I/O Virtualization]
        D4[Enhanced Isolation]
    end

    subgraph "Tier 3: microVM"
        E1[KVM Hardware Virtualization]
        E2[Dedicated Kernel]
        E3[Read-only Rootfs]
        E4[Per-execution Lifecycle]
    end

    subgraph "Hosted: third-party cloud"
        H1[No on-host isolation]
        H2[Trust assumption: provider]
        H3[Quick-start, no setup]
    end

    C --> C1
    D --> D1
    E --> E1
    H --> H1

Jede Host-Isolationsstufe — landlock, Docker, gVisor und Firecracker — wird im OSS-Runtime ausgeliefert. Betreiber waehlen die Stufe pro Agent ueber den DSL-Block with { sandbox = ... } oder setzen einen Projekt-Standard via [sandbox] tier = "..." in symbiont.toml. E2B ist ausschliesslich ueber DSL Opt-in (with { sandbox = "e2b" }) und wird absichtlich nicht als [sandbox] tier-Wert angeboten.

Starke Isolation ist eine Grundlage, kein Upsell. Die Stufen bleiben im Open-Source-Runtime, damit die Community die Grenze, auf die sie sich verlaesst, lesen, pruefen und reproduzieren kann. Die Gast-Attestierung ist der klarste Fall: Ein Fingerabdruck ueber Quellen, die man nicht lesen kann, bezeugt nichts. Der Gastdienst ist gerade deshalb quelloffen, weil er eine Sicherheitskontrolle ist.

Landlock (native Worker)¶

Benannt als landlock, nicht nummeriert. Dieses optionale Linux-Backend verwendet native Prozesse und einen extern verwalteten delegierten Supervisor. Es benoetigt weder ein Container-Image noch einen Container-Daemon. Docker bleibt der Standard. Siehe Diensteinrichtung und Migration.

Konfiguration: Waehlen Sie with { sandbox = "landlock" } pro Agent oder setzen Sie [sandbox] tier = "landlock" in symbiont.toml. Registrierte HTTP- und geplante Agenten muessen Landlock explizit waehlen; ihr bestehender Standard bleibt Docker/Tier1. Schreibgeschuetzte und beschreibbare Obergrenzen stammen aus [sandbox.roots] und werden mit den anderen Backends geteilt. [sandbox.landlock] enthaelt abi_floor, require_network, Speicher-, CPU-, PID-, Lebensdauer- und Ausgabelimits sowie seine supervisor-Konfiguration. Die standardmaessige und mindestens unterstuetzte ABI ist nun 6, auch wenn eine aeltere Konfiguration eine niedrigere Untergrenze setzt. Eine hoeher konfigurierte Untergrenze gilt weiterhin. Natives Little-Endian-x86_64 oder -aarch64 sowie funktionierende seccomp-Filterung sind erforderlich.

Anwendungsfaelle: - Eine Workstation oder ein Desktop, auf dem der Betrieb eines Container-Daemons pro Agent nicht sinnvoll ist - Beschraenkung der Dateisystemreichweite, Sockets und ausgehenden Signale eines lokalen Prozesses, ohne ein Image bereitzustellen

Sicherheitsmerkmale: - Dateisystembeschraenkung auf deklarierte Roots, vom Kernel durchgesetzt - Landlock-ABI-6-Scopes verhindern Signale und Verbindungen zu abstrakten Unix-Sockets von Prozessen ausserhalb der Domaene des Workers. Signale innerhalb der Domaene bleiben nutzbar. - Mit dem Standardwert require_network = true verweigert seccomp neue Sockets, was TCP, UDP und Pfadnamen-Unix-Sockets abdeckt. Private Unix-Stream-Socket-Paare bleiben nutzbar. Datagramm-Paare werden verweigert, da sie an unbeteiligte Pfadnamen-Sockets senden koennen. io_uring-Operationen und alternative Syscall-ABIs werden abgelehnt, damit sie diese Beschraenkung nicht umgehen koennen. - require_network = false erlaubt ausdruecklich neue IPv4-/IPv6-Sockets. Es erlaubt keine Host-Unix-Sockets, keine anderen Socket-Familien, keine Datagramm-Paare und kein io_uring. Diese Option gewaehrt IP-Netzwerkzugriff einschliesslich Loopback; sie ist keine Egress-Allowlist. - Eine Basis-Lese-/Ausfuehrungsberechtigung fuer System-Verzeichnisse mit ausfuehrbaren Dateien und Bibliotheken, die erforderlich ist, bevor ein dynamisch gelinktes Programm starten kann. Sie umfasst keinen beschreibbaren Pfad, nichts unterhalb eines Home-Verzeichnisses und keine breite /etc-Berechtigung. - Rulesets verlangen vollstaendige Durchsetzung. Der Standard der Crate ist Best-Effort und ignoriert stillschweigend, was der Kernel nicht unterstuetzt; dieser Standard wird nicht verwendet. - Regeln und der Syscall-Filter werden im Elternprozess gegen geoeffnete Dateisystemobjekte konstruiert. Das Ersetzen eines Roots nach der Vorbereitung kann dessen Berechtigung nicht umleiten. Das Kind installiert die Beschraenkungen und markiert Deskriptoren oberhalb von stderr mittels roher Syscalls als close-on-exec. Fehlende deklarierte Roots lassen die Vorbereitung fehlschlagen; nicht vorhandene optionale Systempfade duerfen entfallen. Eine fehlgeschlagene Installation bricht den Spawn ab. - Zusaetzlich geerbte Datei-, Socket- und Ring-Deskriptoren werden bei exec geschlossen. Stdin, stdout und stderr bleiben explizite Capabilities: SDK-Aufrufer muessen ausschliesslich die beabsichtigten Kanaele bereitstellen. Der ausgelieferte MCP-Pfad verwendet Pipes. Dies entzieht keine Capabilities, die ein Betreiber bewusst ueber stdio durchreicht oder ueber lesbare Roots gewaehrt.

Migration. Hosts mit ABI 4 oder 5 schlagen nun fail-closed fehl; ein Absenken von abi_floor kann die schwaechere Grenze nicht wiederherstellen. Workloads, die Unix-Dienste, Datagramm-Paare, io_uring oder Kompatibilitaets-Executables benoetigen, muessen ein geeignetes beaufsichtigtes Backend verwenden. Audit-Deskriptoren enthalten Grenzversion 3, geteilte Zulassung und cgroup-Beaufsichtigung, die effektive ABI-Anforderung, Signal-/Socket-Scopes, die Socket-Richtlinie, die Ring-Ablehnung und die Richtlinie fuer geerbte Deskriptoren.

Aktuelle Abdeckung. Registrierte HTTP- und geplante Agenten, MCP-stdio, kontrollierte Oneshot-Befehle, Git-Snapshots, das Staging deklarierter Dateien und verwaltete CLI-Worker verwenden dieses Backend. Interaktive PTYs bleiben nicht unterstuetzt. Die Auswahl auf einem nicht unterstuetzten Pfad schlaegt fehl, statt auf unbeschraenkte Ausfuehrung umzuschalten.

Lebensdauer der Berechtigung. Eine Domaene kann nach ihrer Anwendung nicht gelockert werden. Das SDK-CLI-Kind erhaelt seine Domaene einmalig beim Spawn, einschliesslich Schreibzugriff auf sein Arbeitsverzeichnis. Direkte Roots autorisieren die konfigurierte Hierarchie fuer diese Lebensdauer; sie erstellen keinen Schnappschuss von Dateiinhalten und beschraenken Schreibvorgaenge nicht auf die Veroeffentlichung neuer Dateien. MCP-Discovery und Aufrufe ohne deklarierte Dateien leeren die konfigurierten Host-Roots. Kontrollierte MCP- und Low-Level-SDK-CLI-Worker behalten dauerhafte geteilte CPU-/Speicher-/Worker-Reservierungen bis zur Entfernung der cgroup. Delegierte cgroups setzen Ressourcenlimits durch und stoppen Nachkommen auch dann, wenn diese die Prozessgruppe verlassen. Der unabhaengige Dienstmanager behandelt Supervisor-Ausfaelle und Watchdog-Ablauf. Das rohe PreparedDomain-Primitiv wendet nur Kernel-Zugriffskontrollen an und erwirbt keine Lease.

Fail-closed. Die erforderliche Landlock-ABI und die native Architektur werden vor der Autorisierung geprueft. Fehler bei der Konstruktion oder Installation des Rulesets, einschliesslich nicht verfuegbarer seccomp-Filterung, brechen den Spawn ab, bevor die Worker-Executable startet. Es gibt keine teilweise Anwendung und keinen Rueckfall auf unbeschraenkte Host-Ausfuehrung.

Zulassungssemantik. SecurityTier ist partiell geordnet. Landlock erfuellt eine explizite Landlock-Anforderung oder das Minimum ohne Isolation, ist aber mit Hosted-Ausfuehrung und der nummerierten Docker/gVisor/Firecracker-Leiter nicht vergleichbar. So erfuellt ein nativer Worker keine Container- oder VM-Anforderung stillschweigend.

Validierung. crates/runtime/tests/landlock_sandbox.rs ueberprueft echte beschraenkte Kindprozesse, einschliesslich ersetzter Lese-/Schreib-Roots und legitimen Zugriffs ueber die urspruenglichen Objekte, Socket- und Signalbeschraenkungen, geerbter Deskriptoren, privater Stream-IPC, expliziten IP-Zugriffs und der Ablehnung alternativer Syscall-ABIs. scripts/test-landlock-boundary.py --binary /path/to/symbi --report /path/to/report.json ueberprueft den ausgelieferten signierten MCP-Dispatch, nutzbare Ausgabe, Dateisystem-, TCP-, UDP-, Unix-Socket- und Signalablehnungen, das erforderliche Audit sowie die Ablehnung nicht unterstuetzter Kernel mit lokalen synthetischen Fixtures. Geschuetzte Beobachter pruefen unabhaengig auf zugestellte Nachrichten und Signale. Diese Pruefungen belegen keine adaptive Ausbruchsresistenz. Das separate scripts/test-landlock-supervision.py ueberprueft echte Fehlerfaelle im cgroup-Lebenszyklus. Siehe den Landlock-Kontrakt des Kernels.

Stufe 1: Docker-Isolation¶

Anwendungsfaelle: - Vertrauenswuerdige Entwicklungsaufgaben - Datenverarbeitung mit geringer Sensibilitaet - Interne Tool-Operationen

Sicherheitsmerkmale:

docker_security:
  memory_limit: "512MB"
  cpu_limit: "0.5"
  network_mode: "none"
  read_only_root: true
  security_opts:
    - "no-new-privileges:true"
    - "seccomp:default"
  capabilities:
    drop: ["ALL"]
    add: ["SETUID", "SETGID"]

Bedrohungsschutz: - Prozessisolation vom Host - Ressourcenerschoepfungsschutz - Netzwerkzugriffskontrolle - Dateisystemschutz

Stufe 2: gVisor-Isolation¶

Anwendungsfaelle: - Standard-Produktionsworkloads - Verarbeitung sensibler Daten - Integration externer Tools

Sicherheitsmerkmale: - Benutzerbereich-Kernel-Implementierung - Systemaufruf-Filterung und -Uebersetzung - Speicherschutzgrenzen - E/A-Anfrageverifizierung

Konfiguration:

gvisor_security:
  runtime: "runsc"
  platform: "ptrace"
  network: "sandbox"
  file_access: "exclusive"
  debug: false
  strace: false

Erweiterter Schutz: - Kernel-Sicherheitsluecken-Isolation - Systemaufruf-Abfangung - Speicherkorruptions-Praevention - Seitenkanalangriff-Minderung

Voraussetzungen: Installieren Sie runsc und registrieren Sie es als Docker-Runtime in /etc/docker/daemon.json. symbi doctor meldet, ob runsc erreichbar ist.

Stufe 3: Firecracker microVM¶

Anwendungsfaelle: - Workloads mit hoechster Isolationsanforderung (nicht vertrauenswuerdiger Code, mandantenfaehig, regulierte Daten) - Wenn die Granularitaet der Syscall-Filter (gVisor) unzureichend ist und eine echte Kernel-Grenze erforderlich ist - VM-Lebenszyklus pro Ausfuehrung fuer staerkere Eindaemmung des Schadensradius

Sicherheitsmerkmale: - Hardware-Virtualisierung via KVM - microVM pro Ausfuehrung mit vom Betreiber bereitgestelltem Kernel + rootfs - Standardmaessig schreibgeschuetztes Root-Dateisystem - Keine geteilte Kernel-Oberflaeche mit dem Host - Gast-Attestierung: Der Handshake prueft die Protokollversion und einen Fingerabdruck der Quellen des Gastdienstes und weist ein veraltetes oder nicht passendes Image zurueck, bevor ein Befehl gesendet wird - Unabhaengige VMM-Eigentuemerschaft: Ein Supervisor ausserhalb der Reasoning-Schleife besitzt die VM-Lebensdauer, sodass eine VM ihren Supervisor nicht ueberdauern kann; eine verwaiste VM wird anhand einer verifizierten Prozessidentitaet statt einer wiederverwendbaren PID zurueckgeholt - Unprivilegierte Gast-Workload: Befehle laufen als Nicht-Root-Gastbenutzer mit no_new_privs sowie expliziten Prozess- und Dateideskriptor-Limits

Konfiguration: [sandbox.firecracker] in symbiont.toml:

[sandbox]
tier = "tier3"

[sandbox.firecracker]
kernel_image_path = "/var/lib/firecracker/vmlinux"
rootfs_path       = "/var/lib/firecracker/rootfs.ext4"
vcpus             = 1
mem_mib           = 512
rootfs_read_only  = true

Voraussetzungen: Der Betreiber muss (a) ein Firecracker-kompatibles Kernel-Image und (b) ein Root-Dateisystem-Image mit dem passenden kompilierten Gastdienst bereitstellen. Siehe docs/firecracker-setup.md fuer einen schrittweisen Quickstart, den In-VM-Init-Kontrakt und eine Haertungs-Checkliste. symbi doctor meldet, ob das firecracker-Binary erreichbar ist.

Sobald Sie beide Artefakte haben, scaffolden Sie ein tier3-Projekt mit:

symbi init --profile assistant --sandbox tier3 \
  --firecracker-kernel /var/lib/firecracker/vmlinux \
  --firecracker-rootfs /var/lib/firecracker/rootfs.ext4

symbi init validiert, dass beide Dateien existieren, bevor symbiont.toml geschrieben wird, sodass Fehlkonfigurationen zur Scaffold-Zeit auftreten und nicht erst beim ersten Agent-Lauf.

Hosted-Ausfuehrung: E2B¶

E2B ist ein Hosted-Cloud-Sandbox-Backend, keine Host-Isolationsstufe. Es liegt ausserhalb der Stufen-1-bis-3-Leiter und wird hier der Vollstaendigkeit halber dokumentiert.

Was es ist: Code laeuft auf der Infrastruktur von E2B ueber deren HTTPS-API; die Laufzeit liefert nur einen HTTP-Client. Setzen Sie E2B_API_KEY und waehlen Sie es pro Agent mit with { sandbox = "e2b" }. Es gibt kein --sandbox e2b-Flag fuer symbi init — E2B ist absichtlich ausschliesslich per DSL Opt-in, da es ein anderes Vertrauensmodell als die Host-Stufen darstellt.

Anwendungsfaelle: - Quickstart-Demos und Evaluierung ohne Installation von Docker, gVisor oder Firecracker. - Entwicklungsumgebungen, in denen der Betreiber keinen Sandbox-Host betreiben kann (CI ohne privilegierten Modus, abgeschottete Laptops, ARM-Entwickler-Maschinen).

Was es nicht ist: - Kein Ersatz fuer Host-Isolation. Code, Prompts und Tool-Ausgaben durchlaufen die Infrastruktur von E2B. Nicht fuer Workloads mit Datenschutz-, Residenz- oder Compliance-Anforderungen verwenden. - In einer Sicherheitsbewertung nicht mit Stufe ½/3 vergleichbar. Die Laufzeit bildet E2B → SecurityTier::Hosted ab, das beim Sortieren unterhalb von Tier1 einsortiert wird — Richtlinien, die Host-Isolation verlangen (tier >= Tier1), lehnen Hosted-Ausfuehrung ab.

Konfiguration: Keine projektweite Konfiguration; setzen Sie E2B_API_KEY in der Umgebung und verwenden Sie with { sandbox = "e2b" } pro Agent.

Richtlinien-Engine¶

Richtlinienarchitektur¶

Die Richtlinien-Engine bietet deklarative Sicherheitskontrollen mit Laufzeitdurchsetzung:

graph TB
    A[Policy Definition] --> B[Policy Parser]
    B --> C[Policy Store]
    C --> D[Policy Engine]
    D --> E[Enforcement Points]

    E --> F[Agent Creation]
    E --> G[Resource Access]
    E --> H[Message Routing]
    E --> I[Tool Invocation]
    E --> J[Data Operations]
    E --> CPG[Inter-Agent Policy]

    K[Audit Logger] --> L[Policy Violations]
    E --> K

Richtlinientypen¶

Zugriffskontrollrichtlinien¶

Definieren, wer unter welchen Bedingungen auf welche Ressourcen zugreifen kann:

policy secure_data_access {
    allow: read(sensitive_data) if (
        user.clearance >= "secret" &&
        user.need_to_know.contains(data.classification) &&
        session.mfa_verified == true
    )

    deny: export(data) if data.contains_pii == true

    require: [
        user.background_check.current,
        session.secure_connection,
        audit_trail = "detailed"
    ]
}

Datenflussrichtlinien¶

Kontrollieren, wie Daten durch das System fliessen:

policy data_flow_control {
    allow: transform(data) if (
        source.classification <= target.classification &&
        user.transform_permissions.contains(operation.type)
    )

    deny: aggregate(datasets) if (
        any(datasets, |d| d.privacy_level > operation.privacy_budget)
    )

    require: differential_privacy for statistical_operations
}

Ressourcennutzungsrichtlinien¶

Verwalten die Zuweisung von Rechenressourcen:

policy resource_governance {
    allow: allocate(resources) if (
        user.resource_quota.remaining >= resources.total &&
        operation.priority <= user.max_priority
    )

    deny: long_running_operations if system.maintenance_mode

    require: supervisor_approval for high_memory_operations
}

Richtlinienbewertungs-Engine¶

pub trait PolicyEngine {
    async fn evaluate_policy(
        &self,
        context: PolicyContext,
        action: Action
    ) -> PolicyDecision;

    async fn register_policy(&self, policy: Policy) -> Result<PolicyId>;
    async fn update_policy(&self, policy_id: PolicyId, policy: Policy) -> Result<()>;
}

pub enum PolicyDecision {
    Allow,
    Deny { reason: String },
    AllowWithConditions { conditions: Vec<PolicyCondition> },
    RequireApproval { approver: String },
}

Leistungsoptimierung¶

Richtlinien-Caching: - Kompilierte Richtlinienbewertung fuer Leistung - LRU-Cache fuer haeufige Entscheidungen - Batch-Bewertung fuer Massenoperationen - Submillisekunden-Bewertungszeiten

Inkrementelle Updates: - Echtzeit-Richtlinienaktualisierungen ohne Neustart - Versionierte Richtlinienbereitstellung - Rollback-Faehigkeiten fuer Richtlinienfehler

Cedar Policy Engine (cedar Feature)¶

Symbiont integriert die Cedar-Richtliniensprache fuer formale Autorisierung. Cedar ermoeglicht feingranulare, auditierbare Zugriffskontrollrichtlinien, die an der Policy-Gate-Phase der Reasoning-Schleife ausgewertet werden.

Standardmaessig aktiv seit v1.14.x: Cedar gehoert zum Standard-Feature-Set von symbi-runtime und ist in jeder veroeffentlichten Binary enthalten (crates.io, Docker, GitHub-Release-Tarballs). symbi up und symbi run verdrahten CedarPolicyGate beim Start automatisch aus policies/*.cedar-Dateien; ist mindestens eine Richtliniendatei vorhanden, wird das Gate mit deny_by_default() konstruiert und jede .cedar-Datei als benannte Richtlinie geladen. Sind keine Richtliniendateien vorhanden, faellt die Runtime auf den fail-closed DefaultPolicyGate::new() zurueck (der jede ToolCall- und Delegate-Aktion ablehnt). Um Cedar vollstaendig zu deaktivieren — fuer Builds, die OpaPolicyGateBridge oder ein eigenes ReasoningPolicyGate festlegen — bauen Sie mit cargo build --no-default-features --features "keychain,vector-lancedb".

cargo build --features cedar

Hauptfaehigkeiten: - Formale Verifikation: Cedar-Richtlinien koennen statisch auf Korrektheit analysiert werden - Feingranulare Autorisierung: Entitaetsbasierte Zugriffskontrolle mit hierarchischen Berechtigungen - Reasoning-Loop-Integration: CedarPolicyGate implementiert das ReasoningPolicyGate Trait und bewertet jede vorgeschlagene Aktion gegen Cedar-Richtlinien vor der Ausfuehrung - Audit-Spur: Alle Cedar-Richtlinienentscheidungen werden mit vollstaendigem Kontext protokolliert

use symbi_runtime::reasoning::cedar_gate::CedarPolicyGate;

// Cedar-Policy-Gate mit Deny-by-Default-Haltung erstellen
let cedar_gate = CedarPolicyGate::deny_by_default();
let agent_id = symbi_runtime::types::AgentId::new();
let (journal, audit) = symbi_runtime::reasoning::run_audit::open_run_journal(
    trusted_project, agent_id,
).await?;
println!("Audit: {}", serde_json::to_string(&audit)?);
let runner = ReasoningLoopRunner::builder()
    .provider(provider)
    .executor(executor)
    .policy_gate(Arc::new(cedar_gate))
    .journal(journal)
    .build();

Standardverhalten des Reasoning-Loop-Policy-Gates (nach dem v1.13.0-Audit)¶

Die Reasoning-Schleife in symbi up und symbi run ist standardmaessig fail-closed. DefaultPolicyGate::new() liefert LoopDecision::Deny fuer jede ToolCall- und Delegate-Aktion zurueck, mit der Begruendung "No policy gate configured (DefaultPolicyGate::new is fail-closed; wire OpaPolicyGateBridge or pass --insecure-allow-all)". Respond-Aktionen bleiben weiterhin erlaubt, damit der Agent weiterhin Textausgaben produzieren kann.

Diese Aenderung schliesst die Luecke, in der das Produktions-Binary zuvor DefaultPolicyGate::permissive() fest verdrahtet hatte und jede Aktion stillschweigend zuliess -- siehe SECURITY_AUDIT.md C2 fuer die Audit-Spur.

Betreiber haben zwei Pfade:

1. Ein echtes Policy-Backend anbinden (empfohlen): CedarPolicyGate, OpaPolicyGateBridge oder Ihre eigene Implementierung des Traits ReasoningPolicyGate konstruieren und an den Runner uebergeben.
2. Opt-in in den permissiven Modus fuer lokale Entwicklung: --insecure-allow-all an symbi up / symbi run uebergeben oder SYMBI_INSECURE_ALLOW_ALL=1 setzen. Bei jedem Start in diesem Modus wird ein mehrzeiliger stderr-Banner ausgegeben, und tracing::warn! feuert bei jeder ausgewerteten Aktion.

Der bisherige Konstruktor permissive() wurde in permissive_for_dev_only() umbenannt und mit #[doc(hidden)] markiert, um eine versehentliche Verwendung in Produktionscodepfaden zu verhindern.

Policy-Scoping pro Surface (seit v1.19.0)¶

Frueher luden alle Einstiegspunkte denselben flachen Satz policies/*.cedar, sodass ein permit, das fuer einen davon geschrieben wurde, stillschweigend fuer alle galt. Die Einstiegspunkte haben jedoch nicht dasselbe Bedrohungsmodell: symbi run und der HTTP-Input-Server fuehren echte Tool-Aufrufe aus, symbi shell stellt ein eigenes Toolset zum Bearbeiten von Dateien bereit, und der Chat-Koordinator von symbi up fuehrt ueberhaupt keine Tools aus.

Policies werden jetzt geschichtet:

• policies/*.cedar — gemeinsam, wird von der Gate jedes Surface geladen.
• policies/<surface>/*.cedar — wird nur von dem benannten Surface geladen.

Die Surface-Namen sind run, coordinator, http-input, managed-cli, eval und shell. symbi up baut je eine Gate pro Surface (coordinator und http-input) statt einer gemeinsamen, sodass eine Berechtigung fuer unbeaufsichtigte Webhook-Agenten nicht den Operator-Chat erreicht und umgekehrt. Beide teilen sich weiterhin eine Escalation-Queue, damit zurueckgehaltene Aktionen dieselben Genehmiger erreichen.

Flache Dateien bleiben global, sodass sich fuer bestehende Deployments nichts aendert, bis sie ein Unterverzeichnis anlegen. Reservieren Sie das flache Verzeichnis fuer Regeln, die wirklich ueberall gelten, und legen Sie alles Tool-Spezifische unter das jeweilige Surface. Beachten Sie: Mode B liest policies/managed-cli/, nicht policies/run/ — das Starten eines verwalteten Subprozesses hat einen anderen Wirkungsradius als die interne Reasoning-Schleife, und eine Policy im falschen Verzeichnis wird von nichts geladen, sieht aber genauso aus, als haette man gar keine geschrieben.

Faellt eine Gate auf fail-closed zurueck, nennt das Log beide durchsuchten Verzeichnisse.

Transport-Haertung des OPA-Backends¶

Bei Verwendung von OpaPolicyGateBridge mit SYMBIONT_OPA_URL verweigert der Client unverschluesseltes HTTP zu einem Nicht-Loopback-Host und faellt fail-closed aus (verweigert) -- ein Angreifer auf dem Pfad koennte andernfalls eine allow-Entscheidung faelschen. Klartext ist nur fuer Loopback (ein lokaler OPA-Sidecar) erlaubt oder wenn SYMBIONT_OPA_ALLOW_INSECURE=1 gesetzt ist (nur lokale Tests). Setzen Sie SYMBIONT_OPA_AUTH_TOKEN, um bei jeder Autorisierungsabfrage ein Bearer-Token mitzusenden. Verwenden Sie https:// fuer jeden entfernten OPA-Endpunkt.

Inter-Agent-Kommunikationsrichtlinie¶

Das CommunicationPolicyGate erzwingt Autorisierungsregeln fuer die gesamte Inter-Agent-Kommunikation. Jeder Aufruf ueber ask, delegate, send_to, parallel oder race wird vor der Ausfuehrung gegen Richtlinienregeln ausgewertet.

Regelstruktur: - Bedingungen: SenderIs(agent), RecipientIs(agent), Always, zusammengesetzte All/Any - Wirkungen: Allow oder Deny { reason } - Prioritaet: Regeln werden mit hoechster Prioritaet zuerst ausgewertet; erster Treffer gewinnt - Standard: Allow (rueckwaertskompatibel -- bestehende Projekte funktionieren unveraendert)

Richtlinienablehnung ist ein harter Fehler -- der aufrufende Agent erhaelt einen Fehler durch die ORGA-Schleife und kann darueber nachdenken. Alle Inter-Agent-Nachrichten werden kryptographisch ueber Ed25519 signiert und mit AES-256-GCM verschluesselt.

Beispielrichtlinie: einen Worker-Agenten daran hindern, an andere Agenten zu delegieren:

forbid(
    principal == Agent::"worker",
    action == Action::"delegate",
    resource
);

Kryptographische Sicherheit¶

Digitale Signaturen¶

Alle sicherheitsrelevanten Operationen sind kryptographisch signiert:

Signaturalgorithmus: Ed25519 (RFC 8032) - Schluesselgroesse: 256-Bit private Schluessel, 256-Bit oeffentliche Schluessel - Signaturgroesse: 512 Bits (64 Bytes) - Leistung: 70.000+ Signaturen/Sekunde, 25.000+ Verifikationen/Sekunde

pub struct MessageSignature {
    pub signature: Vec<u8>,
    pub algorithm: SignatureAlgorithm,
    pub public_key: Vec<u8>,
}

impl AuditEvent {
    pub fn sign(&mut self, private_key: &PrivateKey) -> Result<()> {
        let message = self.serialize_for_signing()?;
        self.signature = private_key.sign(&message);
        Ok(())
    }

    pub fn verify(&self, public_key: &PublicKey) -> bool {
        let message = self.serialize_for_signing().unwrap();
        public_key.verify(&message, &self.signature)
    }
}

Schluesselverwaltung¶

Schluesselspeicherung: - Hardware Security Module (HSM) Integration - Secure Enclave Unterstuetzung fuer Schluesselschutz - Schluesselrotation mit konfigurierbaren Intervallen - Verteilte Schluesselsicherung und -wiederherstellung

Schluesselhierarchie: - Root-Signierschluessel fuer Systemoperationen - Pro-Agent-Schluessel fuer Operationssignierung - Ephemere Schluessel fuer Sitzungsverschluesselung - Externe Schluessel fuer Tool-Verifikation

Geplantes Feature -- Die unten gezeigte KeyManager-API ist Teil der Sicherheits-Roadmap und noch nicht im aktuellen Release verfuegbar. Die aktuelle Implementierung stellt Schluesseldienstprogramme ueber KeyUtils in crypto.rs bereit.

pub struct KeyManager {
    hsm: HardwareSecurityModule,
    key_store: SecureKeyStore,
    rotation_policy: KeyRotationPolicy,
}

impl KeyManager {
    pub async fn generate_agent_keys(&self, agent_id: AgentId) -> Result<KeyPair>;
    pub async fn rotate_keys(&self, key_id: KeyId) -> Result<KeyPair>;
    pub async fn revoke_key(&self, key_id: KeyId) -> Result<()>;
}

Verschluesselungsstandards¶

Symmetrische Verschluesselung: AES-256-GCM - 256-Bit-Schluessel mit authentifizierter Verschluesselung - Eindeutige Nonces fuer jede Verschluesselungsoperation - Zugehoerige Daten fuer Kontextbindung

Asymmetrische Verschluesselung: X25519 + ChaCha20-Poly1305 - Elliptische Kurven-Schluesselaustausch - Stream-Verschluesselung mit authentifizierter Verschluesselung - Perfect Forward Secrecy

Nachrichtenverschluesselung:

pub fn encrypt_message(
    plaintext: &[u8],
    recipient_public_key: &PublicKey,
    sender_private_key: &PrivateKey
) -> Result<EncryptedMessage> {
    let shared_secret = sender_private_key.diffie_hellman(recipient_public_key);
    let nonce = generate_random_nonce();
    let ciphertext = ChaCha20Poly1305::new(&shared_secret)
        .encrypt(&nonce, plaintext)?;

    Ok(EncryptedMessage {
        nonce,
        ciphertext,
        sender_public_key: sender_private_key.public_key(),
    })
}

Audit und Compliance¶

Kryptographische Audit-Spur¶

Zwei Subsysteme fuehren eine signierte, hash-verkettete Aufzeichnung: die Kritiker-Audit-Kette (crates/runtime/src/reasoning/critic_audit.rs, verifiziert mit verify_chain / verify_chain_anchored) und die Sitzungstranskripte (crates/runtime/src/session/transcript.rs). Die nachfolgende Struktur beschreibt diese Ketten.

Der Branch ergaenzt zudem erforderliche geschuetzte Lauf-Journale fuer die gewoehnliche/verwaltete CLI, HTTP, geplante ORGA-Laeufe und die standardmaessige DSL-Ausfuehrung von reason()/tool_call(). Diese sind privat, dauerhaft angehaengt, Ed25519-signiert und hash-verkettet; aufrufgebundene Eintraege enthalten die Lauf-ID. Siehe Lauf-Audit fuer das tatsaechliche Format, die Schluesselverwahrung, die Verifizierung und unvollstaendige Endergebnisse.

Dies bleibt hinter einem systemweiten Audit-Log zurueck. Die zugrunde liegende JournalWriter-Schnittstelle erlaubt auf anderen Pfaden oder bei expliziter SDK-Injektion weiterhin einen gepufferten In-Memory-Writer; delegierte interne Journale werden dem Betreiber nicht alle zugaenglich gemacht. Direkte LLM-/Kompositionspfade und weitere Shell-Reasoning-Pfade muessen noch migriert werden. Die nachfolgende beispielhafte Event-Struktur beschreibt die Kritiker-/Transkript-Ketten, nicht das Wire-Format des geschuetzten Lauf-Journals.

Ein Event in diesen Ketten sieht so aus:

pub struct AuditEvent {
    pub event_id: Uuid,
    pub timestamp: SystemTime,
    pub agent_id: AgentId,
    pub event_type: AuditEventType,
    pub details: serde_json::Value,
    pub signature: Ed25519Signature,
    pub previous_hash: Hash,
    pub event_hash: Hash,
}

Audit-Event-Typen: - Agent-Lebenszyklus-Events (Erstellung, Beendigung) - Richtlinienbewertungsentscheidungen - Ressourcenzuweisung und -nutzung - Nachrichten-Versendung und -Routing - Externe Tool-Aufrufe - Sicherheitsverletzungen und Warnungen

Hash-Verkettung¶

Events sind in einer unveraenderlichen Kette verknuepft:

impl AuditChain {
    pub fn append_event(&mut self, mut event: AuditEvent) -> Result<()> {
        event.previous_hash = self.last_hash;
        event.event_hash = self.calculate_event_hash(&event);
        event.sign(&self.signing_key)?;

        self.events.push(event.clone());
        self.last_hash = event.event_hash;

        self.verify_chain_integrity()?;
        Ok(())
    }

    pub fn verify_integrity(&self) -> Result<bool> {
        for (i, event) in self.events.iter().enumerate() {
            // Verify signature
            if !event.verify(&self.public_key) {
                return Ok(false);
            }

            // Verify hash chain
            if i > 0 && event.previous_hash != self.events[i-1].event_hash {
                return Ok(false);
            }
        }
        Ok(true)
    }
}

Human Approval Relay (symbi-approval-relay)¶

Wenn eine Richtlinienentscheidung require: approval zurueckgibt, blockiert die Aktion, bis ein menschlicher Pruefer sie freigibt oder ablehnt. symbi-approval-relay ist die Crate, die diese Anfragen an einen Menschen und die Entscheidung zurueck transportiert und dabei beide Schritte pruefbar haelt.

Zweikanal-Design¶

Das Relay ist zweikanalig aufgebaut: jede Freigabe durchlaeuft zwei unabhaengige Pfade, und beide muessen uebereinstimmen, bevor die Runtime die Aktion entsperrt.

• Primaerkanal -- eine interaktive Oberflaeche fuer den Pruefer (Chat-Adapter, Web-UI, CLI-Prompt). Dort liest der Pruefer die Anfrage und entscheidet.
• Attestierungskanal -- ein unabhaengiger Verifizierungspfad (zum Beispiel ein signierter Callback, ein zweiter Operator oder eine Out-of-Band-Bestaetigung). Die Runtime entsperrt die Aktion nicht allein auf eine Freigabe ueber den Primaerkanal hin.

Diese Struktur schlaegt den Einkanal-Kompromissfall: Ein Angreifer, der den Primaerkanal uebernimmt, kann dennoch keine Freigaben erteilen, da der Attestierungskanal sein Vertrauen nicht mit ihm teilt.

Was das Relay transportiert¶

Jede laufende Freigabeanforderung enthaelt: - Die Agent-Identitaet (AgentPin-verankert) und die Richtlinienentscheidung, die die Anfrage ausgeloest hat - Den vollstaendigen Aktionskontext -- Tool-Aufruf, Ressource, Argumente -- als Hash, damit Pruefer bestaetigen koennen, dass sie diese Aktion und keine ausgetauschte freigegeben haben - Eine Frist, nach der die Anfrage automatisch abgelehnt wird - Korrelations-IDs, damit der Audit-Trail die Entscheidungen beider Kanaele einer einzigen Aktion zuordnet

Freigaben und Ablehnungen werden in derselben kryptographisch manipulationssicheren Audit-Kette aufgezeichnet wie jede andere Runtime-Entscheidung. Ein menschliches "Ja" ist eine Entscheidung im Protokoll, kein Bypass desselben.

Wo es eingesetzt wird¶

• Cedar-Richtlinien, die RequireApproval { approver: "..." }-Urteile ausgeben
• Destruktive oder hochprivilegierte Tool-Aufrufe, abgesichert durch ToolClad-approval-Hooks
• Geplante Jobs mit one_shot = true plus einer Freigaberichtlinie
• Jeder DSL-policy-Block, der require: <role>_approval nennt

Ist kein Relay konfiguriert, scheitern freigabepflichtige Aktionen fail-closed -- sie werden abgelehnt, nicht stillschweigend zugelassen.

Tool-Sicherheit mit SchemaPin¶

Tool-Verifikationsprozess¶

Externe Tools werden mit kryptographischen Signaturen verifiziert:

sequenceDiagram
    participant Tool as Tool Provider
    participant SP as SchemaPin
    participant Runtime as Symbiont Runtime
    participant Agent as Agent

    Tool->>Tool: Sign schema with provider private key
    Tool->>SP: Publish signed schema + public key

    Agent->>Runtime: Request Tool Use
    Runtime->>SP: Verify schema signature against pinned key
    SP-->>Runtime: Verification Result (valid / invalid / unknown key)
    Runtime-->>Agent: Allow/Deny Tool Use

Hinweis: Die SchemaPin-Verifikation ist rein kryptographisch -- Signaturvalidierung und Schluessel-Pinning (TOFU). Sie fuehrt keine KI- oder menschliche Ueberpruefung des Tool-Verhaltens durch; das ist eine separate, geplante Faehigkeit, die weiter unten im Abschnitt KI-gesteuerte Tool-Ueberpruefung beschrieben wird.

Trust-On-First-Use (TOFU)¶

Schluessel-Pinning-Prozess: 1. Erste Begegnung mit einem Tool-Anbieter 2. Oeffentlichen Schluessel des Anbieters ueber externe Kanaele verifizieren 3. Oeffentlichen Schluessel im lokalen Trust Store anheften 4. Angehefteten Schluessel fuer alle zukuenftigen Verifikationen verwenden

Geplantes Feature -- Die unten gezeigte TOFUKeyStore-API ist Teil der Sicherheits-Roadmap und noch nicht im aktuellen Release verfuegbar.

pub struct TOFUKeyStore {
    pinned_keys: HashMap<ProviderId, PinnedKey>,
    trust_policies: Vec<TrustPolicy>,
}

impl TOFUKeyStore {
    pub async fn pin_key(&mut self, provider: ProviderId, key: PublicKey) -> Result<()> {
        if self.pinned_keys.contains_key(&provider) {
            return Err("Key already pinned for provider");
        }

        self.pinned_keys.insert(provider, PinnedKey {
            public_key: key,
            pinned_at: SystemTime::now(),
            trust_level: TrustLevel::Unverified,
        });

        Ok(())
    }

    pub fn verify_tool(&self, tool: &MCPTool) -> VerificationResult {
        if let Some(pinned_key) = self.pinned_keys.get(&tool.provider_id) {
            if pinned_key.public_key.verify(&tool.schema_hash, &tool.signature) {
                VerificationResult::Trusted
            } else {
                VerificationResult::SignatureInvalid
            }
        } else {
            VerificationResult::UnknownProvider
        }
    }
}

KI-gesteuerte Tool-Ueberpruefung¶

Automatisierte Sicherheitsanalyse vor Tool-Genehmigung:

Analysekomponenten: - Sicherheitsluecken-Erkennung: Musterabgleich gegen bekannte Sicherheitsluecken-Signaturen - Schaedlicher Code-Erkennung: ML-basierte Identifikation von boesartigem Verhalten - Ressourcennutzungsanalyse: Bewertung von Rechenressourcenanforderungen - Datenschutz-Folgenabschaetzung: Datenbehandlung und Datenschutzauswirkungen

Geplantes Feature -- Die unten gezeigte SecurityAnalyzer-API ist Teil der Sicherheits-Roadmap und noch nicht im aktuellen Release verfuegbar.

pub struct SecurityAnalyzer {
    vulnerability_patterns: VulnerabilityDatabase,
    ml_detector: MaliciousCodeDetector,
    resource_analyzer: ResourceAnalyzer,
    privacy_assessor: PrivacyAssessor,
}

impl SecurityAnalyzer {
    pub async fn analyze_tool(&self, tool: &MCPTool) -> SecurityAnalysis {
        let mut findings = Vec::new();

        // Vulnerability pattern matching
        findings.extend(self.vulnerability_patterns.scan(&tool.schema));

        // ML-based detection
        let ml_result = self.ml_detector.analyze(&tool.schema).await?;
        findings.extend(ml_result.findings);

        // Resource usage analysis
        let resource_risk = self.resource_analyzer.assess(&tool.schema);

        // Privacy impact assessment
        let privacy_impact = self.privacy_assessor.evaluate(&tool.schema);

        SecurityAnalysis {
            tool_id: tool.id.clone(),
            risk_score: calculate_risk_score(&findings),
            findings,
            resource_requirements: resource_risk,
            privacy_impact,
            recommendation: self.generate_recommendation(&findings),
        }
    }
}

ClawHavoc Skill-Scanner¶

Der ClawHavoc-Scanner bietet inhaltsbezogene Verteidigung fuer Agent-Skills. Jede Skill-Datei wird Zeile fuer Zeile vor dem Laden gescannt, und Befunde mit Critical- oder High-Schweregrad blockieren die Ausfuehrung des Skills.

Schweregrad-Modell¶

Erkennungskategorien (40 Regeln)¶

Urspruengliche Verteidigungsregeln (10) - pipe-to-shell, wget-pipe-to-shell -- Entfernte Code-Ausfuehrung ueber weitergeleitete Downloads - eval-with-fetch, fetch-with-eval -- Code-Injektion ueber eval + Netzwerk - base64-decode-exec -- Verschleierte Ausfuehrung ueber Base64-Dekodierung - soul-md-modification, memory-md-modification -- Identitaetsmanipulation - rm-rf-pattern -- Destruktive Dateisystemoperationen - env-file-reference, chmod-777 -- Sensibler Dateizugriff, weltbeschreibbare Berechtigungen

Reverse Shells (7) -- Critical Schweregrad - reverse-shell-bash, reverse-shell-nc, reverse-shell-ncat, reverse-shell-mkfifo, reverse-shell-python, reverse-shell-perl, reverse-shell-ruby

Credential Harvesting (6) -- High Schweregrad - credential-ssh-keys, credential-aws, credential-cloud-config, credential-browser-cookies, credential-keychain, credential-etc-shadow

Netzwerk-Exfiltration (3) -- High Schweregrad - exfil-dns-tunnel, exfil-dev-tcp, exfil-nc-outbound

Prozessinjektion (4) -- Critical Schweregrad - injection-ptrace, injection-ld-preload, injection-proc-mem, injection-gdb-attach

Privilegien-Eskalation (5) -- High Schweregrad - privesc-sudo, privesc-setuid, privesc-setcap, privesc-chown-root, privesc-nsenter

Symlink- / Pfadtraversal (2) -- Medium Schweregrad - symlink-escape, path-traversal-deep

Downloader-Ketten (3) -- Medium Schweregrad - downloader-curl-save, downloader-wget-save, downloader-chmod-exec

Ausfuehrbare-Whitelisting¶

Der AllowedExecutablesOnly-Regeltyp beschraenkt, welche ausfuehrbaren Dateien ein Agent-Skill aufrufen kann:

// Nur diese Ausfuehrbaren erlauben -- alles andere wird blockiert
ScanRule::AllowedExecutablesOnly(vec![
    "python3".into(),
    "node".into(),
    "cargo".into(),
])

Benutzerdefinierte Regeln¶

Domaenenspezifische Muster koennen neben den ClawHavoc-Standards hinzugefuegt werden:

let mut scanner = SkillScanner::new();
scanner.add_custom_rule(
    "block-internal-api",
    r"internal\.corp\.example\.com",
    ScanSeverity::High,
    "References to internal API endpoints are not allowed in skills",
);

Bereinigung unsichtbarer Zeichen (symbi-invis-strip)¶

symbi-invis-strip ist ein abhaengigkeitsfreier Utility-Crate, der im gesamten Runtime verwendet wird, um Zeichen zu entfernen, die als nichts gerendert werden, aber die Bedeutung veraendern -- die klassische Nutzlast fuer Prompt-Injection- und Richtlinien-Umgehungs-Angriffe.

Was es entfernt¶

• ASCII C0 (0x00--0x1F) und DEL (0x7F), ausser \t \n \r
• ASCII C1 (0x80--0x9F)
• Zero-Width-Zeichen (ZWSP, ZWNJ, ZWJ)
• Bidirektionale Overrides (LRO, RLO, PDF, LRE, RLE, LRI, RLI, FSI, PDI)
• Word Joiner und den Block unsichtbarer Operatoren
• Byte-Order-Marks (BOM)
• Variation Selectors (VS1--VS16 und ergaenzende VS17--VS256)
• Zeichen im Unicode-Tag-Block (U+E0000--U+E007F)

Wo es laeuft¶

• Eingehende Chat- und Webhook-Payloads -- bevor sie den Orchestrator erreichen
• Tool-Call-Argumente -- bevor sie die Cedar-Evaluierung erreichen
• Skill- und Agent-DSL-Inhalte -- vor Scanner und Parser

Optionale Markup-Entfernung¶

Die optionale sanitize_field_with_markup-Variante entfernt zusaetzlich: - <!-- ... --> HTML-Kommentare - Dreifach-Backtick-Fenced-Codebloecke

Markup-Entfernung ist fuer Oberflaechen geeignet, auf denen vom Renderer verborgenes Markup keine legitime Nutzung hat -- beispielsweise kurze Felder fuer Richtlinienbegruendungen oder reine Anzeige-Metadaten. Sie wird nicht auf Felder angewendet, die legitim Markdown oder Code tragen (wie Agent-Quellcode, Richtlinientexte oder Tool-Ausgaben).

Cedar Policy Linter¶

.github/scripts/lint-cedar-policies.py ist ein statischer Analyse-Pass, der auf jeder .cedar-Datei im Repository ausgefuehrt wird. Er faengt eine Klasse von Angriffen ab, bei denen ein boeswilliger (oder kompromittierter) Authoring-Flow eine Richtlinie schreibt, die korrekt aussieht, aber Zeichen enthaelt, die eine andere Autorisierungsentscheidung erzeugen, als der Reviewer erwartet.

Was er abfaengt¶

• Homoglyph-Bezeichner -- kyrillisches а (U+0430), das sich als lateinisches a ausgibt, griechisches ο (U+03BF) als lateinisches o und aehnliche Verwechslungen in Principal-, Action- oder Resource-Namen.
• Unsichtbare Steuerzeichen innerhalb von Bezeichnern, String-Literalen oder zwischen Tokens.

Wo er laeuft¶

• Pre-Commit-Hook -- blockiert Commits, die eine der beiden Problemklassen einfuehren.
• CI -- dieselbe Pruefung ist ein erforderlicher Test-Job, sodass Commits, die den Hook umgehen (via --no-verify), trotzdem in CI fehlschlagen.

Kombiniert mit symbi-invis-strip auf dem Datenpfad schliesst der Linter den Authoring-Pfad-Vektor: unsichtbare Tricks koennen nicht in das Repo gelangen, und solche, die zur Laufzeit durchrutschen, werden vor der Richtlinienevaluierung entfernt.

Netzwerksicherheit¶

Sichere Kommunikation¶

Transport Layer Security: - TLS 1.3 fuer alle externe Kommunikation - Mutual TLS (mTLS) fuer Service-zu-Service-Kommunikation - Zertifikat-Pinning fuer bekannte Services - Perfect Forward Secrecy

Nachrichten-Level-Sicherheit: - Ende-zu-Ende-Verschluesselung fuer Agent-Nachrichten - Message Authentication Codes (MAC) - Replay-Angriff-Praevention mit Zeitstempeln - Nachrichten-Reihenfolgen-Garantien

pub struct SecureChannel {
    encryption_key: [u8; 32],
    mac_key: [u8; 32],
    send_counter: AtomicU64,
    recv_counter: AtomicU64,
}

impl SecureChannel {
    pub fn encrypt_message(&self, plaintext: &[u8]) -> Result<Vec<u8>> {
        let counter = self.send_counter.fetch_add(1, Ordering::SeqCst);
        let nonce = self.generate_nonce(counter);

        let ciphertext = ChaCha20Poly1305::new(&self.encryption_key)
            .encrypt(&nonce, plaintext)?;

        let mac = Hmac::<Sha256>::new_from_slice(&self.mac_key)?
            .chain_update(&ciphertext)
            .chain_update(&counter.to_le_bytes())
            .finalize()
            .into_bytes();

        Ok([ciphertext, mac.to_vec()].concat())
    }
}

Netzwerkisolation¶

Sandbox-Netzwerkkontrolle: - Standardmaessig kein Netzwerkzugriff - Explizite Allowlist fuer externe Verbindungen - Traffic-Ueberwachung und Anomalieerkennung - DNS-Filterung und -Validierung

Netzwerkrichtlinien:

network_policy:
  default_action: "deny"
  allowed_destinations:
    - domain: "api.openai.com"
      ports: [443]
      protocol: "https"
    - ip_range: "10.0.0.0/8"
      ports: [6333]  # Qdrant (only needed if using optional Qdrant backend)
      protocol: "http"

  monitoring:
    log_all_connections: true
    detect_anomalies: true
    rate_limiting: true

Incident Response¶

Sicherheitsereignis-Erkennung¶

Automatisierte Erkennung: - Richtlinienverletzungsueberwachung - Anomales Verhaltenserkennung - Ressourcennutzungsanomalien - Fehlgeschlagene Authentifizierungsverfolgung

Alert-Klassifikation:

pub enum ViolationSeverity {
    Info,       // Normale Sicherheitsereignisse
    Warning,    // Geringfuegige Richtlinienverletzungen
    Error,      // Bestaetigte Sicherheitsprobleme
    Critical,   // Aktive Sicherheitsverletzungen
}

pub struct SecurityEvent {
    pub id: Uuid,
    pub timestamp: SystemTime,
    pub severity: ViolationSeverity,
    pub category: SecurityEventCategory,
    pub description: String,
    pub affected_components: Vec<ComponentId>,
    pub recommended_actions: Vec<String>,
}

Incident Response Workflow¶

graph TB
    A[Security Event] --> B[Event Classification]
    B --> C{Severity Level}

    C -->|Info/Low| D[Log Event]
    C -->|Medium| E[Alert Security Team]
    C -->|High| F[Automatic Mitigation]
    C -->|Critical| G[Emergency Response]

    F --> H[Isolate Affected Components]
    F --> I[Revoke Compromised Credentials]
    F --> J[Preserve Evidence]

    G --> H
    G --> K[Notify Leadership]
    G --> L[External Incident Response]

Wiederherstellungsverfahren¶

Automatisierte Wiederherstellung: - Agent-Neustart mit sauberem Zustand - Schluesselrotation fuer kompromittierte Anmeldedaten - Richtlinienaktualisierungen zur Wiederholungsverhinderung - Systemgesundheitsverifikation

Manuelle Wiederherstellung: - Forensische Analyse von Sicherheitsereignissen - Ursachenanalyse und Remediation - Sicherheitskontrollaktualisierungen - Vorfallsdokumentation und Lessons Learned

Sicherheits-Best-Practices¶

Entwicklungsrichtlinien¶

1. Secure by Default: Alle Sicherheitsfeatures standardmaessig aktiviert
2. Principle of Least Privilege: Minimale Berechtigungen fuer alle Operationen
3. Defense in Depth: Mehrere Sicherheitsschichten mit Redundanz
4. Fail Securely: Sicherheitsfehler sollten Zugriff verweigern, nicht gewaehren
5. Audit Everything: Vollstaendige Protokollierung sicherheitsrelevanter Operationen

Deployment-Sicherheit¶

Umgebungshaertung:

# Disable unnecessary services
systemctl disable cups bluetooth

# Kernel hardening
echo "kernel.dmesg_restrict=1" >> /etc/sysctl.conf
echo "kernel.kptr_restrict=2" >> /etc/sysctl.conf

# File system security
mount -o remount,nodev,nosuid,noexec /tmp

Container-Sicherheit:

# Use minimal base image
FROM scratch
COPY --from=builder /app/symbiont /bin/symbiont

# Run as non-root user
USER 1000:1000

# Set security options
LABEL security.no-new-privileges=true

Operative Sicherheit¶

Ueberwachungs-Checkliste: - [ ] Echtzeit-Sicherheitsereignisueberwachung - [ ] Richtlinienverletzungsverfolgung - [ ] Ressourcennutzungsanomalieerkennung - [ ] Fehlgeschlagene Authentifizierungsueberwachung - [ ] Zertifikatsablaufverfolgung

Wartungsverfahren: - Regelmaessige Sicherheitsupdates und Patches - Geplante Schluesselrotation - Richtlinienueberpruefung und -aktualisierungen - Sicherheitsaudit und Penetrationstests - Incident Response Plan Tests

Sicherheitskonfiguration¶

Umgebungsvariablen¶

# Cryptographic settings
export SYMBIONT_CRYPTO_PROVIDER=ring
export SYMBIONT_KEY_STORE_TYPE=hsm
export SYMBIONT_HSM_CONFIG_PATH=/etc/symbiont/hsm.conf

# Audit settings
export SYMBIONT_AUDIT_ENABLED=true
export SYMBIONT_AUDIT_STORAGE=/var/audit/symbiont
export SYMBIONT_AUDIT_RETENTION_DAYS=2555  # 7 years

# Security policies
export SYMBIONT_POLICY_ENFORCEMENT=strict
export SYMBIONT_DEFAULT_SANDBOX_TIER=gvisor
export SYMBIONT_TOFU_ENABLED=true

Sicherheitskonfigurationsdatei¶

[security]
# Cryptographic settings
crypto_provider = "ring"
signature_algorithm = "ed25519"
encryption_algorithm = "chacha20_poly1305"

# Key management
key_rotation_interval_days = 90
hsm_enabled = true
hsm_config_path = "/etc/symbiont/hsm.conf"

# Audit settings
audit_enabled = true
audit_storage_path = "/var/audit/symbiont"
audit_retention_days = 2555
audit_compression = true

# Sandbox security
default_sandbox_tier = "gvisor"
sandbox_escape_detection = true
resource_limit_enforcement = "strict"

# Network security
tls_min_version = "1.3"
certificate_pinning = true
network_isolation = true

# Policy enforcement
policy_enforcement_mode = "strict"
policy_violation_action = "deny_and_alert"
emergency_override_enabled = false

[tofu]
enabled = true
key_verification_required = true
trust_on_first_use_timeout_hours = 24
automatic_key_pinning = false

Sicherheitsmetriken¶

Key Performance Indicators¶

Sicherheitsoperationen: - Richtlinienbewertungslatenz: Durchschnitt <1ms - Audit-Event-Generierungsrate: 10.000+ Events/Sekunde - Sicherheitsvorfallreaktionszeit: <5 Minuten - Kryptographischer Operationsdurchsatz: 70.000+ Ops/Sekunde

Compliance-Metriken: - Richtlinien-Compliance-Rate: >99,9% - Audit-Spur-Integritaet: 100% - Sicherheitsereignis-False-Positive-Rate: <1% - Vorfallaufloesungszeit: <24 Stunden

Risikobewertung: - Sicherheitsluecken-Patch-Zeit: <48 Stunden - Sicherheitskontrolleffektivitaet: >95% - Bedrohungserkennungsgenauigkeit: >99% - Recovery Time Objective: <1 Stunde

Zukuenftige Verbesserungen¶

Erweiterte Kryptographie¶

Post-Quantum-Kryptographie: - NIST-genehmigte Post-Quantum-Algorithmen - Hybride klassische/Post-Quantum-Schemas - Migrationsplaene fuer Quantenbedrohungen

Homomorphe Verschluesselung: - Datenschutzwahrende Berechnung auf verschluesselten Daten - CKKS-Schema fuer approximative Arithmetik - Integration mit Machine Learning Workflows

Zero-Knowledge Proofs: - zk-SNARKs fuer Berechnungsverifikation - Datenschutzwahrende Authentifizierung - Compliance-Beweisgenerierung

KI-verstaerkte Sicherheit¶

Verhaltensanalyse: - Machine Learning fuer Anomalieerkennung - Praediktive Sicherheitsanalysen - Adaptive Bedrohungsreaktion

Automatisierte Antwort: - Selbstheilende Sicherheitskontrollen - Dynamische Richtliniengenerierung - Intelligente Vorfallklassifizierung

Naechste Schritte¶

• Beitraege - Sicherheitsentwicklungsrichtlinien
• Runtime-Architektur - Technische Implementierungsdetails
• API-Referenz - Sicherheits-API-Dokumentation

Das Symbiont-Sicherheitsmodell bietet unternehmenstauglichen Schutz fuer regulierte Industrien und Hochsicherheitsumgebungen. Sein geschichteter Ansatz gewaehrleistet robusten Schutz vor sich entwickelnden Bedrohungen bei gleichzeitiger Aufrechterhaltung der betrieblichen Effizienz.