Governance on t0ul

A governed control plane and operator roles

Tue, 21 Jul 2026 00:00:00 +0000

Part of my AI Security Engineering series, a local email-to-calendar agent I build, then attack, then harden. If you have not set up the lab yet, start with Set up your lab. The lessons are on GitHub, and the agent itself lives at t0ul/emaildrop.

From building it to running it

The agent is finished. Every feature is wired and every attack from the outside is contained. This part is about the other half of security, the half that starts once the thing is deployed and a team has to operate it: who is allowed to change it, what happens when it crashes, and how you prove after the fact what it did. The threats here are not a hostile newsletter. They are a mistaken operator, a leaked credential, a change nobody reviewed.

The agent gets a wallet

Tue, 28 Jul 2026 00:00:00 +0000

An identity that holds credentials

An agent that does anything in the world needs credentials to do it: a token to send mail, a grant to write the calendar, a scope to fetch a URL. It is a non-human identity with a wallet, and like any wallet, the question that matters is not what is in it when everything is fine but what happens the moment one of the cards is stolen. Credentials leak. A grant ends up in a log, a prompt, a crash dump. When that happens, you revoke it, and the entire value of revocation is that it is immediate.

Admin audit and one-click rollback

Tue, 04 Aug 2026 00:00:00 +0000

Changes go wrong

The last post was about who may change the agent. This one is about what happens when a change they were allowed to make turns out to be bad: a prompt tweak that breaks the retrieval defense, a config that weakens a check. It will happen, because tuning an agent is a live, iterative thing, and the measure of an operation is not whether bad changes occur but how cleanly you can undo them.

Incident response and the kill switch

Tue, 11 Aug 2026 00:00:00 +0000

The control you reach for under pressure

A kill switch has shown up in this book twice already, wired to the capability authority so that engaging it revokes every grant at once. This post is about the switch as an incident-response tool, in the moment you actually use it, because that moment is where a naive kill switch fails in two different ways. Both come from treating it as a simple flag, and both are the kind of thing you only discover at the worst possible time.

Data and privacy governance

Tue, 18 Aug 2026 00:00:00 +0000

Two gates on trust

Governance so far has been about the agent’s operation: who may change it, how to stop it. This post is about its supply chain, the two moments where something from outside becomes something the agent relies on. Data comes in, and a change goes out. Each is a gate, and a gate that is not enforced is a door.

Output authenticity

Tue, 25 Aug 2026 00:00:00 +0000

The output has to be checkable too

The last post signed the data coming in. This one signs the artifacts going out, and closes the governance chapter by turning the same provenance check outward. The agent produces things people act on: a calendar file you import, a summary you read and trust, an action you approve based on what it told you. All of that rests on an assumption that is almost never stated, that a thing which looks like the agent’s output actually is. Once an agent’s output has authority, that assumption is a target.