The switch nobody logs

For most of the last two years, the honest reason agent governance did not exist in a given organisation was that building it was expensive. Someone had to write the audit trail. Someone had to build the permission model, the sandbox, the credential handling and the trace. All of it sat between a working prototype and anything defensible in production, and almost none of it was work anyone had been funded to do.

That reason has largely gone. Claude Managed Agents, in public beta since April, hands over the harness: hosted execution, secure sandboxing, scoped permissions, identity management, and a session event stream that persists server side and can be read back in full. Notion, Rakuten, Asana and Sentry are shipping on it. Whatever one makes of the vendor claims about development speed, the governance primitives are real and they arrive switched on.

This ought to be good news for anyone who has spent time arguing that agent activity needs to be bounded and traceable. Mostly it is. But it moves the problem rather than solving it, and it is worth being precise about where it moves to.

What the platform now hands you

Three things, and they are not equally interesting.

The harness becomes someone else’s problem. The agent loop, the sandbox, tool execution and credential handling sit with the platform. Teams configure the agent rather than building the runtime around it, and when a new model arrives they point the agent at it and rerun their evaluations.

The trace comes free. Session events persist server side and can be fetched in full. Every tool call and every decision is captured without anyone instrumenting anything first. For provenance work this is a meaningful shift, because the most common reason provenance data does not exist is that capturing it was a project nobody started.

And the permission model becomes declarative. This is the part worth slowing down on.

A control that acts, not a log that records

Most agent oversight in practice is retrospective. Something runs. It is logged. A human reads the log afterwards if anything goes wrong, and often not even then. That is cataloguing. It produces evidence for a conversation that happens later, which is useful, but it does not intervene.

A permission policy behaves differently. Tools carry one of two settings. Either the call executes without confirmation, or the session stops, emits a state indicating it requires action, names the blocking call, and waits. Nothing proceeds until a human returns an explicit allow or deny, and a denial can carry a written reason back to the agent so it can adjust rather than simply retry.

That is a control at the point of action. It sits in the path of the work rather than downstream of it.

The distinction is not between having a control and having none. It is between having a control and having a control that changes what happens.

Which is exactly where the gap moves

I have written before about policy moving out of the prompt and into the harness, and about why enforcement is not the same as evidence. This is the next turn of that argument. The harness can now stop an agent mid-task and demand a human decision. What it cannot do is tell you whether that decision was considered, whether the person granting it understood what they were approving, or whether the policy still says today what it said at launch.

A control that exists is one thing. A control that demonstrably changes behaviour at the point of action is another. The distance between those two states is where most governance programmes quietly live, and shipping the controls in the box does not close it. It just makes the gap harder to blame on tooling.

Three details worth reading closely

• Defaults are the policy. The agent toolset runs permissively unless it is configured otherwise, while connected tool servers default the other way. Most teams never revisit a default, so the default is the governance posture for most of the lifetime of most agents. Find out which way each one falls and write it down rather than assuming.
• Custom tools sit outside the policy engine. Where you define your own tool, the platform hands the decision back to your application. That is reasonable design, and it means your application is the control. It should be reviewed as one.
• State residency is not the same as compute residency. These sessions are stateful by design, which is what makes them useful and also why they carry conversation history, sandbox state and outputs on the provider side. Self-hosted execution addresses where the compute runs. It does not address where the history rests. In financial services and other regulated settings those are separate questions and should be asked separately.

Govern the configuration, not just the run

The failure mode here is not dramatic. Nobody disables oversight in a board meeting. What happens is that a team ships with approvals switched on, hits a delay at an inconvenient moment in week three, and relaxes a policy to keep moving. The change takes about forty seconds. It is rational at the time. It is also completely undocumented, because the configuration was never treated as the kind of thing that gets documented.

So treat it as one. Version the permission configuration alongside the code it governs. Require a written reason for every relaxation, in the same way a production change would require one. Review the permission posture on the same cadence as the system it constrains, and report changes to it as a governance metric rather than an engineering detail. None of this is expensive now that the controls themselves are free.

The question to carry into any adoption conversation is not whether the platform supports human oversight. It plainly does. The question is whether, six months in, anyone could tell you when the policy last changed and who decided it should.

A control that can be switched off without leaving a record is not a control. It is a preference.