600 Copilot Licences, 40 Agents, One HR Incident

Roughly 175 of 600 licences cannot deliver value - identify them by cause, not by name.

• 70 service accounts with no mailbox - Copilot is a user-productivity licence. A shared account with no mailbox and no interactive sign-in has nothing to ground on.
• 45 disabled users - licence is held but unusable; reclaim immediately.
• 60 users with on-premises mailboxes - Copilot depends on Exchange Online for mail and calendar grounding; these users will get partial or no capability until their mailboxes move. Defer these, do not delete them.

Reclaim and reassign:

1. Export current assignments and cross-reference against sign-in activity and Copilot usage reports - usage counts, not intent, decides who keeps a licence in the next wave.
2. Stop hand-editing. Create a security group for Copilot entitlement and assign the add-on to the group; group-based licensing removes the licence on removal from the group, which is the behaviour you want when someone leaves.
3. Reclaim from disabled and service accounts first, and reissue to the waiting list.

Report the number up front: 175 licences at list price is a figure a sponsor understands instantly.

The incident needed two failures at once: an over-broad share and an over-privileged connection.

Immediate response:

• Unpublish or disable the agent so it stops answering, and restrict its sharing.
• Preserve evidence before cleanup: conversation transcripts, Copilot Studio analytics, Power Platform audit logs. Determine who actually queried the grievance table - 'shared org-wide' is exposure, not proof of access.

Root causes:

• Sharing: org-wide sharing of an agent that returns sensitive rows.
• Identity of the connector: the SQL connection used an account with read access to the whole table, so the agent had no per-user filtering. Agent permissions are the connector's permissions unless per-user authentication is configured.

Control set:

1. Restrict who can share agents; disable org-wide sharing unless a review approves it.
2. Restrict who can create agents, and remove that ability from the general population in the default environment.
3. Apply DLP policies that block or gate the SQL connector outside an approved environment.
4. Design the data layer so the connector cannot return more than the caller may see - per-user authentication, or a filtered view keyed to the requester.
5. Require an owner and a stated data classification on every agent before publishing.

Note what is not a control: freezing all agent creation. It stops the good agents too, and the existing 39 keep running ungoverned.

The question is not which is cheaper per message - it is who owns the risk of being wrong about volume.

• Capacity packs: prepaid message capacity shared across the tenant, billed monthly. Best when usage is predictable and steady. Risk: unused capacity is wasted spend, and a runaway agent can exhaust the tenant's pool and starve production agents.
• Pay-as-you-go: link an Azure subscription and pay per message. Best for pilots, spiky workloads, and seasonal agents that run for six weeks a year. Requires an Azure subscription and the right billing role to exist before you need it, and it needs budget alerts or it fails silently at the cost layer.

Decision criteria: variance of monthly message volume, number of agents, tolerance for unused spend, and whether finance accepts per-message charges appearing on an Azure bill.

Guardrails either way:

• Set per-agent limits so one agent cannot consume the shared pool.
• Review Copilot Studio analytics monthly against the capacity report.
• Keep the three heavy agents in a dedicated environment so their consumption is visible and separable from everything else.

Recommendation to give: start pay-as-you-go for the pilot quarter to measure real volume, then buy capacity once the curve flattens.