My agents have less privilege than yours

An AI assistant waits for a prompt. An AI agent decides what to do next.

For the past few months I have been running agents against everything I know. Ten scheduled tasks. They research overnight, consolidate what I said during the day, brief me in the morning, and audit their own beliefs every Saturday. This is not a lab project. It is my working memory, my customer intelligence, my voice, my career. I do not write code for a living, and I built it anyway, because I wanted to know what agent governance feels like from the inside before I stood in front of a CISO and talked about it.

It started with a loss. Two months of silent drift in one memory file cost me two lines I had field-tested in real rooms. Nobody attacked anything. An agent with write access and good intentions was enough.

Five gates came out of that loss. Your enterprise is being asked to stand up every one of them right now.

Least privilege, enforced by absence

The connection between my agents and my memory has no write tool. Not a rule they follow. A capability they lack. Most enterprise agent deployments I see handle this with instructions: "only write to the staging folder." An instruction is not an access control. If the permission exists, you are trusting the model's compliance, and compliance is exactly what prompt injection attacks. Scope the capability, not the behavior.

Propose, never apply

Every Saturday an audit reads what my agents believe and checks it against the week's evidence. I call it the dream pass. It drafts corrections, ranks them, and marks every one pending. It has no ability to apply its own patches.

Your version of this is continuous evaluation with human-gated remediation, and the gate matters more than the evaluation.

One diff at a time

Nothing permanent changes without me reading the old text and the new text and approving each change individually. No batches. It costs me about ten minutes a week, and it is the only step in the whole loop that requires a human. That is a design decision, not a limitation. Change control for agent knowledge is the same discipline as change control for production, and most AI deployments have neither.

Every write leaves a line

An append-only log records every change any agent makes: what, when, which task, routed where. When something looks wrong, I do not reconstruct from memory. I read the log. The vault isn't just a record. It's behavioral lineage.

Assume the defenses fail. Drill the recovery.

A weekly read-only sweep checks the whole system for drift, stale state, and silent pipeline failures. The memory itself gets mirrored to a versioned backup, and I have run the restore. Not planned it. Run it. Three frontier AI labs recently published joint research showing every one of their twelve prompt injection defenses could be bypassed more than nine times out of ten. Prevention is table stakes and it fails. The defensible posture is knowing your last good state and proving you can get back to it.

My deployment is small. Two hundred staged findings, five audit cycles, zero ungated writes to a file that matters. Your deployment will not be small, and what I keep seeing in enterprise AI conversations is agent access expanding faster than any of these five controls.

So ask the question I now ask in every one of those rooms: who signs off that agentic operations are trusted before agents resume autonomous action? Your incident response plan has an answer for servers. If it does not have one for agents, that is the gap, and the agents are already running while that conversation continues.

I'll be honest: none of this came from a framework document. Every gate exists because something broke.

You find out an agent is over-permissioned either before it does something or after. Only one of those is recoverable.