Telemetry & the defense layers
An agent that can run commands, browse the web, spend credits, and deploy apps is powerful — and power needs guardrails. Ultron runs behind a layered defense: independent checks that keep the wrong actor out, contain what the agent executes, treat the open web as data rather than orders, bound what leaves, put a person on the irreversible decisions, and stop a turn before it runs away. Nothing runs unwatched.
Overview
- Model
- Defense in depth — seven independent layers
- Design rule
- Every layer fails safe on its own
- Human control
- Irreversible actions pause for your explicit approval
- Untrusted web
- Fenced as data; it can never issue instructions to the agent
- Observability
- Per-action cost, per-turn context, and an append-only audit log
This page describes the shape of the defense — what each layer is for and what it guarantees. It deliberately does not publish the trigger logic, the exact patterns each check matches, or the thresholds behind them. Knowing the guardrails exist is the point; a map for evading them is not something a safety page should hand out.
The layers
Seven, each independent, each with a single responsibility.
| Layer | Job | What it means for you |
|---|---|---|
| Perimeter | Keep the wrong actor out | Authenticated sessions, strict per-user data isolation, signed webhooks, rate limiting, and size caps. Regularly penetration-tested and re-tested. |
| Isolation | Contain what the agent runs | Code executes in a per-conversation, VM-isolated sandbox with ephemeral storage. Durability comes from version control, not from a long-lived machine. |
| Untrusted-content defense | Treat the web as data, not orders | Everything fetched from the open web is wrapped with its provenance and neutralized, so page text can never be obeyed as an instruction. This layer fails open and is logged. |
| Egress control | Bound what leaves | Outward actions — especially destructive ones after untrusted content was read — are watched and re-validated at the boundary before they go out. |
| Human approval gate | A person decides the irreversible | The agent pauses on consequential actions and shows an approve-or-decline card; sandbox commands have their own Execute/Reject gate. With no answer, the safe default holds. |
| Runtime breakers | Keep a turn from running away | Cost, time, and round bounds, graduated self-correction, and anti-spin, plus a completion gate so a turn neither stops half-done nor nags. |
| Telemetry | Nothing runs unwatched | A full per-action cost ledger, a per-turn context breakdown, and an append-only, server-only audit log of guardrail and security events. |
Telemetry
Observability is a defense layer, not an afterthought.
Every action the agent takes is measured. A cost ledger records what each step spent, so a turn’s total is always accountable. A per-turn context breakdown accounts for every component of the model’s working set and reconciles it against the real token total, with any residual reported openly rather than hidden. Guardrail and security events append to a server-only log that the app itself cannot rewrite, feeding an internal security dashboard.
Why layers
The reason it is built as independent checks.
No single guardrail can be perfect. A layered design means it does not have to be. Each layer is independent and each fails safe on its own, so a gap in one is caught by the next rather than opening the whole system. Perimeter keeps the wrong actor out; isolation assumes something might still get in and contains it; untrusted-content defense assumes the web will try to give orders and refuses to take them; egress control assumes an action might be wrong and bounds what can leave; the human gate assumes the irreversible needs a person; the breakers assume a turn might spin and stop it; telemetry assumes you should be able to see all of it. Defense in depth, by design.