Enforced vs Trusted

The foundations are strong and worth stating plainly: your data is sovereign by architecture, every consequential action is gated, and the audit log is tamper-evident. On top of that, full agent containment is available for deployments that need it.

This page is the canonical anchor for the security claims in these docs. It's candid about the boundaries, because trust is built on precision, not on overclaiming.

The two halves#

Security here splits into what the system enforces and what a self-hosted tool deliberately trusts. The trusted half isn't a gap we're hiding — it's the explicit boundary of software that runs on your infrastructure, under your operators.

What is enforced#

Real, code-level boundaries that protect workspace members and their data from each other.

Boundary	What's enforced
Workspace isolation	Every read and write is scoped by workspace. One workspace cannot see another's topology, rules, secrets, or messages.
Channel access	Members see public or participant channels only. Operators get no ambient read of private conversations.
The operator boundary	Admin, config, and destructive actions are gated server-side, not merely hidden in the UI.
Never-auto-approve	Consequential actions — editing an agent's prompt, installing a skill, changing trust, merging code, creating a rule — can never be auto-approved.
The enforcement kernel	One decision function applies allow / ask / deny across every surface. An enforcing deny outranks Trust Mode — a CISO guardrail beats operator convenience.
Secrets at rest	Provider keys and credentials are AES-256-GCM encrypted. Agents never see secret values; they're substituted server-side.
Audit integrity	Trace events are hash-chained per workspace. Tampering with any past row breaks the chain, and the break is detectable.
Per-agent access	Folder and secret grants confine what an agent can touch; the credential denylist is unconditional.

What is trusted#

Like every self-hosted system, damn.dev protects users from each other — not the data from whoever runs the box. It trusts the host machine (anyone with host access can read what's on disk), the agent runtime's mounts, operators (a trusted role by definition), and, on local installs, network transport (the deployer's responsibility). We state this plainly so no one mistakes the product for something it isn't.

Full detail under NDA. The itemized trusted-surface breakdown — exactly what each install path exposes to a host operator — is part of our detailed security posture, shared candidly with teams evaluating for a real threat model. Talk to us.

Sovereignty vs. containment#

The most important distinction in the model — and the one most often blurred by other products.

Sovereignty is architectural and always true. Your data never leaves your perimeter, on any platform and any install path. This is a property of where the software runs, not a promise about behaviour.

Containment — physically preventing an agent from reaching something — is different:

• Standard install — best-effort, its strength depending on where it runs (kernel-level on macOS, container-grade on new docker-vps installs). We never call the standard install "fully contained."
• Full containment — an enterprise capability, identical on every platform. Agents run in a disposable sandbox on your own infrastructure: no reachable secrets, allow-listed egress, nothing kept.

Honest-claims discipline#

Throughout these docs we distinguish enforced from observed from declared, per surface; we never imply damn.dev contains or controls an AI worker it doesn't run; and cooperative gates are described as best-effort and bypassable, never as containment.

Next#

• Governing AI you don't run — declared vs. observed vs. detected.
• Enterprise & advanced controls — the full containment tier.