Governing AI you don't run

Bringing AI workers that run outside damn.dev into the same Registry and audit log — each with an honest label: declared, observed, or detected.

Not every AI worker in your org runs inside damn.dev — a developer's Claude Code, a ChatGPT workflow, an MCP-speaking agent. damn.dev still brings them into one Registry and one audit log, each with an honest label for exactly how far the governance goes.

Ceiling — damn.dev records what is declared or observed about an external worker. Where a cooperative gate exists, it is best-effort and bypassable — an agent that doesn't route through it isn't gated. We never call any of this "containment"; real containment means running the agent in a box you provision (the enterprise tier).

The connectors and their labels#

SourceSetupHonest label
External workerRegister it by hand (name, owner, declared access)Declared — inventory & accountability, not control
Claude Code / CodexA one-line installer wires the tool's own configObserved (+ best-effort gate)
Cursor / Hermes (MCP)Point it at the MCP proxyMCP gated · shell observed
OpenTelemetry / CLIA standard OTLP endpointObserved — inventory breadth
Discovered toolFound by the endpoint sensorDetected — it exists, nothing more

Observed connectors report their actions (which tool, which file, which command) into the audit log and auto-register in the Registry. Prompts, file contents, and tool outputs are never captured. Derived gap chips ("touched main branch", "ran network egress") come straight from the reported rows.

Ceiling — the gradient. Declared = you told us. Observed = it reports its own actions on a tamper-evident record, and a rule may deny one (best-effort, bypassable). Detected = we know it exists and who runs it, never what it did. None of these is an OS sandbox.

Setting one up#

All of the above are wired from Oversight → Registry → Connect, which builds the one-time config for your tool (and a one-command installer that wires several at once).

Next#