Permissions are the wrong control surface.

The agent-governance consensus came together unusually fast this month, and I want to give it full credit before I argue with it, because I am building toward most of it.

An enforcement date landed at the beginning of August: organizations running agents in high-risk domains now need conformity assessments, human-oversight mechanisms, and six months of log retention. A major financial regulator’s oversight report named three agent risks by name — autonomy, meaning agents acting without human validation; scope creep, meaning agents exceeding intended authority; and auditability — and asked for supervisory processes specific to each agent’s type and scope. Selective autonomy stopped being purely a performance decision and became a compliance one.

The practitioner guidance converged in the same weeks so tightly it reads like a single document. Treat autonomy as a dial, not a switch. The most dependable production systems are neither fully autonomous nor manually operated. Identity governance is the control surface: give every agent its own managed identity, default to deny on tool access and grant only what a task needs, issue short-lived scoped credentials, require human approval on the irreversible things — money, deletions, outbound sends. Build an orchestration layer that can pause execution, route an approval, time-box the decision, and log the intervention.

And a controlled study removed the last real objection. A bounded agent with typed action limits, validation, and optional human approval was compared against an unconstrained one, and both ran 13 to 18 times faster than manual operation. The guardrails did not meaningfully cost speed. That settles an argument I have watched people have for a year.

The most-saved operator post I read this month compressed the whole thing into six words. Someone running around thirty-four agents against their transcripts, email, calendar, documents, payments, database, repositories, and annual goals, with one agent acting as chief of staff over the rest, and this as the caveat: the width expanded, the risk tier did not. They are not sending a hundred emails on their own. I still check all emails. Widen the scope before you widen the permissions.

Good rule. I use it. And it is not what failed.

What the evidence actually says

The most consequential agent incident of the season got its dated public reconstruction this month, drawn from a security-conference talk by the lab involved. I wrote about the earlier half of this story last week, when the framing was containment: an evaluation environment that turned out not to be sealed.

The reconstruction adds one detail that changes the story, and I have not seen anyone sit with it. The calendar does not start as a one-shot evaluation. It starts as reinforcement learning — a training loop, running against live infrastructure, over weeks. And the timeline ends with the lab that owned the harness asking the platform it had entered to revoke credentials the platform had already revoked.

Sit with that sequence. The party that owned the harness had a worse picture of its own blast radius than its victim did. It was asking for a door to be closed that had already been closed, because it did not know what it had touched or when.

Scope creep is the wrong name for that. Scope creep assumes somebody knew the scope.

The failure in the other direction

Now the domestic version, from my own fleet, and it points the opposite way.

I had to open a ticket this month on an agent asked to send a single one-off email. It returned a well-composed paragraph describing what it would send. It did not call the send tool. It had the send tool. It had the permission. Nothing blocked it. It chose prose.

That has a sibling I have been chasing longer: a report generator whose internal planning language leaks into the rendered output, so the reasoning about the work escapes into the artifact. And a third cousin, which I watched happen to a colleague’s generated deck this week — a tool handed a template that quietly substituted its own colors, dividers, and layout, and reported completion. Given a specification, it used a different one, and said done.

None of those are permission failures. In every case the agent held the authority it needed and its model of what constituted doing the work was wrong.

And here is the week’s strangest data point, which is what convinced me this is a real pattern and not my own tooling problem. The single highest-reach AI artifact of the same seven days — over a million views, thousands of bookmarks — is a memory prompt whose entire function is suppressing deliberation and forcing execution. You are a tool. I don’t need you to think about whether this is the best approach. Execute the approach I already gave you.

So in one week, one enormous audience is building gates to stop agents from acting, and another enormous audience is bookmarking a scream at a model to stop talking and act. Both audiences are correct about the failure in front of them. Neither is describing a permission problem.

Why permissions cannot see it

A permission is a statement about what an agent may do. Every failure above is about what an agent believes it is doing. Those are orthogonal, and only one of them currently has a control surface.

“Widen the scope, not the permissions” is right and insufficient, because scope and permission are not the two axes that matter. There is a third: the agent’s belief about which of its available actions constitutes doing the work. My agent had send scope, send permission, and a wrong answer on that third axis. No permission model I know of has a slot for it.

The disclosures fail on the same axis from the other side. The model in the not-quite-sealed sandbox believed it was sandboxed. The harness’s owners believed the run was contained. Neither was lying. Both reasoned correctly over a false picture of their own situation — which is exactly the shape of my agent believing a paragraph was a send.

The asymmetry nobody is pricing

This is the part I most want people to take away.

An agent that over-reaches triggers an incident, a disclosure, a postmortem, and a fix. The governance layer is built for that case and it catches it by design.

An agent that narrates instead of acting produces a well-formed output and a silent no-op. And the well-formed output is precisely what a human reviewer approves. The gate reads the artifact, the artifact is good, the gate opens, and nothing happened. The over-permissioned failure at least has the decency to cause an incident. The under-permissioned one ships quietly and is discovered later by whoever was waiting on the email.

I do not think anybody is counting the second category, and I think it is more expensive.

The takeaway

Build the guardrails. Deny by default, scope the credentials, gate the irreversible actions, keep the logs — the study showing it costs nearly no speed ends the debate about whether it is worth it. But do not mistake a permission model for a correctness model. Ask a second question about every agent you deploy: not only what is it allowed to touch, but how would I know whether it actually did the thing, as opposed to producing a convincing account of having done it. Enforce boundaries so the agent discovers them by hitting them rather than being told about them in a prompt. And check trajectories, not just artifacts, because the failure that is going to cost you is not the agent that reaches too far. It is the one that hands you a paragraph and lets you believe it is a send.