English | 中文简体 | Español | Português | 日本語 | Deutsch
Richtliniengesteuerte Agenten-Laufzeitumgebung fuer den Produktionseinsatz. Derselbe Agent. Sichere Laufzeitumgebung.
Was Sie hier sehen: ein echtes Modell (
claude-haiku-4.5) fordert die Auflistung der Agentenflotte an. Eine Cedar-forbid-Regel verweigert den Aufruf bei jedem erneuten Versuch -- keine Code-Aenderung, nur policy. Reproduzieren Sie es mit einem einzigen Befehl ↓ · ▶ Vollstaendiger Walkthrough
Symbiont ist eine Rust-native Laufzeitumgebung fuer die Ausfuehrung von KI-Agenten und Tools unter expliziter Richtlinien-, Identitaets- und Audit-Kontrolle.
Die meisten Agenten-Frameworks konzentrieren sich auf Orchestrierung. Symbiont konzentriert sich darauf, was passiert, wenn Agenten in realen Umgebungen mit echten Risiken ausgefuehrt werden muessen: nicht vertrauenswuerdige Tools, sensible Daten, Genehmigungsgrenzen, Audit-Anforderungen und wiederholbare Durchsetzung.
KI-Agenten sind leicht zu demonstrieren und schwer zu vertrauen.
Sobald ein Agent Tools aufrufen, auf Dateien zugreifen, Nachrichten senden oder externe Dienste nutzen kann, braucht man mehr als Prompts und Glue-Code. Man braucht:
- Richtliniendurchsetzung fuer das, was ein Agent tun darf -- eingebaute DSL und Cedar-Autorisierung
- Tool-Verifikation, damit die Ausfuehrung kein blindes Vertrauen ist -- SchemaPin kryptografische Verifikation von MCP-Tools
- Tool-Vertraege, die regeln, wie Tools ausgefuehrt werden -- ToolClad deklarative Argumentvalidierung, Scope-Durchsetzung und Injection-Schutz
- Agenten-Identitaet, damit man weiss, wer handelt -- AgentPin domaingebundene ES256-Identitaet
- Sandboxing fuer riskante Workloads -- waehlen Sie Docker, gVisor (
runsc) oder Firecracker-microVM pro Agent - Audit-Trails fuer das, was passiert ist und warum -- kryptografisch manipulationssichere Logs
- Genehmigungsgates fuer sensible Aktionen -- menschliche Ueberpruefung vor der Ausfuehrung, wenn die Richtlinie es erfordert
Symbiont ist fuer diese Schicht gebaut.
Symbiont ist die Referenzimplementierung des Open Agent Trust Stack (OATS) -- einer offenen Spezifikation (CC BY 4.0) zur Absicherung der Ausfuehrung von KI-Agenten durch strukturelle Durchsetzung statt nachgelagerter Interception ("define what is permitted and make everything else structurally inexpressible" -- definiere, was erlaubt ist, und mache alles Uebrige strukturell unausdrueckbar). Die OATS-Spezifikation basiert auf den operativen Produktionserfahrungen von Symbiont, und das Design von Symbiont entspricht direkt den OATS-Schichten:
| OATS-Schicht | Symbiont-Zuordnung |
|---|---|
| Layer 1 -- ORGA Loop (typestate-erzwungenes Observe-Reason-Gate-Act) | crates/runtime/src/reasoning/ -- typestate-erzwungene Phasen; das Policy-Gate ist zur Compile-Zeit nicht umgehbar. Siehe Wanger 2026 / DOI 10.5281/zenodo.19896446. |
| Layer 2 -- Tool Contracts | ToolClad deklarative .clad.toml-Manifeste + der agent_summary-Typestate-Zaun in crates/runtime/src/toolclad/. Siehe Wanger 2026 / DOI 10.5281/zenodo.19957596. |
| Layer 3 -- Identity | SchemaPin fuer MCP-Tools + AgentPin ES256 domaingebundene Agenten-Identitaet. |
| Layer 4 -- Policy Engine | Cedar-Policy-Gate (crates/runtime/src/reasoning/cedar_gate.rs) + CommunicationPolicyGate fuer Inter-Agent-Aufrufe; beide seit v1.14.0 standardmaessig fail-closed. |
| Layer 5 -- Audit Journal | Hash-verkettetes, Ed25519-signiertes BufferedJournal in der Reasoning-Schleife; verschluesselte Modell-I/O-Logs in crates/runtime/src/logging.rs. |
Symbiont entspricht OATS Extended (C1-C7 + E1-E8). Der empirische Vergleich von Runtimes mit struktureller Durchsetzung, der der Spezifikation zugrunde liegt, ist Wanger 2026 / DOI 10.5281/zenodo.20043247.
Ein Cedar-forbid blockiert ein privilegiertes Tool, waehrend ein sicheres durchgelassen wird. Kopieren Sie dies und fuehren Sie es gegen das veroeffentlichte Image aus (kein Klon, kein Build):
docker run --rm --entrypoint sh ghcr.io/thirdkeyai/symbi:latest -c '
mkdir -p /tmp/p && cat > /tmp/p/policy.cedar <<EOF
forbid(principal, action == Symbi::Action::"tool_call::list_agents", resource);
permit(principal, action == Symbi::Action::"tool_call::system_health", resource);
EOF
echo "{\"tool_name\":\"list_agents\"}" | symbi policy evaluate --stdin --policies /tmp/p --json
echo "{\"tool_name\":\"system_health\"}" | symbi policy evaluate --stdin --policies /tmp/p --json'{"decision":"deny","reason":"deny policies matched: policy_0","tool":"list_agents", ...}
{"decision":"allow","reason":"allow policies matched: policy_1","tool":"system_health", ...}Das ist dasselbe Cedar-Gate, das die Laufzeitumgebung in die Live-Reasoning-Schleife einbindet -- genau die Ablehnung, die in der Demo oben gezeigt wird.
# Linux / macOS — installs the `symbi` binary to /usr/local/bin
curl -fsSL https://symbiont.dev/install.sh | bash
symbi --helpDer Installer laedt das vorgefertigte Release-Binary fuer Ihre Plattform herunter. Fixieren Sie eine Version mit bash -s -- --version v1.15.2 oder aendern Sie das Zielverzeichnis mit --dir. Bevorzugen Sie Docker oder das Erstellen aus Quellcode? Beides finden Sie weiter unten.
- Docker (empfohlen) oder Rust 1.82+
# 1. Create the project in the current directory.
# Generates symbiont.toml, agents/, policies/, docker-compose.yml, and
# a .env with a freshly generated SYMBIONT_MASTER_KEY.
docker run --rm -v $(pwd):/workspace ghcr.io/thirdkeyai/symbi:latest \
init --profile assistant --no-interact --dir /workspace
# 2. Start the runtime. Reads .env automatically.
docker compose upDas war's -- Runtime-API auf http://localhost:8080, HTTP Input auf http://localhost:8081.
Verwenden Sie symbi init --catalog list (oder das Docker-Aequivalent), um vorgefertigte Agenten zu durchsuchen.
# Ad-hoc runtime without a project (ephemeral, no master key)
docker run --rm -p 8080:8080 -p 8081:8081 ghcr.io/thirdkeyai/symbi:latest up
# MCP server only
docker run --rm -p 8080:8080 ghcr.io/thirdkeyai/symbi:latest mcp
# Parse an agent definition (`.symbi`; legacy `.dsl` also accepted)
docker run --rm -v $(pwd):/workspace ghcr.io/thirdkeyai/symbi:latest \
dsl -f /workspace/agent.symbicargo build --release
./target/release/symbi --help
# Scaffold a project locally, then start the runtime
./target/release/symbi init --profile assistant --no-interact
./target/release/symbi upFuer Produktionsdeployments lesen Sie
SECURITY.mdund den Deployment-Leitfaden, bevor Sie nicht vertrauenswuerdige Tool-Ausfuehrung aktivieren.
Symbiont trennt die Absicht des Agenten von der Ausfuehrungsberechtigung:
- Agenten schlagen Aktionen durch die Reasoning-Schleife vor (Observe-Reason-Gate-Act)
- Die Laufzeitumgebung evaluiert jede Aktion gegen Richtlinien-, Identitaets- und Vertrauenspruefungen
- Richtlinien entscheiden -- erlaubte Aktionen werden ausgefuehrt; abgelehnte Aktionen werden blockiert oder zur Genehmigung weitergeleitet
- Alles wird protokolliert -- manipulationssicherer Audit-Trail fuer jede Entscheidung
Modellausgaben werden niemals als Ausfuehrungsberechtigung behandelt. Die Laufzeitumgebung kontrolliert, was tatsaechlich passiert.
Ein Agent versucht, ein nicht verifiziertes MCP-Tool aufzurufen. Die Laufzeitumgebung:
- Prueft den SchemaPin-Verifikationsstatus -- Tool-Signatur fehlt oder ist ungueltig
- Evaluiert die Cedar-Richtlinie --
forbid(action == Action::"tool_call") when { !resource.verified } - Blockiert die Ausfuehrung und protokolliert die Ablehnung mit vollstaendigem Kontext
- Leitet optional an einen Operator zur manuellen Genehmigung weiter
Keine Code-Aenderung erforderlich. Die Richtlinie steuert die Ausfuehrung.
agent secure_analyst(input: DataSet) -> Result {
policy access_control {
allow: read(input) if input.verified == true
deny: send_email without approval
audit: all_operations
}
with memory = "persistent", requires = "approval" {
result = analyze(input);
return result;
}
}
Den vollstaendigen DSL-Leitfaden mit metadata-, schedule-, webhook- und channel-Bloecken finden Sie im DSL-Leitfaden.
Dateiendung: Symbiont-Agentendefinitionen verwenden
.symbials ihre kanonische Endung (z. B.agents/assistant.symbi). Die alte Endung.dslwird zur Abwaertskompatibilitaet weiterhin unbegrenzt geparst, aber neue Projekte, die mitsymbi initangelegt werden, sowie alle Beispiele in diesem Repository verwenden.symbi.
| Faehigkeit | Beschreibung |
|---|---|
| Policy Engine | Feingranulare Cedar-Autorisierung fuer Agenten-Aktionen, Tool-Aufrufe und Ressourcenzugriff |
| Tool-Verifikation | SchemaPin kryptografische Verifikation von MCP-Tool-Schemas vor der Ausfuehrung |
| Tool-Vertraege | ToolClad deklarative Vertraege mit Argumentvalidierung, Scope-Durchsetzung und Cedar-Policy-Generierung |
| Agenten-Identitaet | AgentPin domaingebundene ES256-Identitaet fuer Agenten und geplante Aufgaben |
| Reasoning-Schleife | Typestate-erzwungener Observe-Reason-Gate-Act-Zyklus mit Richtlinien-Gates und Circuit-Breakern |
| Sandboxing | Docker, gVisor (runsc) oder Firecracker-microVM -- pro Agent waehlbar ueber den DSL-Block with { sandbox = ... } |
| Audit-Logging | Manipulationssichere Logs mit strukturierten Datensaetzen fuer jede Richtlinienentscheidung |
| Secrets Management | Vault/OpenBao-Integration, AES-256-GCM-verschluesselter Speicher, pro Agent begrenzt |
| MCP-Integration | Native Model Context Protocol-Unterstuetzung mit gesteuertem Tool-Zugriff |
Weitere Faehigkeiten: Bedrohungsscanning fuer Tool-/Skill-Inhalte (40 Regeln, 10 Angriffskategorien), Cron-Scheduling, persistenter Agentenspeicher, hybride RAG-Suche (LanceDB/Qdrant), Webhook-Verifikation, Delivery-Routing, OTLP-Telemetrie, HTTP-Sicherheitshardening und Governance-Plugins fuer Claude Code und Gemini CLI. Details finden Sie in der vollstaendigen Dokumentation.
Repraesentative Benchmarks sind im Benchmark-Harness und in den Schwellenwerttests verfuegbar.
Symbiont basiert auf einem einfachen Prinzip: Modellausgaben sollten niemals als Ausfuehrungsberechtigung vertraut werden.
Aktionen durchlaufen Laufzeitkontrollen:
- Zero Trust -- alle Agenten-Eingaben sind standardmaessig nicht vertrauenswuerdig
- Richtlinienpruefungen -- Cedar-Autorisierung vor jedem Tool-Aufruf und Ressourcenzugriff
- Tool-Verifikation -- SchemaPin kryptografische Verifikation von Tool-Schemas
- Sandbox-Grenzen -- waehlen Sie die Isolationsstufe pro Agent: Docker (Standard), gVisor (
runsc-Syscall-Filter) oder Firecracker (microVM) - Operator-Genehmigung -- menschliche Ueberpruefungsgates fuer sensible Aktionen
- Secrets-Kontrolle -- Vault/OpenBao-Backends, verschluesselter lokaler Speicher, Agenten-Namespaces
- Audit-Logging -- kryptografisch manipulationssichere Aufzeichnungen jeder Entscheidung
Wenn Sie nicht vertrauenswuerdigen Code oder riskante Tools ausfuehren, verlassen Sie sich nicht auf ein schwaches lokales Ausfuehrungsmodell als einzige Grenze. Siehe SECURITY.md und die Sicherheitsmodell-Dokumentation.
| Crate | Beschreibung |
|---|---|
symbi |
Einheitliches CLI-Binary |
symbi-runtime |
Kern-Agenten-Laufzeitumgebung und Ausfuehrungsengine |
symbi-dsl |
DSL-Parser und -Evaluator |
symbi-channel-adapter |
Slack/Teams/Mattermost-Adapter |
repl-core / repl-proto / repl-cli |
Interaktive REPL und JSON-RPC-Server |
repl-lsp |
Language Server Protocol-Unterstuetzung |
symbi-shell |
Interaktive TUI fuer Autorenerstellung, Orchestrierung und Remote-Attach (Beta) |
symbi-a2ui |
Admin-Dashboard (Lit/TypeScript, Alpha) |
Governance-Plugins: symbi-claude-code | symbi-gemini-cli
- Erste Schritte
- Sicherheitsmodell
- Runtime-Architektur
- Reasoning-Loop-Leitfaden
- DSL-Leitfaden
- API-Referenz
Wenn Sie Symbiont fuer den Produktionseinsatz evaluieren, beginnen Sie mit dem Sicherheitsmodell und der Erste-Schritte-Dokumentation.
Offizielle Client-SDKs zur Integration der Symbiont-Laufzeitumgebung in Ihre Anwendung:
| Sprache | Paket | Repository |
|---|---|---|
| JavaScript/TypeScript | symbiont-sdk-js | GitHub |
| Python | symbiont-sdk | GitHub |
Empfehlung fuer den Produktionseinsatz: Die JS- und Python-SDKs sind HTTP-Clients fuer die Anwendungsintegration und Prototyping. Fuer produktive Agenten-Workloads empfehlen wir, direkt auf der Rust-Implementierung aufzubauen, um die vollstaendigen typestate-gesteuerten Sicherheitsgarantien von Symbiont zu nutzen -- Capability-Autorisierung, Richtliniendurchsetzung und Lifecycle-Invarianten, die zur Compile-Zeit statt zur Laufzeit erzwungen werden. Clients in dynamischen Sprachen koennen diese Eigenschaften erst pruefen, nachdem eine Anfrage die Laufzeitgrenze ueberschritten hat.
- Community Edition (Apache 2.0): Kern-Laufzeitumgebung, DSL, Policy Engine, Tool-Verifikation, Sandboxing, Agentenspeicher, Scheduling, MCP-Integration, RAG, Audit-Logging und alle CLI/REPL-Werkzeuge.
- Enterprise Edition (kommerzielle Lizenz): Compliance-Audit-Exporte, KI-gestuetzte Tool-Ueberpruefung, verschluesselte Multi-Agenten-Kollaboration, Monitoring-Dashboards und dedizierter Support. (Alle drei Sandbox-Backends -- Docker, gVisor und Firecracker -- sind OSS.)
Kontaktieren Sie ThirdKey fuer Enterprise-Lizenzierung.
