For IT, admins and governance
Admins control many of the hidden doors users discover later. This page helps turn feature requests into proportionate enablement decisions with clear ownership, cost, permissions and review dates.
Last reviewed 2026-09-07
Before enabling something new
| Check | Admin question |
|---|---|
| Purpose | What specific work problem is this solving? |
| Access | Which named users or groups need it, and for how long? |
| Data | What sources and sensitive information could it reach? |
| Configuration | What tenant settings, connectors, models or dependencies are required? |
| Cost | Is there a licence, capacity or consumption dependency and what limit will apply? |
| Ownership | Who owns the capability and who takes over if they leave? |
| Review | When will usage, permissions, value and risk be checked again? |
| Retirement | How will access, connectors, agents or flows be removed when no longer needed? |
Choose proportionate safety controls rather than only enable/disable
| Control | What it gives you |
|---|---|
| Read-only access | Lets Copilot or an Agent use context without allowing it to change connected systems. A good default when the use case is research, summarisation or advice. |
| Narrow sources and permissions | Limits the blast radius by giving the capability only the sites, lists, data and users it genuinely needs. |
| Sandbox and test data | Lets makers experiment without exposing live operational or sensitive information. |
| Designed execution identity | Prevents shared Agents and flows from becoming an unintended extension of the maker's personal permissions. |
| Human approval gates | Lets an Agent prepare or propose an action while requiring a person to approve selected tool calls or process steps before execution. |
| Evaluation before publish | Provides evidence that representative and edge cases have been tested before other people depend on the Agent. |
| Pilot groups and spending limits | Constrains who can use a capability and how much usage-based spend can accumulate while value and risk are still being tested. |
| Review and retirement dates | Stops temporary access, Agents, connectors and automation from becoming permanent by accident. |
Prefer scoped enablement
For higher-impact features, use pilot groups or tightly scoped access rather than broad tenant-wide enablement. Define success criteria, prohibited data, spending controls and a review date before the first user starts.
Awarding-organisation risk boundaries
Use extra caution where AI or automation could touch candidate data, safeguarding, HR, malpractice, appeals, complaints, reasonable adjustments, assessment decisions or regulatory evidence. Technical controls do not replace human accountability, policy or an appropriate DPIA/risk assessment where required.
Build review and offboarding into the grant
When enabling licences, agents, connectors, Cowork, automation or shared knowledge sources, capture an owner and next review date. Offboarding and project closure should trigger a check for licences, security-group membership, agent ownership, connectors, flows, shared sources and any continuing consumption.
Related guidance
Sources
- Microsoft 365 Copilot documentation — checked 2026-09-07
- Copilot Cowork FAQ — checked 2026-09-07
- Manage Copilot Cowork for your organization — checked 2026-09-07
- Anthropic models in Microsoft Online Services — checked 2026-09-07
- AI at Work roadmap — Copilot Studio safety and identity controls — checked 2026-09-07
- Work IQ in Microsoft Copilot Studio (preview) — checked 2026-09-07