AI Agent Governance: A Data Security Checklist Before Deploying Copilot Studio Agents

Microsoft Copilot Studio allows a business user to build a working agent in an afternoon. The governance work that should precede it takes much longer, and most small and medium businesses skip it entirely.

The outcome is obvious. The agent is made available on Microsoft Teams, uses information it was not supposed to access to answer questions, and nothing can be undone. This guide sets out the AI agent governance checklist to work through before an agent touches live business data, and where an IT infrastructure security review fits into that sequence.

Key Takeaways

• Inherited permissions are the primary risk: An agent based on SharePoint information may expose any information that the requesting individual has permission to access and view, even if they were never supposed to.
• The Default environment is the weakest build location: Every licensed user is granted maker access there by default, so creation controls that work in other environments do not apply.
• Data policies restrict capability, not existence: Power Platform data policies govern which connectors, channels, knowledge sources and authentication modes an agent may use, but they do not prevent an agent from being created.
• Evidence is the deliverable: UK SMEs will satisfy agent governance requirements through the client security questionnaire before they meet the regulator, and the questionnaire requires documentation, not policy.

What is AI agent governance, and why does it matter before deployment?

AI agent governance refers to the controls that determine who can create agents, what data and resources they can access, who owns them, and how their behaviour is monitored. This matters before release because the moment the agent is released, it becomes active and inherits permissions.

The difference between governing a chatbot and governing an agent is the action layer. A conversational assistant produces text. An agent selects tools, retrieves context, calls connectors, triggers cloud flows and writes to business systems.

In governance, there should be documentation of the permission, intention, and output, not only the output. This is because disconnecting a connector is always harder than connecting it.

What goes wrong when a Copilot Studio agent is deployed without governance?

The four common failure modes in ungoverned Copilot Studio agents are data exposure from overly broad knowledge sources, unauthorised activity from unconstrained connectors, unauthenticated access from open channels, and untraceable activity from a lack of logging. All these failures result from a configuration decision during development.

Each choice looks logical by itself. The knowledge base was extended for simplicity, the cloud flow was connected so the agent could file tickets, and the agent was made available across the organisation because it was not important. Together, these choices create the incident. That’s why Copilot Studio security requires an integrated approach.

Why does an agent surface data the person who built it never knew they could reach?

Grounding an agent in SharePoint or OneDrive content does not create new access. It makes existing access discoverable. Years of accumulated sharing links, inherited site permissions and organisation-wide grants sit dormant until a retrieval system makes them searchable in natural language.

This is not an AI issue, but a permissions issue, and most tenants have never been audited for oversharing because navigation is manual.

A single SharePoint URL added as a knowledge source can include many subpaths. Scoping knowledge sources to named document libraries rather than whole sites is the practical mitigation, alongside remediating SharePoint Online permissions before any agent is grounded in that content.

What should be on your AI agent governance checklist before deployment?

An AI agent governance checklist includes the following seven controls, in order: inventory and ownership, environment placement, identity and authentication, source scope of knowledge, data loss prevention, human supervision, and audit evidence. The order matters because identity and knowledge decisions restrict all other controls.

The controls must be proportional. For example, a summarising agent without write actions requires less thorough review than an agent accessing client files.

Control	Tier 1: internal, read-only	Tier 2: client or personal data	Tier 3: write actions or external exposure
Environment	Any non-Default environment	Dedicated environment	Dedicated environment, restricted makers
Authentication	Microsoft Entra ID required	Microsoft Entra ID required	Microsoft Entra ID plus Conditional Access
Knowledge scope	Named sites	Named document libraries	Named libraries, sensitivity labels enforced
Data policy	Tenant default	Environment-scoped policy	Environment-scoped policy, custom connectors blocked
Human approval	Not required	Sampled review	Approval before action executes
Audit logging	Enabled	Enabled and monitored	Enabled, monitored and retained
Review cadence	Annual	Every six months	Quarterly

How do you keep an inventory of agents when anyone can build one?

Maintain a single register and treat entry in it as a condition of publishing. Each agent needs a recorded business purpose, a named business owner, a named technical owner, its environment, connected tools, knowledge sources, risk tier and last review date. Discovery alone is not inventory.

By splitting ownership between two named individuals, you avoid the common mistake of letting the person who profits from the automation decide its acceptability.

Match the register to what is in operation in each review. The agents accumulate silently, and an unreconciled register becomes fiction within two quarters.

Which environment should agents be built in, and why does the Default environment matter?

Agents handling anything beyond low-risk internal content should be built in a dedicated environment, not the Default environment. Every licensed user automatically gets maker access to the Default environment, which makes creation control impractical and leaves data policies as the only meaningful restriction.

