Governing AI you don't run

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).

Observing a connected worker is free; blocking its actions needs a license. The connectors, the audit trail, and the record of what your rules would have stopped all work without one. See Licensing.

The connectors and their labels#

Source	Setup	Honest label
External worker	Register it by hand (name, owner, declared access)	Declared, inventory & accountability, not control
Claude Code / Codex	A one-line installer wires the tool's own config	Observed (+ best-effort gate)
Cursor / Hermes (MCP)	Point it at the MCP proxy	MCP gated · shell observed
OpenTelemetry / CLI	A standard OTLP endpoint	Observed, inventory breadth
Discovered tool	Found by the endpoint sensor	Detected, 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). On a Mac with the desktop app, the same connect is one click.

Codex asks permission before it runs a hook#

Codex will not run a lifecycle hook it has never been trusted with, and it says nothing when it declines: the hook simply never executes. So writing the config is only half of connecting, and a connector that stopped there would report nothing while looking perfectly healthy.

The installer and the desktop app therefore finish by asking Codex itself to trust the hook, through the same mechanism its own trust prompt uses. Only the damn.dev hook is trusted — any other hook in your Codex config is left exactly as it was, for you to decide on.

Two things worth knowing:

• Rotating a token does not break it. The credential lives in a private file next to the hook, not on the hook's command line, so the command Codex trusted never changes. Older installs still carry the token inline and keep working; their next re-install moves them over.
• If it can't be done, you're told. No codex on the PATH, for instance. The installer says the hook is not yet trusted and that nothing will be reported until it is, rather than claiming a connection; the desktop app's row says the same. You can always finish it by starting codex once and accepting its prompt.

One Codex config serves both the CLI and the ChatGPT desktop app, so connecting once covers both.

Next#

• Enforced vs Trusted, why these are honestly labelled the way they are.
• Enterprise & advanced controls, when you need real containment, not just observation.