All posts
/5 min read

Detected is not observed. Observed is not gated. Gated is not contained.

Four words the AI security market uses interchangeably, what each one actually means, and the exact ceiling of what damn.dev enforces on every surface we ship.

Anthony Levy
Anthony LevyFounder, damn.dev

There are four words in this market that get used as if they were synonyms. They are not, and the distance between them is where every unpleasant surprise lives.

Detected. We know the tool exists. Nothing about what it did.

Observed. We see the actions, on a record that cannot be quietly edited afterwards. We did not stop any of them.

Gated. An action was allowed or refused at a decision point. How reliably depends entirely on who owns that point.

Contained. The agent physically could not do the thing, because its environment made it impossible. Not a decision. An impossibility.

A vendor demo can look identical at all four. A dashboard showing red and green does not tell you whether anything was actually stopped. So here is ours, surface by surface, including the parts that are weaker than we would like.

What each word costs you when it is wrong#

The gap between detected and observed is the gap between knowing an agent exists and knowing what it did with your production database.

The gap between observed and gated is the gap between a camera and a lock. A camera is genuinely valuable. It is also, by construction, a thing that narrates the burglary while it happens. Most of what is sold as AI security today is a very good camera.

The gap between gated and contained is the one nobody wants to talk about, because it is the difference between a decision an agent cooperates with and a boundary it cannot cross. A cooperative gate lives inside the tool it governs. It asks the tool to check in before acting. If that check fails, times out, or the tool is configured not to make it, the action proceeds. That is not a bug in anybody's implementation. It is what a cooperative gate is.

Our ceiling, by surface#

Agents we run. These launch inside an environment we control on your infrastructure. Shell execution is OS sandboxed on macOS through Seatbelt, covering reads, writes, and an enforced network block. On Linux and containerized server installs it is best effort, inside standard container isolation. We do not say kernel contained there, because it is not.

Coding agents on a laptop or in CI. Claude Code, Codex, Cursor, an MCP client. We observe every action on the same record as everything else, and we gate through a hook inside the tool. That gate is best effort and it fails open. If our backend is slow or unreachable, the action proceeds, deliberately, because a governance tool that freezes a developer's session gets uninstalled by lunchtime. It is bypassable by anyone who wants to bypass it. What it is not is silent: the record shows what happened either way.

Anything reaching a company key or door. Here the enforcement is real regardless of where the agent runs, because the refusal happens at the resource rather than inside the agent. An agent whose credential was never issued for a system does not get a polite decline. It gets nothing.

Web and vendor cloud agents. ChatGPT in a browser, an agent baked into a SaaS product. We detect that they exist. We govern any action that lands on a key or door you own. We do not claim to control the browser, and we cannot contain an agent running on somebody else's cloud. Nobody can.

A personal account, on a personal device, against a public service. Detection only. There is no product that does more, and a vendor claiming otherwise is describing something they have not built.

Why publish this#

Two reasons, and the second is the real one.

The first is that a technical buyer finds out anyway. Not during the demo, when the deck says "blocks unauthorized actions." During the incident, when the action was not blocked and the deck has to be explained to a board. Every overclaim is a deferred trust collapse with interest.

The second is that the honest version is a better product story than the marketing one.

Here is the same information stated forward:

One rulebook. One record. Every agent. And how hard we can stop something depends on how much of the path runs through you.

That is not a disclaimer. It is a design, and it is the design that lets one trust model cover an estate you do not control. What is uniform across every agent, every runtime, every vendor is the rulebook and the record. What varies is the teeth. And the teeth are something you can deliberately strengthen, surface by surface, by routing more of the path through yourself: issue the key, own the door, put the traffic through your own chokepoint.

A vendor who tells you it is uniformly enforced everywhere is telling you they have not thought about the case where it is not.

Four questions this makes easy to ask#

Take these to us and to everyone else you are evaluating.

  1. For each surface you cover, is it detected, observed, gated, or contained? Ask surface by surface, not as one answer.
  2. What happens when your service is unreachable? Fail open or fail closed? Both are defensible. Not knowing is not.
  3. Where does the record live, who can alter it, and can you prove it was not altered?
  4. Show me one thing your product does not stop.

The fourth is the one that ends demos.

We will answer all four in writing, before you buy anything. That is the whole pitch.