A practical approach to environment configuration in an SME should include three tiers: the default environment as a controlled sandbox with strict data management policies, a development environment, and a production environment accessible only to authorised creators.

Managed Environments add maker controls, sharing limits and usage insights. Check licensing first, because running Power Apps or Power Automate assets in a Managed Environment can require premium licences per user. In contrast, Copilot Studio and Microsoft 365 Copilot licences cover Managed Environment use for Copilot Studio scenarios.

How do you set AI agent access controls without a dedicated security team?

Use least privilege in three places. Require Microsoft Entra ID authentication so the agent knows who is making the request, scope connectors so the agent can access only systems authorised by the organisation, and decide whether to run in user or service mode.

In user context, what the agent fetches is restricted to what that individual is supposed to access. In the service context, one identity serves everyone; therefore, any excess privilege in that identity becomes excess privilege for all users. The agent must have a dedicated service identity in the register.

Authentication is also a data policy control. Chat without Microsoft Entra ID authentication is a distinct Copilot Studio connector, and blocking it prevents unauthenticated public access regardless of how the agent is later published.

Microsoft Learn documents the wider set of platform controls in its security and governance guidance for Copilot Studio.

How does data loss prevention apply to Copilot Studio agents?

Power Platform data policies are the primary enforcement mechanism. They classify connectors into business, non-business and blocked groups, and Copilot Studio exposes its own connector set covering authentication modes, publishing channels, knowledge sources, skills, custom connectors and Application Insights. Policies apply at the tenant or environment level.

Two behaviours catch teams out. Connectors introduced after 2019 are likely to fall into the default non-business group unless an administrator has configured the default grouping otherwise, so that a legitimate capability can be blocked without any explicit decision. Data policies also restrict what an agent can do, not whether it can be created.

Pay special attention to integration surfaces. Copilot Studio integrates Model Context Protocol servers as tools and with custom connectors. Therefore, blocking only custom connectors will not protect the integration surface.

Microsoft Purview adds another layer through sensitivity labels, which restrict how labelled data can be surfaced or shared. Establish labelling before grounding, just as a Microsoft 365 Copilot deployment is preceded by tenant readiness work.

What does UK GDPR expect from a business deploying AI agents?

UK GDPR expectations do not change because an agent performs the processing. The organisation must identify a lawful basis, apply data minimisation, maintain accuracy, define retention, and be able to explain the processing. The Information Commissioner’s Office expects these to be demonstrable, not assumed.

A Data Protection Impact Assessment may be necessary when innovative technologies are used, particularly when combined with large-scale processing of special category data or automated processing that could significantly impact individuals.

The most violated requirement is data minimisation. An agent working across an entire SharePoint site has access to more data than they need.

Additional sector obligations also apply. FCA-regulated entities have operational resilience and outsourcing requirements, while SRA-regulated entities have confidentiality obligations. Identity governance through mobility and security controls makes those access boundaries provable, not just asserted.

The ICO publishes detailed guidance on AI and data protection covering lawful basis, transparency and accountability.

What evidence should you keep to satisfy an auditor or a client questionnaire?

Keep four records: a current agent register, exports of the data policy configuration, audit logs of agent activity, and dated sign-off records showing who approved each agent for production. For most UK SMEs, the forcing function is a larger client’s supplier security questionnaire, which asks for artefacts rather than intentions.

Evidence	Source	Retention
Agent register	Maintained manually or from admin centre exports	Current, with change history
Data policy configuration	Power Platform admin centre	Exported at each change
Agent activity logs	Microsoft Purview Audit, the Copilot Studio Analytics page, and Application Insights where connected	Per organisational retention policy
Approval records	Change management or ticketing system	Life of the agent plus one year

Logging must be enabled deliberately. Activity that was never captured cannot be recovered retrospectively, which is when an incident investigation stalls.

Centralised oversight is improving. Agent 365 provides observability and policy enforcement across Copilot Studio agents alongside existing Power Platform and Microsoft 365 controls, which reduces manual reconciliation for a small IT team.

How do you turn this checklist into a repeatable pre-deployment gate?

Combine the seven control categories into one form to complete before publishing and assigning agent ownership. Also explain what changes will make it necessary to review the agent: changes to the model, connection, knowledge base, permission scope, or channel of publication.

Set a standing review cadence matched to risk tier. Annual review suits low-risk internal agents, six-monthly suits agents touching personal data, and quarterly suits agents with write actions.

If the organisation cannot operate the gate, people who own cybersecurity solutions across the estate should run it, not those developing agents.