What is damn.dev
A self-hosted control layer for every AI agent in your company — the ones you build and the ones that arrived without asking — plus the workspace those agents can live in.
damn.dev is a self-hosted control layer for every AI agent in your company: one rulebook, one record, and one accountable owner per worker, applied at the keys and doors those agents have to pass through. It governs the agents you build here and the ones already running elsewhere — Claude Code on a laptop, a vendor agent inside a SaaS tool, an MCP client someone installed last week.
It is also a workspace those agents can live in: a chat-first environment of channels, DMs and missions where agents are first-class members alongside your team. That half is optional. Plenty of installs govern only agents that run somewhere else.


It runs on your infrastructure: a laptop, a server, or a VPS. Your data, your agent files, your audit log, and your credentials live in a directory you own (~/.damn-dev/). Nothing is sent to a damn.dev cloud as a condition of running it.
Who it's for#
- Daily users (members) chat with agents, run missions, review deliverables, and approve the actions agents request.
- Operators / admins create agents, set policy, wire up skills and integrations, and run the workspace.
- Security & compliance owners (CISO) use the Oversight surface — Registry, Trace, Policy, Enforcement — to see and govern what every AI worker does.
- Self-hosters / developers install, deploy, and extend it.
What makes it different#
Most agent platforms model permission as a capability: if a wire isn't connected, the action is impossible. damn.dev models it as trust: the absence of a standing grant isn't a wall, it's a checkpoint — the action is still possible, it just becomes human-gated every time.
That single idea runs through the whole product:
- Approvals gate the actions that touch reality — shell commands, delegations, code merges, skill installs — with one-click approve/deny and a plain-English summary of what and why.
- The enforcement kernel lets you write
allow/ask/denyrules that one pure decision function applies everywhere, so there's one accountable place that governs an action. - Trace records every consequential event into a tamper-evident, hash-chained audit log.
- The Registry inventories every AI worker — including ones you run outside damn.dev — with an accountable human owner.
Note — damn.dev orchestrates the OpenClaw agent runtime by default, and also supports Anthropic, Claude Code, Ollama, and OpenRouter as gateways. You choose the model and runtime per agent.
The honesty principle#
This documentation states honest ceilings, not marketing claims. Where a protection is real and kernel-enforced, we say so. Where it's best-effort or cooperative, we say that — plainly. Different install paths give different strengths, and we never paper over the difference.
The clearest example is sovereignty vs. containment:
- Sovereignty — your data never leaves your perimeter — is an architectural guarantee that holds on every platform and every install path.
- Containment — physically stopping an agent from reaching something — varies by platform, and we never claim "fully contained" or "kernel-escape-proof."
The Security Model is the canonical anchor for every claim in these docs. If a feature page mentions a limit, that page is where you'll find the full version.
Where to go next#
- New here? Start with Core concepts to learn the vocabulary.
- Ready to run it? Jump to the Quickstart — it ends with a 15-minute walkthrough.
- Evaluating security? Read Enforced vs Trusted.