Every governance process has a settlement date. The publish button settles T+0.
Why the Copilot Velocity Gap Matters Now
There is a specific pattern we keep walking into in Microsoft-heavy estates, and it has nothing to do with a vulnerability. An E5 licensee describes an app in natural language, wires it to a SharePoint site and a Dataverse table, tests it against live data, and publishes it to the tenant. Start to broad availability: roughly two weeks, often less. The change-management process that is supposed to review that app — intake ticket, architecture review, data-classification sign-off, CAB slot — runs two to three months in most enterprises we see.
The app is in production for ten weeks before the ticket is triaged. By the time governance renders a verdict, the thing it is ruling on has been reading production records for a full quarter, and three other teams have forked it.
This is not a Copilot flaw. Microsoft built exactly what it advertised: a compressed path from idea to deployed software. The flaw is control placement. Governance was designed as a queue that sits beside the build path, and it is now being lapped by a publish button that sits on it.
| Signal | Figure | Source |
|---|---|---|
| CIOs with AI agents already deployed | 17% | Gartner CIO survey |
| CIOs deploying within one year | 42% | Gartner CIO survey |
| Unauthorized agent transactions caused by internal violations, through 2028 | ≥80% | Gartner SPA |
| Endpoints in a typical dev fleet running an unsanctioned AI agent | 88% | Ospiri fleet research |
Note what the Gartner SPA number does to the threat model. Four out of five unauthorized agent transactions are not attacks. They are ordinary employees shipping ordinary apps that quietly reach further than anyone intended. That is a latency problem, not an adversary problem — and latency problems are solved by moving the control, not by hardening the perimeter.
The Two Clocks
Any governance regime has two clocks running against each other: how fast capability reaches production, and how fast oversight reaches the same capability. When the second clock is slower, the difference is not a process inefficiency. It is an open position nobody marked.
| Stage | Build path (observed) | Review path (observed) | Spread |
|---|---|---|---|
| Idea to working prototype | 1–3 days | — | — |
| Connector wired to live data | Same day | Data-classification review: 2–4 weeks | ~4 weeks |
| Published to tenant | ~2 weeks | Architecture review: 3–6 weeks | ~5 weeks |
| Broad enterprise availability | ~2 weeks | CAB slot and sign-off: 4–8 weeks | ~8 weeks |
| Ownership assigned | Rarely | Assumed at sign-off | Indefinite |
| Decommission trigger | None | None | Permanent |
The last two rows are the ones that should bother a risk committee. The build path has no ownership step and no decommission trigger at all. The review path assumes both happen at sign-off — a sign-off that lands after the app is already load-bearing, at which point “reject” is no longer a real option. The governance function has been handed a decision it cannot actually make.
Anatomy of the Lapped Review
The failure is boringly consistent. In the estates where we have reconstructed it, it runs like this:
- A business analyst builds against real data on day one. Not a sandbox, not a masked extract — the actual SharePoint site, because that is what makes the prototype convincing to their director.
- Permissions are inherited, not requested. The app runs under the builder’s delegated scope, so it can reach everything the builder can reach. No access request is ever filed, which means no access request is ever reviewed.
- Publication is a self-service action. No gate fires, because publication was designed as a productivity feature, not a control point.
- Adoption outruns the ticket. Two or three adjacent teams start using it. Usage creates political weight.
- The review arrives and rubber-stamps. Rejecting a tool forty people now depend on costs more organizational capital than the reviewer has. Approval becomes the path of least resistance.
- Nobody owns the sunset. The original builder changes roles. The app keeps its standing credentials and keeps running, unattended, against production data.
Step five is where the governance program actually dies. Not from being ignored — from being structurally unable to say no.
Pricing the Gap
Treat each published app as a position and the estate as a book. The exposure is not the average app; it is the tail. A useful first-order frame:
Governance Gap Exposure = (Publish Rate × Review Lag) × (Data Sensitivity × Blast Radius)
The left-hand term is how many ungoverned positions you are carrying at any moment. The right-hand term is what a bad one costs. Both are measurable today, and neither appears on a standard risk register.
| Factor | What to measure | Where it lives |
|---|---|---|
| Publish rate | Apps and agents published per month, per business unit | Power Platform admin center, Copilot Studio telemetry |
| Review lag | Median days from publish to completed review | Your ITSM queue |
| Data sensitivity | MIP/Purview label of the highest-classified source touched | Purview, plus kernel evidence of actual file opens |
| Blast radius | Write scope, egress destinations, and downstream systems reachable | Endpoint ground truth — not the app’s declared manifest |
The distinction in the last row is the entire argument. A declared connector list is a self-report frozen at publish time. What the process actually opens on disk at 2am, three sprints later, is a different number — and it is the only one that prices the position correctly.
Where the Gate Belongs
If the review cannot outrun the publish button, stop racing it. Move the gate onto the provisioning path so it fires at the moment of creation, and size its weight to exposure rather than applying it uniformly.
| Control point | Fires when | Right response |
|---|---|---|
| Provisioning-time classification | App is created, before first connector | Auto-tag by data sources requested; low-risk clears instantly |
| Publish-time gate | Publish action is invoked | Low blast radius: pass. Labeled data or write scope: human-in-the-loop |
| Runtime enforcement | Process opens a file or makes egress | Kernel-level allow, sandbox, or copy-on-write redirect — in-line, not logged after |
| Continuous reconciliation | Ongoing | Compare declared footprint against observed behavior; flag drift |
Two distinctions worth being precise about. Risk-based gating is not block-by-default — the majority of citizen-built apps touch nothing sensitive and should clear in seconds, or you will be routed around within a quarter. And copy-on-write is not block-on-deny — the agent gets a working file and keeps functioning; the original stays untouched. That difference is why the control survives its first political review. See /agent-governance/ for how the gating tiers map to policy, and /copilot-firewall/ for the Microsoft-estate specifics.
What CISOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1 | Pull publish counts and median review lag for the last two quarters | The actual spread, in days and app-count | 2 days |
| 2 | Rank published apps by highest-classified data source touched | Top-decile exposure list | 1 week |
| 3 | Reconcile declared connectors against observed endpoint behavior | Drift report: what apps reach beyond their manifest | 2 weeks |
| 4 | Move one gate from the review queue onto the publish path | A control that fires at T+0 instead of T+90 | 3 weeks |
Step three is the one that changes the budget conversation, because it converts “we think this is fine” into a list with names on it.
The Bottom Line
A governance process that settles slower than the capability it governs is not a control — it is a record of decisions that were already made for you. The Copilot velocity gap is not a Microsoft problem and not a citizen-developer problem; it is a control-placement problem, and it is fully solvable without slowing anyone down. Gates that ride the provisioning path clear low-risk work instantly and reserve human attention for the tail. Kernel-level enforcement handles what happens after the gate, when the declared footprint and the actual one diverge. The organizations that get this right will publish faster than the ones that don’t, because they will be the only ones who can afford to say yes.
If your team is sizing this for the fall planning cycle, request a working session. We will walk through your Power Platform and Copilot Studio publish telemetry, produce a drift report reconciling declared connectors against observed endpoint behavior, and scope a deployment. Ninety minutes.