Security model
Two credential tiers.
One trust boundary.
Sagewai separates operator credentials from per-customer credentials. The first never reach a customer's sandbox. The second never reach your control plane. The sandbox is the only place they meet.
Tier 1
Orchestration keys
The LLM key your Sagewai Agent uses to plan and dispatch. Lives in worker process env. You manage its lifecycle with your existing infrastructure.
Used for: small, cheap planning calls (e.g. "given this user goal, which CLI should I dispatch?"). Often a local Ollama model or a budget cloud model.
Tier 2
User-task keys
Per-customer credentials — Anthropic API keys, GitHub tokens, AWS keys, customer database URLs. Lives in the sandbox container. Sourced from Sealed Identity profiles at sandbox-start time, scrubbed on release.
Used for: the actual customer-facing work. Claude Code pushes to a customer repo, Codex queries a customer database, the artifact uploader writes to a customer S3 bucket — all using credentials only the sandbox sees.
What Sagewai promises
Commitments, not claims.
Customer credentials never cross the worker host.
Tier-2 keys (the API tokens, database passwords, and provider credentials your customers use) are env-injected into the sandbox container at start time, directly from the Sealed Identity backend. Plaintext values never touch the worker process or the control plane.
Every credential read is audited.
Every cascade resolution, every secret injection, every revocation interaction is recorded as a structured audit event with key NAMES — never values. Audit events are queryable from the admin console and exportable for SIEM ingestion.
Credentials can be revoked mid-run.
Operators can revoke a (profile, secret) pair at any time. Future runs fail closed. In-flight runs that have already injected the value get aborted (hard-revoke) or expire on the next sandbox start (soft-revoke). Pool reuse is safe — sandbox env is scrubbed on release.
Cascade rotation is observable.
When a profile is rotated between enqueue and sandbox start, a profile.drift_at_injection audit event records the diff (added keys, removed keys). No silent credential changes mid-run.
What Sagewai doesn't promise
Honest about scope.
These are operator concerns or upstream-vendor concerns. Sagewai gives you the primitives; the security posture of your specific deployment is yours to design.
We don't protect Tier-1 keys.
Your operator-side orchestration LLM keys (the planning brain) are managed by your existing infrastructure — k8s Secrets, AWS Secrets Manager, dotenv files, whatever your team already uses. Sagewai doesn't encrypt them or rotate them.
We don't defeat sandbox-backend escapes.
A vulnerability in the chosen sandbox backend (Docker daemon, Kubernetes kubelet, Lambda runtime) that lets sandbox code reach the host is the backend vendor's problem. Sagewai uses defense-in-depth — network policy, resource limits, image variants without unnecessary tooling — but cannot retroactively fix a backend escape.
We don't guarantee LLM provider trust.
When a CLI agent calls Anthropic, OpenAI, or another provider, that provider receives the prompt content. If the prompt accidentally contains a secret, the provider sees it. Sagewai's redaction layer scrubs known patterns from prompts and tool stdout — but it cannot retroactively unsee.
We don't hold compliance certifications today.
Sagewai is open source software, not a service offering. SOC2, ISO 27001, and HIPAA compliance are operator concerns, depending on how you deploy. We provide the auditable primitives (Tier-2 isolation, immutable audit log, cascade rotation visibility) — your audit team builds the certified deployment on top.
Roadmap, not "today"
Some primitives are still landing.
The current Sealed-i (foundation profile management) and Sealed-iii.A (mid-run revocation) primitives ship today. The following are designed and queued, but not yet shipped:
- •External Identity backends — HashiCorp Vault, 1Password, AWS Secrets Manager, SOPS, Bitwarden. The builtin file-based backend ships today; external backends are the Sealed-ii decomposition.
- •Just-in-time credential callback (Mode 3b) — the bidirectional channel that lets a CLI agent request a credential it doesn't have at runtime, with operator policy or HITL approval. Currently designed; ships in the Sealed-iv plan.
- •Kubernetes sandbox backend — Docker is shipped today. Kubernetes is in plan SBX-K8S; Lambda is in plan SBX-LAMBDA (Modes 1/2 only).
The technical reference.
This page is the end-user overview. The full architecture contract — runtime topology, mode-by-mode data flow, audit event vocabulary, trust assumption tables — lives in the public docs.
Found a vulnerability?
See the project's SECURITY.md for the responsible-disclosure policy and reporting addresses.