Isolation, auth & secrets
How workspaces and channels stay separated, how the operator boundary works, and how authentication and secrets-at-rest are handled.
The enforced boundaries that protect workspace members and their data from each other. (For the parts that are deliberately trusted, see Enforced vs Trusted.)
Workspace isolation#
Every read and write is scoped by workspaceId at the query layer. The audit chain is per-workspace. One workspace cannot see another's agents, channels, rules, secrets, or topology — a missing scope would be a leak, so the scope is applied everywhere, not opt-in.
Channel access#
Ceiling — Members can read public channels, or private channels they're a participant in — nothing more. Operators get no ambient read of private conversations. Terminal channels are operator-only, gated on the server (not merely hidden). Access is checked at one authorization seam that every channel/message read passes through; denial is returned as "not found" so the surface never confirms a channel exists.
The operator boundary#
Admin, configuration, and destructive actions are gated server-side. The UI's role-based views are a convenience; the real boundary is the server check. An operator is a trusted role by definition — the boundary protects members from each other, not a workspace from its own operators.
Authentication#
Sign-in is email + password (12-character minimum) or Google OAuth, via better-auth. Invite tokens are 256-bit with indexed lookup (no timing side-channel), and signup is rate-limited per IP.
Secrets at rest#
- Secrets (provider keys, skill credentials) are AES-256-GCM encrypted under
~/.damn-dev/secrets.key. Agents reference them as${KEY}; values are substituted server-side and never shown to the agent. - Environment variables are plaintext by design — they're boot-time infra config, and encrypting them with a key in the same directory adds nothing against the host-access threat.
Warning — This encryption protects secrets in the database, not from someone with host access. Anyone who can read the filesystem can read
secrets.keyand.env. That's the explicit trusted boundary of a self-hosted system — see Enforced vs Trusted.
Next#
- Shell execution & containment — the per-platform execution ceilings.
- Honest claims & reporting — the canonical "what we never say" list.