Five Checkpoints. Zero Signatures.

Picture the morning of June 3. The head of compliance at a regional bank opens three browser tabs before her second coffee.

The first is a White House executive order signed the previous day, directing the federal government to coordinate the scanning, discovery, validation, and remediation of AI vulnerabilities through a new cybersecurity clearinghouse (Executive Order 14409, whitehouse.gov, June 2, 2026).

The second is a post from Microsoft's engineering blog announcing the Agent Control Specification, an open standard that places five validation checkpoints across an AI agent's lifecycle: input, model decision, memory update, tool execution, and output (Microsoft Foundry Blog, Sarah Bird, June 2, 2026).

The third arrives a day later. Microsoft's AI Red Team has published an updated taxonomy of failure modes grounded in twelve months of red team engagements against deployed agents, and one of the most consistently exploited failure modes was human-in-the-loop bypass, achieved through consent fatigue and incremental escalation (Microsoft Security Blog, June 4, 2026).

She forwards all three to her CTO with one sentence: which one of these tells us who authorized our agents in the first place?

All three are silent on that question.

Here is what the three announcements share. Each one addresses what an AI agent does while it runs. The executive order coordinates who finds security vulnerabilities and patches them. The Agent Control Specification stops the agent the moment it tries something outside its rules. The red team report names how those rules get bypassed. All real work, aimed at real problems. All three stop at the same place: the moment before any of it applied, when a human decided what the agent was allowed to do.

Somebody made that decision. They decided this agent could draft the email, move the funds, update the record, recommend the settlement amount. They decided what conditions made those actions appropriate and what would make them wrong. In many regulated organizations right now, that decision happened in a meeting, or in a one-line approval on a ticket, or in the silence that follows a launch when everyone moved on. The decision was never written down as an accountable act. The person who made it was never told their name was attached to it.

There is something almost funny buried in the red team finding. One of the most reliable ways to defeat an enterprise AI governance program turned out to be making the humans responsible for oversight do too much of it. Give a compliance officer four hundred agent decisions in a shift and they click through them the way people click through cookie consent. The governance structure assumed a human was watching. The human was technically present. The watch had stopped. The approval workflow was designed by people who understood process. What they built was a form, not a decision.

A week before the June announcements, Microsoft published its own internal guide for governing AI agents at scale. It states that effective governance must be human-led because accountability and judgment remain essential (Inside Track Blog, Alex Fleck, May 21, 2026). Four chapters follow. A governance matrix. A lifecycle model. A deployment review process. Every chapter addresses a different operational layer. In the published guidance, the step where a named human records the authorization decision for a specific agent's permitted scope does not appear. Microsoft wrote the principle correctly. The instrument to fulfill it was left out of the guide.

For a security team, the new enforcement tools are genuinely worth deploying. For a compliance officer at a regulated institution, they are table stakes. The examiner does not ask whether the agent has guardrails. The examiner asks who authorized the agent to operate inside those guardrails, on what business basis, and who answers if the authorization was set too broadly. The enforcement standard Microsoft shipped this month is the strongest the market has produced. What it enforces is a rule someone wrote. Whether anyone authorized that rule, on what basis, and who owns the consequences if it was wrong, those questions are absent from every piece of published June guidance reviewed.

The response is not a sixth control. It is a different kind of document.

Every agent in production needs three things the June announcements leave unaddressed. A plain-language statement of what it is authorized to do. The name of the person who made that decision and the date they made it. A schedule for when that authorization gets reviewed against what the agent actually does now. This is the Authorization Coverage Lifecycle. The enforcement standard Microsoft shipped this month is the strongest mechanism available for enforcing that record once it exists. What it cannot do is create the record, because creating the record requires a human to make a decision, own it, and put their name on it before the agent runs a single task.

Pick one production agent. Produce the document that names who authorized its scope and what business condition made that scope correct. In many organizations, the security review exists. The privacy assessment exists. The technical sign-off exists. The authorization record does not, because the governance programs those organizations followed never asked for one.

The agent will do exactly what its rules permit. The harder question is whether anyone decided what the rules should be, and whether that person knows their name is the answer.

In your organization, who is the named individual accountable for the authorization decision behind your most consequential production agent, and what happens to that accountability when the agent's scope quietly changes?