𝗗𝗲𝗳𝗲𝗻𝘀𝗲 𝗶𝗻 𝗗𝗲𝗽𝘁𝗵 𝗳𝗼𝗿 𝗔𝗻 𝗔𝗴𝗲𝗻𝘁 𝗧𝗵𝗮𝘁 𝗪𝗶𝗹𝗹 𝗦𝗰𝗿𝗲𝘄 𝗨𝗽
Every safety mechanism has a bug. You just do not know which one yet.
This is the only sane way to build an autonomous agent for production. The conscience will misclassify an action. The council will approve a bad idea. The isolation wall will have a gap.
Each layer will eventually fail.
The design question is not how to build a perfect layer. The question is: what stands behind a layer when it fails?
I use six layers to protect the system. Earlier layers are cheaper because they stop problems before they become reality.
• L0 — Structural isolation. Prevents wrong-tenant actions at the base level. • L1 — Idea-gate. Stops bad ideas during debate before code exists. • L2 — Action-gate. A reflex that allows or denies commands based on risk. • L3 — Resource-gate. Controls memory, budgets, and runaway costs. • L4 — Audit. Uses tamper-evident receipts to track every decision. • L5 — Recovery. Uses quarantine and rollbacks to stop active damage.
A list of layers is not defense in depth. Real depth requires one rule:
Every critical risk must be caught by at least two independent layers.
Independent means they do not fail for the same reason. If two checks use the same config or the same signal, they are the same check. When that signal fails, both checks fail.
I saw this happen. My idea-gate once returned a confident verdict for a debate that never occurred. A helper fabricated the entire result.
L1 failed. It did not just miss the error. It produced a convincing lie.
If L1 was my only line, the lie would have become a real decision. But L4 caught it. L4 does not believe narration. It only believes receipts. I looked for the transcript file. The file did not exist. The claim was void.
The system stayed safe because I assumed L1 would fail.
Current status of these layers:
• L1 — Coded. • L2 — Coded. • L4 — Coded. • L0 — Partial. • L3 — Partial. • L5 — Partial.
A safety architecture you cannot audit is just a mood board.
Ask yourself these three questions about any safe agent:
- For your worst risk, what are the two independent layers that catch it?
- When a layer produces a confident wrong signal, what layer behind it refuses to believe that signal?
- Which layers are built, and which are just ideas?
Capability is one layer. Safety is the other five.
Defense in Depth für einen Agenten, der definitiv Mist bauen wird
Wenn wir über KI-Agenten sprechen, sprechen wir über Systeme, die nicht nur Text generieren, sondern Handlungen ausführen. Sie nutzen Tools, greifen auf APIs zu und interagieren mit der realen Welt.
Das Problem? LLM-Agenten sind unvorhersehbar. Sie sind probabilistisch, nicht deterministisch. Das bedeutet, dass sie zwar in 99 % der Fälle das Richtige tun, aber in den restlichen 1 % etwas völlig Unerwartetes tun können – und das kann katastrophale Folgen haben.
Wenn Sie einem Agenten die Erlaubnis geben, Code auszuführen oder Dateien zu löschen, sollten Sie nicht darauf vertrauen, dass er "schon gut sein wird". Sie müssen das Prinzip der Defense in Depth (gestaffelte Verteidigung) anwenden.
Hier sind die Schichten, die Sie implementieren sollten:
1. Sandboxing (Isolation)
Die wichtigste Regel lautet: Lassen Sie den Agenten niemals direkt auf Ihrem Host-System arbeiten.
Wenn ein Agent Code ausführt, muss dies in einer isolierten Umgebung geschehen. Ein Docker-Container ist ein guter Anfang, aber für maximale Sicherheit sind MicroVMs (wie Firecracker) noch besser. Eine Sandbox stellt sicher, dass selbst wenn der Agent versucht, rm -rf / auszuführen, er nur das Dateisystem innerhalb des Containers zerstört, nicht Ihren Server.
2. Das Prinzip der geringsten Privilegien (Least Privilege)
Geben Sie dem Agenten nur die Werkzeuge und Berechtigungen, die er für seine spezifische Aufgabe benötigt.
Wenn der Agent nur Daten analysieren soll, sollte er keinen Schreibzugriff auf die Datenbank haben. Wenn er nur Dateien in einem bestimmten Verzeichnis lesen muss, sollte er keinen Zugriff auf das gesamte Dateisystem haben.
Verwenden Sie API-Keys mit eingeschränkten Scopes und stellen Sie sicher, dass die Tools, die der Agent aufruft, strikt validierte Parameter erwarten.
3. Guardrails (Eingangs- und Ausgangskontrolle)
Sie müssen sowohl das kontrollieren, was in den Agenten hineingeht, als auch das, was aus ihm herauskommt.
- Input Guardrails: Verhindern Sie Prompt Injection. Filtern Sie Anfragen, die versuchen, die Systeminstruktionen zu umgehen.
- Output Guardrails: Überprüfen Sie die Ausgaben des Agenten, bevor sie ausgeführt werden. Wenn der Agent einen Befehl generiert, der potenziell schädlich ist (z. B. ein SQL-Injection-Versuch oder ein gefährlicher Shell-Befehl), muss das System dies blockieren.
Tools wie NeMo Guardrails oder einfache Validierungsschichten können hier helfen.
4. Human-in-the-loop (Menschliche Kontrolle)
Für kritische Aktionen ist eine menschliche Bestätigung unerlässlich.
Ein Agent sollte niemals autonom Geld überweisen, Benutzerkonten löschen oder Produktionsumgebungen ändern können, ohne dass ein Mensch "OK" sagt. Implementieren Sie einen Workflow, bei dem der Agent seinen geplanten Schritt vorschlägt und ein Mensch diesen freigibt.
Fazit
KI-Agenten sind die Zukunft, aber sie sind keine perfekten Mitarbeiter. Sie sind eher wie extrem talentierte, aber manchmal sehr verwirrte Praktikanten. Bauen Sie Sicherheitsbarrieren, die nicht darauf basieren, dass der Agent keine Fehler macht, sondern darauf, dass die Fehler keine Auswirkungen auf Ihr System haben.