Systems & Keys — what your AI can reach

The Registry answers who your AI workers are. Two further lenses on the same surface answer the questions that follow it, and they're usually the ones a security review actually asks:

• Systems — what can my AI reach, through which worker, and on what basis?
• Keys — which credential opens which of those doors, who holds it, and what is it costing?

Both are at Oversight → Registry, as lenses beside Workers. Same door, no second place to look.

Systems — the doors#

A system is anything your AI can get to: a folder, a host, an API, an MCP server, a tool. For each one you see which workers can reach it, on what basis — a folder you granted, a skill that calls it, an allowed host, or simply that a worker was observed there — and how much it's actually used.

This is not an inventory of your infrastructure. A system appears here for exactly one reason: some AI worker can traverse to it, or was seen at it. Everything your company runs that no AI touches is deliberately absent. It's a map of AI reach, and it stays small enough to read.

It maintains itself#

This is the part that matters, and it's a consequence of where the data comes from rather than a feature bolted on top. The map is built from the same grants that gate the action and the same activity that lands in your audit log. So:

• Granting an agent something draws the door.
• Using it keeps the door current.
• Not using it lets the grant go quiet, and a standing grant nobody has used is exactly the thing worth revoking.

Nobody maintains a spreadsheet, and the map can't drift from what's enforced, because it's made of the same facts.

The finding: reach nobody granted#

The map's job is to surface reach that isn't governed — a worker touching something no grant covers. What that means depends on who's doing it, and the wording differs on purpose:

• For an agent you run, it's a configuration gap: your rules don't describe what it's actually doing, and you can close it.
• For an agent running on someone's machine, there was no rule covering it — and closing that properly is a containment question, not a rule you can write.

Alongside it: grants that were declared and never used, systems with no accountable owner, and credentials that never expire.

Fixing it in place#

Where the fix is a single, safe, bounded action on the exact thing you're looking at, it's inline — scope a credential to the agents that need it, revoke a folder grant, add an expiry. Anything broader is a precise link to the right control rather than a button that half-does it. Every row can jump to its own activity in Trace.

There's a table view for reading and a graph view for showing someone. Both export.

Ceiling — this is the reach, not the behaviour. Systems shows what a worker can get to and where it has been seen. It does not tell you what was done with the data afterwards, and it never predicts where information flows. Treat it as the ceiling of reach.

Governance state is what your deployment enforces, not what you configured. An allowlist without the enforcement tier actually in the path reads as gated, never as blocked — see Enforced vs Trusted.

There is no cost per system. Spend belongs to the model that ran a turn, not to the thing that turn called; putting a number on a door would be a fabrication. You get how often it's touched.

Keys — the credentials#

The mirror image. One row per credential — by name, never by value — showing who holds it, whether it's scoped to specific agents or open to all of them, when it expires, and which doors it unlocks. For model provider keys it also carries what they cost over the last month, labelled real or estimated.

That gives you the two sentences a review wants: this credential is held by these agents and opens these things, and these agents need it and nothing else does. Scoping it to exactly those is one action from the row.

Credentials that never expire are called out. So are the ones a single agent needs but every agent can currently reach.

Ceiling — Keys describes what a credential is declared to unlock inside damn.dev, and who can resolve it here. It is not a picture of everywhere that credential is used across your company — if the same key is pasted into a CI job, damn.dev has no way to know. Per-agent expiry is per-agent: a shared credential can be time-boxed for one holder and permanent for another, and each row says which.

Who can see it#

Both lenses are operator-only, and the boundary is on the server. A reachability map names credentials, folders, and internal hosts — so a member gets nothing here rather than a partial view.

Next#

• Oversight & the Registry — the Workers lens these sit beside.
• AI usage, budgets & access — issuing a key per agent, and scoping folders and secrets.
• Trace — where every row's activity comes from.