Your team publishes a procurement agent after it answers four prepared questions correctly. The tests look clean. The source scope does not. It includes the entire procurement site and a folder of draft contracts. Spending is charged to an unnamed billing policy, while the only success measure is a usage count. Good answers can coexist with excessive access, incorrect billing, and no evidence of value. Treat the agent as the user it effectively is.
Review four questions independently: who can reach it, which identity acts, how cost is measured, and what the activity shows. A passing test still needs approval. A successful sign-in still needs authorization evidence. The two billing units carry different meanings. Usage becomes value evidence only when a measured outcome supports that claim.
Five separate governance decisions
The most common agent mistake is collapsing five separate governance decisions into a single "it's shared." They're independent, and each one leaves the others unanswered:
- Maker sharing is the audience the maker picks in Agent Builder: Only you, Specific users, or Anyone in your organization.
- Catalog availability is whether an admin makes the agent discoverable through organizational agent or app management.
- Approval is whether a reviewer accepted its purpose, owner, audience, sources, and test evidence.
- Agent access is whether a particular person can open and use it.
- Content permissions cover whether those people can read the SharePoint sources it draws on.
The last two controls cause the most confusion. A person may be allowed to open an agent without having permission to read its SharePoint sources. Sharing the agent does not change those source permissions. If a pilot user cannot retrieve a source, correct the permission or narrow the audience. Widening the site creates a larger access problem.
Approval records a decision about the agent's purpose, owner, audience, sources, and tested behavior. It is not a quality warranty. Reviewers should return an agent whose source scope is broader than its purpose even after prepared tests pass. Those tests sample behavior. They cannot make unrelated draft contracts appropriate source material.
Who is the agent?
When an agent acts, an identity is behind it, and Microsoft Entra Agent ID makes that identity a first-class object you can govern. Three objects get conflated, so keep them straight. The agent service principal is the single-tenant identity (with an agent subtype) you record when reviewing sign-in and access. An agent identity blueprint is an application-level construct that creates one or more of those service principals, holds credentials, and requires a sponsor. A managed identity can serve as the blueprint's credential. It is not another name for the agent's own identity.
The identity answers "who made this request?" The downstream resource still decides which operation is allowed. A successful sign-in never proves the business operation succeeded, so correlate the identity evidence with the resource result before calling a test a pass.
Platform governance sits alongside identity. In Copilot Studio, data policies sort every connector into one of three documented groups: Business, Non-business, or Blocked, and a pre-publish security scan surfaces a maker-facing warning. The evidence discipline reappears here as a three-way verdict: Pass, Fail, or Inconclusive. If you test a connection you intend to block and the agent refuses while the destination stays empty, that's inconclusive, a different verdict than a pass: a refusal plus an empty sink doesn't prove the named connection was even attempted, so withhold publication until the evidence is sufficient.
A second distinction changes the risk question: how an agent works. An agent can act on a user's behalf with delegated access, or behind the scenes with its own access, and those ask different things. Delegated access asks whether the user, the agent, and the requested action all aligned with the approved purpose. Own access asks whether the agent's identity, its accountable owner, and its granted permissions do. An agent that joins a team workflow counts as own access, and that category is documented as public preview, so record it as own access with the preview noted rather than inventing a tidier label for it.
Two billing units that must never be added
Agents cost money, and the fastest way to produce a wrong forecast is to mix two units that only look alike. Pay-as-you-go connects eligible usage to an Azure subscription and resource group, and it's measured two different ways. A billable message is the meter unit: the documented Copilot Studio rate is $0.01 per billable message. A Copilot Credit is a feature-level consumption unit: a generative answer is 2 Credits, an agent action is 5, tenant-graph grounding is 10, and standard tools run 15 Credits per 10 responses. These are not two prices for the same request. One message does not equal one Credit, and the two forecasts stay in separate rows.
The "about $0.01 per Credit" figure is a labeled planning estimate derived from an annual pre-purchase example, leaving the Credit-to-message equivalence unproven. Replace it with your tenant's actual terms and observed Azure costs before any purchasing decision. Two more honest limits: a tenant can hold up to 50 billing policies, and crossing a policy's budget triggers an alert while spending can continue. Pair the threshold with an investigation and an authorized response. Also remember that disabling billing can take up to two hours and can make associated agents unavailable. Setting any of this up needs a documented role: Billing Administrator, AI Administrator, or Global Administrator.
Usage is not value
Copilot Analytics is five distinct tools (the readiness and adoption report, the Copilot Dashboard, the Agent Dashboard, the Consumption Dashboard, and Advanced Reporting), and their measures aren't automatically comparable just because two labels look alike. Before you compare any two values, reconcile them on six axes: window, population, organizational scope, spending-policy scope, viewer role, and metric definition. If any answer is unknown, the pair is UNRECONCILED: don't average it, subtract it, or draw a trend from it. Similar names hide different populations (the Microsoft 365 Copilot usage report and the Microsoft Copilot usage report are separate rows), and intensity bands don't sum unless the report says they're mutually exclusive.
The deepest habit here is refusing to read adoption as impact. Assigned licenses don't prove adoption. Agent responses don't prove useful outcomes. High consumption doesn't prove value. Real value work keeps three evidence layers apart: usage telemetry (did people use it?), employee sentiment (Viva Pulse feeds the Copilot Dashboard Sentiment section, and the Viva Glint Copilot Impact Survey covers productivity, satisfaction, and collaboration), and a business KPI (did the outcome move?), and it declares thresholds before seeing results. When a KPI improves during a pilot that also changed its own process template, the honest language is "associated with," not "caused by." A dashboard alone never establishes causation, and naming that limit is how you keep a governance report trustworthy.
