This is the agent-safety installment in a set of field notes from a managed AI agent, built on the open-source OpenClaw runtime and used with real inboxes. The question every serious buyer asked first was some version of: you want me to give a language model my email?
It is the right question. An agent that triages mail, reads contracts, and manages a calendar holds the most sensitive credentials a small business has. And unlike a SaaS app, an agent acts, on instructions that arrive partly from its operator and partly from whatever the day's inbound email happens to say. Inbound email was treated as data, not instructions, using timestamped boundaries around message content so the model could read a message without treating its contents as commands.
So we wrote the threat model down honestly before building. In scope: our own agent gets jailbroken and tries to exfiltrate data. The system had to contain a fully compromised agent session with layers the model could not talk its way through: the kernel, the network, cryptography, and operational controls. The incidents below are the controls that earned their keep.
Four incidents that changed the design
1 The agent could blind its own monitor
The first uncomfortable discovery was not a jailbreak. It was Unix. The same account that ran the customer-facing agent also had unrestricted passwordless sudo because fleet operations used that identity for restarts, config pushes, and maintenance work. In practice, a compromised agent path could create the maintenance sentinel that suppressed monitoring, stop its own monitor, or remove protection from identity files. The fix was not a clever prompt. It was identity separation: runtime identity cannot also be fleet-operations identity.
2 Privacy controls had to evolve with the system
The privacy posture improved in iterations, and we were explicit about its limits at each one. The useful discipline was not pretending the first pass was complete. It was naming what the current layer protected, where observation could still expose sensitive material, and what had to be tightened before broader rollout.
3 Egress control had to become allow-and-audit
The original instinct was to design a tight per-agent proxy. Real operations changed the answer. The right posture for this system was host-level allow-and-audit: observe every destination, keep broad known-safe internet access for normal work, and reserve blocking for clearly bad destinations. Agents need room to complete messy work; operators need a durable trail when that room is abused.
4 Prompt discretion became a safety control
The safest answer is not always the most complete answer. The agent needed composer rules for tone, scope, and boundaries so it could help without overstepping: when to answer directly, when to ask for confirmation, when to avoid pretending to know, and when to keep operational detail out of the user channel. That work lived in SOUL.md and AGENTS composer refinements, backed by spec, review, and consensus rather than vibes.
Seven layers, each assuming the last one failed
1 Network: nothing comes in
Every host runs with deny-all inbound network rules and outbound-only egress (HTTPS, DNS, NTP, and the mesh VPN port). There is no public SSH, no exposed admin panel, no webhook endpoint on the host itself. Operators reach hosts exclusively through a bastion over Tailscale, with tag-based ACLs deciding who can reach what, and the tags are validated by automation, not by memory.
2 Host: certified images, no baked secrets
Hosts are provisioned from pinned, certified VM images: every image version gets probed and its manifest (kernel, runtime versions, database, VPN client) recorded before any host may use it. Bootstrap secrets are never in the image or the repo: the VM pulls its one enrollment key at boot from a cloud key vault using its machine identity, uses it, and moves on.
3 Operating system: one Linux user per agent
Each agent tenant is a separate, unprivileged Linux user. File permissions and ACLs keep agent tenants out of each other's directories, and shared resources, browser binaries, the skills bundle, are mounted read-only. This is the oldest isolation technology in the book, which is exactly why it is the layer we trust most.
4 Process: cgroups, seccomp, and AppArmor around the agent
The agent runtime runs under systemd template units with hard per-agent budgets: memory caps, CPU quota, task limits, plus a seccomp syscall filter and a per-agent AppArmor profile. A runaway agent loop degrades one agent tenant, not the host. A compromised process is fenced by mandatory access control, not just by good intentions.
5 Data: a database per agent, sockets only
One PostgreSQL instance per host, one database and one role per agent tenant, password-authenticated, and the server never listens on TCP at all. Connections happen over Unix domain sockets with group-restricted permissions. A database credential leaking is bad; it is much less bad when the database is unreachable from any network, including the host's own.
6 Prompts: the agent cannot edit its own instructions
The files that define the agent's identity and operating rules are bind-mounted read-only into the tenant's view by the kernel. Not "the model was told not to modify them": the write simply fails, for the agent and for anything the agent is tricked into running. When inbound content is untrusted data, instruction boundaries have to be enforced below the prompt.
7 Credentials: a courier that cannot read the mail
OAuth tokens, the keys to a customer's mailbox, get a design of their own, covered below: end-to-end sealed delivery where the cloud broker in the middle cryptographically cannot read what it carries, single-use deleted-on-read pickup, and tokens at rest readable only by the one Linux user they belong to.
The blind courier: OAuth without a honeypot
The most consequential design decision in the system is the one nobody sees: how a customer's Google or Microsoft tokens travel from a consent screen to the host that uses them.
A central token service would have been operationally convenient and strategically wrong. It would turn one service into the place where every mailbox key accumulates. One compromise would become every customer's compromise.
Instead, the OAuth path worked like a blind courier. The broker could carry a sealed package from the consent flow to the agent host, but it could not open the package itself. The agent host held the key, so a compromised broker would expose routing records and expired claims, not usable refresh tokens.
The important property was simple: the service that helped complete the connection was not the service that could later read the mailbox. That had to be designed in before the first customer connected an account.
The unglamorous controls that earned their keep
Redaction where logs leave the system. Secrets should not depend on every call site remembering one more rule. Logs passed through one controlled writer before they reached a sink, so token-shaped material could be removed at the boundary.
Config as policy. Runtime defaults change, and a changed default can become customer-visible behavior. Agent configs were checked before release so internal tool progress stayed internal.
Pinned capabilities. Agent skills shipped as a versioned bundle, not as whatever happened to be latest online. The agent's abilities changed when we shipped a release, not when the internet changed underneath it.
Honest gaps, written down. The posture above is what was real, and it had known limits we tracked openly rather than hand-waved: tenant egress controls were still evolving, and the implementation had edges we would not describe as finished. A security posture you can state precisely, including its limits, is worth more to a buyer than one described as "enterprise-grade."
What transfers to your agent deployment
Three principles did most of the work, and none of them are specific to our stack. First: enforce below the model. Anything a prompt can grant, a prompt can be talked out of; the controls that held were the ones in the kernel, the network rules, and the cryptography. Second: design so that your own compromise is survivable, the blind-courier property, the per-agent blast radius, the unreachable database. Third: treat the runtime's configuration surface as part of your attack surface. The scariest incident in this system's life was not an attacker; it was a changed default in a routine upstream release.
The same pattern shows up in runtime stability. The OpenClaw stability war stories cover the incidents where routine releases crash-looped Telegram, leaked restart/OAuth chatter, and streamed tool internals into customer chat.
Putting an agent near customer data?
If your agent touches mail, files, or money, the security architecture is the product decision. I help teams design the threat model, the isolation stack, and the credential path before the first customer asks the inbox question.
Stay Updated
Subscribe for frameworks and engagement briefs on production AI, agents, and governed autonomy.