What agents can't touch

On September 16, a Hydrant change was merged and ready to deploy. The deployment stopped before it touched the database or uploaded the Worker. Production was missing a secret that another change had introduced for error reporting.

The agent shipping the issue could see what was missing. It didn’t fill in a placeholder, weaken the check or borrow a value from somewhere else. It left the issue in Human Review and recorded the blocker. I configured the secret and asked it to retry.

That stop was part of the procedure.

Permission has an edge

An agent can ship a Hydrant issue when I give it a grant for that issue. The grant covers the written scope, review, checks, merge, deployment and verification. It has a reserved list of things the agent must bring back to a person.

Secrets are on it. So are paid infrastructure, production data changes, destructive cleanup and enabling a feature that’s deliberately switched off. Finding unrelated work doesn’t enlarge the grant. It creates another thing to discuss.

The missing secret was particularly useful evidence because the release had already made progress. The code was merged. Stopping meant leaving the work visibly unfinished, which is exactly when a vague instruction to finish the job could become expensive.

The issue stayed open until the deployment and the production checks actually passed.

Deployed can still mean off

Browser sign-in for agent connections went through a similar boundary. The code and database migration reached production with the feature disabled. The discovery and token endpoints returned 404. Existing keys kept working.

Turning the feature on needed its own authorization. Testing the disabled state established that the new code could be deployed safely; it didn’t establish that a real client could complete sign-in. Those were separate claims, and the issue kept the missing evidence visible.

After the expanded authorization, the agent tested real clients in preview before enabling production and checking reconnect and revocation.

The boundary isn’t based on whether an agent is capable of doing something. An agent capable of changing a secret still needs permission to change that secret. I want that distinction written down before a deployment is waiting on it.