Security and trust
How Yodu keeps AI employee work safe — dedicated container isolation, encrypted never-returned secrets, the human approval gate, per-employee tool switches, scoped access, and backup evidence.
Yodu's trust model rests on four layers that work independently: workspace isolation at the runtime, encryption for every stored secret, a human approval gate in front of risky actions, and per-employee switches that control what each AI employee can see at all. If one layer is misconfigured, the others still hold.
Isolation by design
Each workspace runs OpenClaw in its own Docker container on Yodu's managed runtime host. Nothing else shares that container: not another company's workspace, not another client boundary you separated deliberately.
The container is reached only through Yodu's command queue. Runtime ports stay private; the app never dials into the container directly. A sidecar worker makes outbound requests, claims bounded commands off the queue, and reports results and heartbeats back. If the worker stops heartbeating, the Runtime page shows it — silence is visible, not hidden.
| Boundary | What it separates |
|---|---|
| Workspace container | One company's employees, files, and runtime state |
| Command queue | The app from raw runtime access |
| Employee switches | What each employee inside the workspace can see |
| Approval gate | Prepared work from external or irreversible effects |
Secrets are stored, never shown
Model provider keys, connected-account credentials, and workspace secrets are encrypted at rest and never returned — not in the UI, not by the API, not by any Platform MCP tool. list_secrets returns names and metadata only.
The operating rule is rotate, don't retrieve. Enter a new value to replace access; there is no control that displays the old one. A Configured badge means an active stored secret exists — it does not claim the key currently works. A real employee turn is the end-to-end check.
Runtime gateway credentials are excluded from workspace backup archives, and provider secrets stay encrypted references rather than plaintext copied into employee files.
The approval gate
Anything external or irreversible — send, post, publish, spend, delete, change production — pauses for a human decision before it runs. The request appears as an inline card in the employee's chat and in the Approvals queue. You choose Allow once, This session (a few hours), or Deny.
The gate is not configurable per tool; it applies to the action class regardless of which tools are enabled. That is deliberate: safety does not depend on someone remembering to set the right mode on the right grant. See Approvals and autonomy for the full decision model.
Per-employee tool switches
Every connected app and custom MCP server is a switch per employee: enabled by default, or disabled entirely. A disabled tool is hidden — omitted from that employee's TOOLS.md, and for custom MCP servers, removed from the employee's private mcporter registry. The employee cannot see it, call it, or ask for it by name.
Use switches for role boundaries, not risk decisions — the gate carries the risk. See Tool access per employee.
Who gets in
- Your accounts stay yours. Business apps connect through OAuth via the Composio catalog. Yodu holds the resulting credential encrypted; employees use it without ever seeing it.
- Workspace members hold owner, admin, or member roles. Provider secrets, employee configuration, and runtime repair require owner or admin. See Member access and roles.
- External clients reach one workspace through scoped, revocable API keys at
https://app.yodu.ai/api/mcp— works with Claude Desktop, Claude Code, and Cursor. Every key derives its workspace from verification; no tool accepts an organization ID.
Backups with evidence
Workspaces get scheduled backups, plus a fail-soft safety backup before stop, restart, and provision operations. The Runtime page shows when the last archive ran, its size, its recorded file count, and a freshness status — evidence you can check, not a checkbox you trust.
Backup evidence proves an artifact with measurable contents exists. It does not by itself prove a full recovery meets a recovery-time objective; a tested restore into a scratch location remains the operator's job. See Managed runtime and backups.
Verify it yourself
A short trust review for any workspace:
- Open Runtime and confirm worker heartbeat, container state, and backup freshness.
- Open Approvals and confirm a human owner is actually reviewing the queue.
- Open Tool access → Employee access and confirm each employee's switches match their role.
- Confirm no secret value is visible anywhere in the UI — only names, badges, and rotation controls.
- Send one risky test instruction and confirm it stops at the gate instead of running.
If any of those checks fails, fix it before adding more employees or higher-risk work.
Managed runtime and backups
Understand how Yodu provisions AI employee workspaces, reports runtime health, executes scheduled work, and records workspace backup evidence.
Product tour
A visual tour of the current Yodu company overview, employee channels, work board, memory, files, tools, MCP, skills, schedules, and model settings.