Security & Permissions

Security & Permissions

5-Layer Security Architecture

1. Transport Layer: Strict TLS and redirect: "manual" proxy policies with fixed upstreams.
2. Authentication: Server-side token resolution and scoped API key verification (internal/http/auth.go).
3. Authorization & RBAC: Role hierarchy (Owner > Admin > Operator > Viewer).
4. Tenant Isolation: Application-level tenant scoping (WHERE tenant_id = $N, store.WithTenantID(ctx), and store.IsMasterScope(ctx)).
5. Execution Sandboxing: Docker container isolation with restricted network capabilities and shell deny patterns.

Agent File Access Across Tenants

Agent file tools (read_file, list_files, search_files, send_file) read outside the agent’s workspace only where the agent’s tenant is allowed. These grants are read-only.

• A tenant agent can read its own tenant’s skills and data, and the system skills. It cannot read the master tenant’s custom skills or another tenant’s data.
• A master-tenant agent can read every skill in the shared skills store, but not other tenants’ data.
• No agent can read the Claude CLI provider’s per-session prompt files (<dataDir>/cli-workspaces).

Subagents and Workers

Subagents and native workers never get more than the agent that spawned them:

• A tool the agent explicitly denies (tools.deny, including group:* entries and aliases such as bash for exec, or the global deny) is never offered to its subagents, and a call to it is refused. A worker’s toolAllowlist can only narrow its tools, so it cannot re-add a denied tool.
• A subagent’s exec is the gateway’s exec: it denies the same paths (data dir, .dewee/, workspace memory.db/config.json, gateway database and config files) and allows the same per-run paths, such as the run’s own workspace uploads and its own tenant directory. Another tenant’s directory stays denied.

Admin Control Plane Credentials

The platform Admin Control Plane (ACP) authorizes every request against one deny-by-default list of operations, whether it comes from the browser, the REST API or dewee admin.

• People sign in with GitHub or Google. Operators can read and run day-to-day order, license, runtime and ticket actions. Super admins can do everything.
• Automation and the CLI use scoped ACP API keys (dewee_acp_…), created by a super admin under API keys or with dewee admin api-keys create. A key carries only the scopes chosen for it, never more than its creator holds, and expires within 90 days. The secret is shown once and stored only as a keyed hash.
• Revoking a key takes effect on its next request everywhere. Rotating issues a replacement with an optional overlap so clients can switch without downtime.
• The legacy static admin token works only during an explicit, time-boxed break-glass window, and every use is audited.
• Gateway (RGD) and workspace (CCP) credentials are never accepted by ACP. Request headers cannot change who the caller is.
• Each audit record names the actor type, credential, client, auth method, outcome (allow or deny) and correlation id. Refused attempts are recorded too, without the secret.

Check your current identity and scopes with dewee admin whoami.