中文简体 | Español | Português | 日本語 | Deutsch
Policy-governed agent runtime for production. Same agent. Secure runtime.
Symbiont is a Rust-native runtime for executing AI agents and tools under explicit policy, identity, and audit controls.
Most agent frameworks focus on orchestration. Symbiont focuses on what happens when agents need to run in real environments with real risk: untrusted tools, sensitive data, approval boundaries, audit requirements, and repeatable enforcement.
AI agents are easy to demo and hard to trust.
Once an agent can call tools, access files, send messages, or invoke external services, you need more than prompts and glue code. You need:
- Policy enforcement for what an agent may do — built-in DSL and Cedar authorization
- Tool verification so execution is not blind trust — SchemaPin cryptographic verification of MCP tools
- Agent identity so you know who is acting — AgentPin domain-anchored ES256 identity
- Sandboxing for risky workloads — Docker isolation with resource limits
- Audit trails for what happened and why — cryptographically tamper-evident logs
- Approval gates for sensitive actions — human review before execution when policy requires it
Symbiont is built for that layer.
- Docker (recommended) or Rust 1.82+
# Start the runtime (API on :8080, HTTP input on :8081)
docker run --rm -p 8080:8080 -p 8081:8081 ghcr.io/thirdkeyai/symbi:latest up
# Run MCP server only
docker run --rm -p 8080:8080 ghcr.io/thirdkeyai/symbi:latest mcp
# Parse an agent DSL file
docker run --rm -v $(pwd):/workspace ghcr.io/thirdkeyai/symbi:latest dsl parse /workspace/agent.dslcargo build --release
./target/release/symbi --help
# Run the runtime
cargo run -- up
# Interactive REPL
cargo run -- replFor production deployments, review
SECURITY.mdand the deployment guide before enabling untrusted tool execution.
Symbiont separates agent intent from execution authority:
- Agents propose actions through the reasoning loop (Observe-Reason-Gate-Act)
- The runtime evaluates each action against policy, identity, and trust checks
- Policy decides — allowed actions execute; denied actions are blocked or routed for approval
- Everything is logged — tamper-evident audit trail for every decision
Model output is never treated as execution authority. The runtime controls what actually happens.
An agent attempts to call an unverified MCP tool. The runtime:
- Checks SchemaPin verification status — tool signature is missing or invalid
- Evaluates Cedar policy —
forbid(action == Action::"tool_call") when { !resource.verified } - Blocks execution and logs the denial with full context
- Optionally routes to an operator for manual approval
No code change required. The policy governs execution.
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;
}
}
See the DSL guide for the full grammar including metadata, schedule, webhook, and channel blocks.
| Capability | What it does |
|---|---|
| Policy engine | Fine-grained Cedar authorization for agent actions, tool calls, and resource access |
| Tool verification | SchemaPin cryptographic verification of MCP tool schemas before execution |
| Agent identity | AgentPin domain-anchored ES256 identity for agents and scheduled tasks |
| Reasoning loop | Typestate-enforced Observe-Reason-Gate-Act cycle with policy gates and circuit breakers |
| Sandboxing | Docker-based isolation with resource limits for untrusted workloads |
| Audit logging | Tamper-evident logs with structured records for every policy decision |
| Secrets management | Vault/OpenBao integration, AES-256-GCM encrypted storage, scoped per agent |
| MCP integration | Native Model Context Protocol support with governed tool access |
Additional capabilities: threat scanning for tool/skill content (40 rules, 10 attack categories), cron scheduling, persistent agent memory, hybrid RAG search (LanceDB/Qdrant), webhook verification, delivery routing, OTLP telemetry, HTTP security hardening, and governance plugins for Claude Code and Gemini CLI. See the full documentation for details.
Representative benchmarks are available in the benchmark harness and threshold tests.
Symbiont is designed around a simple principle: model output should never be trusted as execution authority.
Actions flow through runtime controls:
- Zero trust — all agent inputs are untrusted by default
- Policy checks — Cedar authorization before every tool call and resource access
- Tool verification — SchemaPin cryptographic verification of tool schemas
- Sandbox boundaries — Docker isolation for untrusted execution
- Operator approval — human review gates for sensitive actions
- Secrets control — Vault/OpenBao backends, encrypted local storage, agent namespaces
- Audit logging — cryptographically tamper-evident records of every decision
If you are executing untrusted code or risky tools, do not rely on a weak local execution model as your only boundary. See SECURITY.md and the security model docs.
| Crate | Description |
|---|---|
symbi |
Unified CLI binary |
symbi-runtime |
Core agent runtime and execution engine |
symbi-dsl |
DSL parser and evaluator |
symbi-channel-adapter |
Slack/Teams/Mattermost adapters |
repl-core / repl-proto / repl-cli |
Interactive REPL and JSON-RPC server |
repl-lsp |
Language Server Protocol support |
symbi-a2ui |
Admin dashboard (Lit/TypeScript, alpha) |
Governance plugins: symbi-claude-code | symbi-gemini-cli
If you are evaluating Symbiont for production, start with the security model and getting started docs.
- Community Edition (Apache 2.0): Core runtime, DSL, policy engine, tool verification, sandboxing, agent memory, scheduling, MCP integration, RAG, audit logging, and all CLI/REPL tooling.
- Enterprise Edition (commercial): Advanced sandbox backends, compliance audit exports, AI-powered tool review, encrypted multi-agent collaboration, monitoring dashboards, and dedicated support.
Contact ThirdKey for enterprise licensing.
