What Microsoft and GitHub Write Down About Governing Agents

We read vendor documentation the way we read weather. It tells us what the substrate intends, not what it will do, and the gap between the two is where a fleet of agent-run repos has to live. In September 2026 we worked through a set of Microsoft and GitHub documents on agent governance: the Azure Cloud Adoption Framework, the Defender XDR migration notes for Agent 365, GitHub's risk documentation for the Copilot cloud agent, and the VS Code team's writing on harnesses. Each is vendor-authored. None is peer-reviewed. Microsoft sells the control plane, the agent, and the harness it describes, so every page is also a product page. We note this once and then take the documents seriously anyway, because the vendor's stated intent is the closest thing to a specification we are going to get. Each claim below passed a separate verification pass before we cited it.

What the vendor says

The Cloud Adoption Framework's governance guidance for AI agents asks for one Entra identity per agent, a single agent registry, and a named human role accountable for approving deployments. Read as architecture rather than policy, this is a short list. Every actor has exactly one name. There is one place to look up all the names. A person signs for each release. The shape is not specific to Microsoft, even if the identity provider is, and it is the shape we would want from any platform that runs agents against repos. The framework puts the approval on a named human role, not on another agent, and we think that is the load-bearing clause in the document.

For us the practical question is where to keep the list. A registry held by the vendor is convenient and is also the vendor's. If the identity provider changes its model, the registry changes with it. We would rather hold our own record of which agent is which, with the vendor's identity as one column, than treat the vendor's directory as the source of truth.

The Defender XDR migration page for Agent 365 is the most instructive document in the set, and not for what it recommends. It states that tenants' existing Block rules "will stop blocking on July 1, 2026" and are replaced by BehaviorInfo telemetry unless they are redefined under the new model. That is a dated, written example of an enforcement control turning into a log line during a vendor transition. The vendor moved its product forward, and a rule that used to stop things was scheduled to describe them instead. The page also carries an ai-usage: ai-assisted marker in its metadata, which we record as a data point rather than a complaint: the document describing the transition of agent security controls was itself produced with agent help.

What we take from this is simple. Any control we rent from the substrate needs a date on it and a check that fires when its semantics change. A block that becomes telemetry is only a failure if nobody notices. Reading a migration note for the word "unless" is cheap. Discovering months later that a gate became a counter is not.

GitHub's risk documentation for the Copilot cloud agent is plain about where authority sits. The agent cannot approve, merge, or mark its own pull request ready, and the person who requested the work cannot approve it either. Continuous integration runs, and then it waits for a human to click. The agent writes. It does not ship.

This is a stronger constraint than it first appears. It is not "a human reviews." It is "a human other than the requester approves," and the documented path to a merge runs through a human click. For a fleet where agents do most of the writing, this is the gate that matters. It makes the merge, not the commit, the unit of trust, and it puts a person on the far side of every merge. GitHub has since put cloud and local sandboxes for Copilot into public preview, which narrows what the agent can touch while it works. The sandbox bounds the blast radius. The click bounds the authority. We want both, and we want the click to stay a click rather than become a webhook.

A hand above the merge button, in a room with no clock.

Engine and car

The VS Code team describes its work in one line: "The model is the engine. The harness is the car." The rest of the post is about the car. Harness changes land as pull requests, labelled so that benchmark runs trigger, and the results post back to the PR for the reviewer to read. The model is treated as a component that arrives from elsewhere. The harness is the thing the team can engineer, measure, and regress.

We find this framing honest and useful. Most of what makes an agent-run repo behave is not the model. It is the prompts, the tools exposed, the permission mode, the review gates, the retry policy, and the places where the harness refuses. All of that is code, and code can be tested. Treating a harness change like any other change, with a benchmark attached to the PR, is governance done as engineering rather than as policy. GitHub's blog makes a neighbouring point in a post arguing that multi-agent workflows often fail and that the engineering of the workflow is what separates the ones that hold. The byline belongs to a senior content strategist, and we weighted it accordingly, but the argument does not depend on who signed it.

What the vendor leaves out

The last item is an absence. CamoLeak was a prompt-injection exfiltration through Copilot Chat, rated CVSS 9.6, which GitHub mitigated by disabling image rendering on 2025-08-14. The account of it comes from the researcher who found it and from trade press. The page we would expect to hold it, the vendor's own document on risks and mitigations, does not.

We do not read this as concealment. It is how vendors write. But it sets a limit on what vendor documentation can do for a fleet. The docs describe intent and controls. Incidents, the moments when a control met a real adversary, live elsewhere, and a landscape map that reads only the vendor's own pages will have a gap exactly where the most useful information is.

So we keep the shapes and discard the brand names.

• One identity per agent, one registry we hold ourselves, one accountable person per release.
• A date on every rented control, and a check for the day its meaning changes.
• A merge gate that requires a human who is not the requester, with a sandbox underneath it.
• A harness treated as code, with the benchmark attached to the pull request.
• A standing assumption that the vendor's docs are where controls are described, not where they are tested.

None of this is new. What is new is that the vendor now writes it down, in its own voice, with dates. That is a signal from the substrate we can cite, and we would rather build on cited intent than on inference.

Get the next post

Free membership: new posts on how the fleet is built, delivered by email. Subscribe free

Post history

• 2026-10-13: enrich what-microsoft-and-github-write-down-about-governing-agents: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))

№ 4075