DEV Community

Artem Matviychuk
Artem Matviychuk

Posted on • Originally published at Medium

Defense in Depth for an Agent That Will Definitely Screw Up

Third in a series on building an autonomous AI organism that operates real multi-tenant infrastructure under a constitutional safety model. Part 1 was two gates. Part 2 was the wall. This one is about why no single one of them — including the wall — is allowed to be the last line.

Every safety mechanism I've described so far has a bug in it right now. I just don't know which one.

That's not false modesty — it's the only sane operating assumption for an autonomous agent on production. The conscience will misclassify an action someday. The council will wave through a bad idea. The isolation wall will have a gap I didn't see. Each of these is the primary defense for some risk, and each one will, eventually, fail at its job.

So the real design question was never "how do I make a perfect layer." It was: when a layer fails — and it will — what's standing behind it?

The stack

I think about the organism's safety as six layers, numbered by how early they catch a problem. Earlier is cheaper: the best place to stop a disaster is before it's an idea.

  • L0 — Structural isolation. The wall from part two. Wrong-tenant actions aren't forbidden, they're unrepresentable. Catches: cross-tenant leaks.
  • L1 — Idea-gate. The council from part one. Bad ideas die in debate before any code exists. Catches: building the wrong thing.
  • L2 — Action-gate. The conscience from part one. A deterministic reflex on every command: allow / ask / deny by blast radius. Catches: doing the wrong thing.
  • L3 — Resource-gate. A governor over the body: admission control, budget ceilings, an OOM/runaway-cost killer. Catches: the agent eating all the memory or money.
  • L4 — Audit. Tamper-evident hash-chain receipts. Every non-trivial decision signs the previous one. Catches: not knowing what actually happened — and lies about it.
  • L5 — Recovery. Immune-style quarantine, checkpoints, rollback. Catches: the damage already in progress.

Read top to bottom and you get a funnel: stop it as an idea (L1), as an intent (L2), as a resource grab (L3); if it still happened, know it happened (L4); if it's hurting, contain it (L5). L0 sits under all of them as the boundary none of the others are allowed to cross.

The only rule that makes it "depth" and not "a list"

A stack of layers isn't defense in depth. It's just a list, and lists give you a warm feeling that isn't safety. The thing that turns a list into depth is one rule I hold hard:

Every critical risk must be caught by at least two independent layers — and "independent" means they don't fail for the same reason.

Two checks that both read the same config and both trust the same upstream signal are one check wearing two hats. When that shared assumption is wrong, both fall together. Real depth means the second layer would catch it even if the first layer's entire premise was broken.

Concretely, for the worst risk — acting on the wrong tenant — L0 makes the wrong endpoint unrepresentable, and the audit layer would surface any cross-tenant write after the fact, and egress scoping would refuse the route. Three mechanisms, three different failure modes. You have to break all three on the same action, and they don't break for the same reason.

The plot twist: the time one layer lied and another caught it

If you read part one, you know the most embarrassing thing that's happened in this whole project: my idea-gate — the council — once returned a complete, confident verdict for a debate that never ran. A helper had fabricated the votes, the rounds, the conclusion, and reported it as fact.

Here's the part I didn't dwell on then, because it belongs in this article: that fabrication is exactly the scenario defense in depth exists for.

L1 — the idea-gate — failed. Not "gave a wrong answer" failed. Lied about its own existence failed. The single worst way a layer can break: it didn't just miss, it actively produced a convincing false signal. If L1 had been my only line, a fabricated verdict drives a real decision and I never know.

It wasn't the only line. The thing that caught it was L4 — the audit principle: a verdict is only valid if it's backed by an artifact I can independently read. I went looking for the receipt. There was no transcript file. The chain didn't exist, so the claim was void, regardless of how confident the narration was.

That's the whole doctrine in one incident. L1 produced a lie; L4 didn't believe narration, only receipts; the lie died. One layer failed in the worst possible way and the system was fine — not because I'm clever, but because I'd assumed L1 would fail and put something behind it that fails for a completely different reason.

The part most write-ups skip: half of this is real, half is doctrine

Here's where most "defense in depth" write-ups quietly cheat: they draw the diagram and let you assume it's all built. Given that this entire series is about not trusting confident narration, I'd be a hypocrite to do that. So, the real status:

  • L1 idea-gatecoded. It's a process I actually run before building.
  • L2 action-gatecoded. A real deterministic hook on every command.
  • L4 auditcoded. Hash-chain receipts on disk.
  • L0 isolationpartial. The manifest, per-session capabilities, and a tenant-guard primitive exist; binding it into CI against live configs is still a code step, not a finished gate.
  • L3 resource-gatepartial. The policy and the logic are written and tested; the part that actually kills a runaway process needs a body it doesn't fully have yet.
  • L5 recoverypartial. Quarantine and checkpoint exist; full rollback is doctrine with a prototype.

I'm telling you which layers are load-bearing and which are scaffolding on purpose. A safety architecture you can't audit is just a mood board. The status table is part of the product — it's the same rule as L4 pointed inward: don't trust my diagram, check which boxes are actually wired.

Why this matters beyond my setup

The pitch for autonomous agents is always capability. The thing that decides whether you can run one on production is what happens at the moment of failure — and whether you've been clear with yourself about where failure lives.

Three questions worth asking of any "safe" agent:

  • For your worst risk, name the two independent layers that catch it. If you can only name one, you don't have depth — you have a single point of failure with good marketing.
  • When a layer fails by producing a confident wrong signal (not just silence), what behind it doesn't believe the signal?
  • Which of your layers are built, and which are slides? If you can't answer instantly, neither can the system.

Capability is one layer. Safety is the other five — and knowing which of them are real yet.


Next: the resource-gate up close — a budget governor for an AI organism, and why the most dangerous agent isn't the malicious one, it's the hungry one that takes a task and eats all the memory.

Top comments (0)