The Microsoft Agent Governance Kit

The Microsoft Agent Governance Kit

Agent Builder, Copilot Studio, and the GitHub Copilot harness. The controls that exist, where they fall short, and the manual configuration to close the gap.

Microsoft gives you the controls. It does not turn them on for you. Every default in Agent Builder and Copilot Studio is set for adoption, not for safety, and the gap between the two is manual admin work that somebody has to do on purpose.

Who this is for: Microsoft 365 and Power Platform admins told to turn on agents, AI and transformation leaders who need a governance position they can defend, and anyone about to let the GitHub Copilot harness loose in Copilot Studio without ring-fencing it first.

How to use it: Part 1 is the map. Part 2 is the shortfalls, the part vendors skip. Part 3 is a runbook, in order, with the admin centre and setting for each step. Part 4 is the gate, when to allow what. Part 5 is a pre-flight checklist you can copy.

Part 1: The map

1.1 There are three surfaces, not one

Surface A: Agent Builder (Microsoft 365 Copilot)

Lightweight agents built in natural language inside the Microsoft 365 Copilot app. Grounded on Microsoft Graph content a user can already reach: SharePoint, Teams, Outlook, public websites, and data indexed through Microsoft 365 Copilot connectors. Built for individuals and small teams. SharePoint agents are a parallel route to the same problem: anyone with SharePoint access and a Copilot licence, or a pay-as-you-go policy, can create an agent scoped to sites and files they can access.

Governance home: Microsoft 365 admin center, under Agents, plus Microsoft Purview for labels, audit, and DLP.

Surface B: Copilot Studio, standard harness

Full Copilot Studio agents built on the standard harness. Topics and rules the maker defines. Predictable paths. The maker decides what happens next. Billing is the Copilot Studio capacity model.

Governance home: Power Platform admin center (PPAC) for environments, data policies, and publishing, plus Microsoft 365 admin center for which agents appear in the Microsoft 365 and Teams catalogues.

Surface C: Copilot Studio, GitHub Copilot harness

The same Copilot Studio, a different runtime. A harness is the layer between the model and the agent configuration. It decides when to call the model, what to send it, and what to do with the output.

The GitHub Copilot harness is built for reasoning-heavy, multi-step work. Give it a goal. It breaks the goal into steps, calls tools across connectors, knowledge, MCP servers, and connected agents, and if a path fails it retries and finds another one. It creates and edits Word, Excel, PowerPoint, and PDF files natively. It supports skills and persistent memory. Each task runs in a sandbox governed by Copilot Studio. Billing is Copilot Credits, usage based, not capacity.

The other harness in the family is the Copilot chat harness, which extends Microsoft 365 Copilot Chat with organisational knowledge and publishes internally only.

1.2 The name trap

Read this twice, because your security team will get it wrong the first time.

The GitHub Copilot harness is a Microsoft Copilot Studio authoring and orchestration framework. It is not the GitHub Copilot service. Microsoft states this plainly on Learn: the harness shares underlying technology and SDK components with GitHub Copilot, but customer data is not sent to or processed by the GitHub Copilot service when agents run in Copilot Studio. Copilot Studio privacy, security, compliance, and data residency commitments continue to apply.

So the risk is not that your data goes to GitHub. The risk is what the harness does inside your own tenant, with your own connectors, your own knowledge, and your own overshared files, at machine speed, with no fixed path to audit in advance.

GitHub proper is a separate surface again. If your makers also use GitHub Copilot, the GitHub MCP server, or a GitHub connector, that needs its own hardening. Appendix A covers it.

1.3 The graduated view

Microsoft’s own guidance zones this work, and the zones line up with the graduated architecture on this site:

• Zone 1, Citizen: Agent Builder and SharePoint agents. Personal, read-only, private by default.
• Zone 2, Partnered: Copilot Studio in IT-managed environments, with IT-approved makers and IT approval to publish.
• Zone 3, Professional: Copilot Studio plus Foundry, with standard ALM and the strongest controls.

The GitHub Copilot harness belongs in Zone 2 at the lowest, and Zone 3 for anything that touches sensitive data or takes actions. If a GitHub harness agent is running in your default environment, shared from a maker’s personal space, you have skipped two zones. That is the whole problem in one sentence.

1.4 The principle Microsoft repeats, and what it does not mean

Microsoft’s core promise is: no new privileges. An agent respects existing Microsoft 365 permissions. If a user cannot open a SharePoint site, the agent does not surface it.

That promise is true. It is also not protection. It means an agent inherits your existing oversharing at full speed. Everyone except external users links, Anyone links, broken inheritance, ownerless sites, oversized audiences: all of it becomes agent grounding on day one. Fixing permissions was always important. Agents make it urgent, because the reader is no longer a person browsing. It is a runtime that reads everything its user can reach, summarises it, and can write it into a new file.

Part 2: The shortfalls

These are not bugs. Most are documented behaviour. The shortfall is the distance between what leaders assume is governed and what is actually governed by default.

2.1 Defaults are permissive

• Agent Builder user access defaults to All users.
• Org-wide sharing of Agent Builder agents defaults to All users.
• New Power Platform connectors default into the Non-business group, not Blocked. Non-business is not blocked. A connector sitting in Non-business can still be used, and can share data with other connectors in the same group.
• By default, no data policy exists at all in Power Platform until an admin creates one. Data policy enforcement has been in effect for all tenants since early 2025, with exemptions no longer supported, but the policy content is still yours to write.
• Blocking maker-provided credentials ships off. See 2.6.

2.2 The default environment is the landing zone

On first use, agents land in the default environment unless an admin has done something about it. Microsoft advises using a non-default production environment for agents you deploy to production. Nothing prevents the opposite by default. The default environment is shared, weakly governed, and the hardest place to apply tight rules without breaking everything else in it.

2.3 Sharing controls are narrow, and none of them reach backwards

• The Agent Builder sharing control applies only to agents built with Agent Builder. It does not govern Copilot Studio sharing, and it does not govern SharePoint agent files.
• It applies only to new sharing actions. Agents already shared stay shared until you change them manually, one by one.
• Copilot Studio sharing limits are a Managed Environments feature. Not a tenant default. If the environment is not managed, the limits are not available.
• Sharing rules are enforced at share time only. They do not revoke access people already have.
• Sharing rules can take up to an hour to start being enforced.
• Sharing rules only apply to agents that require authentication. Unauthenticated agents are outside them.
• In Dataverse for Teams environments, sharing rules do not affect sharing to the team the environment is bound to.

2.4 DLP is one connector at a time, and partial blocks mislead

Data policies in Copilot Studio work connector by connector, in three groups: Business, Non-business, and Blocked. Data cannot flow between connectors in different groups inside the same agent or flow.

That design creates a predictable admin error: blocking one door and reporting the room as secure.

• Blocking knowledge from local document uploads does not block SharePoint and OneDrive knowledge. They are separate connectors.
• Blocking public websites as a knowledge source does not block the HTTP connector. An agent that cannot ground on the web may still be able to call the web.
• Blocking one channel does not block the others. Direct Line, Teams and Microsoft 365, SharePoint, Facebook, WhatsApp, and Omnichannel are separate entries.
• Blocking a Power Platform connector also blocks MCP tools that depend on that connector for connectivity. That is useful. It is not the same as per-tool control over a standalone MCP server. No per-tool allow list for MCP tools was verified on the Learn data policy page.

Every capability you want to close is its own line item. The full list is in Part 3, Step 4.

2.5 Generative features are governed somewhere else

A connector policy alone does not settle generative AI. Public data grounding through Bing, cross-region data movement for generative features, and the tenant setting for publishing copilots with AI features are separate controls, in separate places. Data movement that happens while cross-region movement is enabled cannot be reversed later. Decide it before the first agent, not after the first incident.

2.6 Maker credentials are the quiet privilege escalation

A Copilot Studio tool can run two ways:

• End user credentials: the agent acts as the person chatting. They only reach what that person can reach.
• Maker-provided credentials: the agent acts as its author, for every user who chats with it.

With maker credentials, every end user indirectly gets the maker’s access. They can retrieve information and take actions the maker could, whether or not they could do it themselves. Microsoft documents the risk in those terms.

The control that blocks this, Block the use of maker-provided credentials for authentication, is not enabled by default. An admin has to turn it on, per environment or per managed environment group. Until then, the choice is the maker’s.

2.7 There is no approval gate unless you build one

Publishing to the organisational catalogue has a review flow: a maker submits, an admin reviews capabilities, data sources, and actions in Requested agents, then publishes or rejects. Use it.

Outside that flow, there is no default per-agent approval for a user sharing an Agent Builder agent, and no default approval for sharing inside a Copilot Studio environment. The gate is the tenant and environment settings you set. If they are loose, sharing is loose.

Bulk cleanup is also thin. Agent Management Rules currently cover two scenarios: installing Microsoft agents, and reassigning ownerless Agent Builder agents to the former owner’s manager. Everything else, blocking, removing, reassigning arbitrary agents, is manual work in the agent registry.

2.8 Audit shows you less than you think

• Microsoft Purview Audit logs Copilot interaction events with metadata: date, time, user and resource IDs, and a transcript thread ID.
• The audit log does not contain the full text of the interaction. It holds the thread ID, not the transcript.
• Copilot Studio conversation transcripts live in a different place, the Dataverse Conversation Transcript table, with a 30 day default retention.
• Some channels are excluded from logging, per Microsoft’s audit documentation.
• A maker-facing security scan and warning exist before publishing. DLP is the control that actually makes the Publish button unavailable on a violation. Do not present the warning to your board as a gate.

If you are regulated, 30 days of transcript in Dataverse is not an audit strategy. It is a countdown.

2.9 Third-party agents sit outside your Microsoft agreements

Microsoft warns admins directly: data processed by non-Microsoft agent services is not subject to Microsoft’s agreements. Allowing external publisher agents in the agent settings is not a technical decision. It is a procurement and privacy decision. Review publisher terms before you allow that agent type.

2.10 Harness-specific shortfalls: the GitHub Copilot harness

Everything above applies. Then the harness adds its own list.

1. There is no fixed path to audit in advance. The standard harness follows maker-defined topics and rules. The GitHub harness reasons, plans, replans, and retries with alternative paths when a step fails. Control moves off the flow chart and onto instructions, knowledge scoping, tool allowances, and evaluations. If your review process is reading the topic tree, you have no review process for a harness agent.

2. The blast radius is chained, not single. One agent can chain connectors, MCP, and connected agents, reach organisational data through Work IQ (email, calendar, files, Teams messages, people data), and then create a new Word, Excel, PowerPoint, or PDF artefact from what it found. A read-only knowledge leak stops being read-only when the runtime can transform and route what it read.

3. Skills are portable, code-like artefacts. Skills are a native feature of the harness. They can be built once, reused across agents, and shared as Markdown files or packages. Treat a skill file like code: source control it, review it, and know who wrote it. An unreviewed skill passed around as a helpful file is an unreviewed instruction set running inside your agents.

4. Memory persists. The harness supports persistent per-user memory across interactions. That is the feature. It is also a retention question. No admin control for GitHub harness memory retention was verified on the Learn pages checked for this kit. Do not promise your privacy team a toggle you have not seen in your own tenant.

5. The meter runs on credits. GitHub harness agents bill in Copilot Credits, usage based, even in a tenant where users hold Microsoft 365 Copilot licences. Cost governance is a budgeting exercise per environment and per agent in PPAC, not a licence assignment exercise. No per-agent credit limit setting was verified on Learn for this kit. Check your own PPAC before you quote one.

6. Harness choice is sticky. Microsoft lists an upgrade path to the GitHub Copilot harness in preview. Plan any harness change as a rebuild and a full re-test until Microsoft documents a clean migration in general availability. Pick the harness first, on purpose. Changing your mind later is a project.

7. The sandbox is asserted, not specified. Learn says each harness task runs in a secure sandbox governed by Copilot Studio. The pages checked do not specify network egress, file system, or MCP process limits for that sandbox. Do not write sandbox boundaries into a risk assessment that Microsoft has not published. Compensate with the environment, DLP, and credential controls in Part 3, which are specified.

Part 3: The manual remedial configuration

Work these steps in order. Later steps assume earlier ones are done. Nothing here is exotic. That is the point. The controls exist. They are just not on.

Step 1: Tighten the tenant agent settings

Microsoft 365 admin center. Go to Agents, then Settings.

1. Set User access to Specific users or groups. Start with a pilot group. All users is a decision, not a default you drift into.
2. Set Sharing for Agent Builder agents to Specific users or groups, or to No users if org-wide sharing is not approved yet. Remember: this only affects new shares, and only Agent Builder.
3. Set Allowed agent types. Allow Microsoft-built and organisation-built agents as your programme needs. Disable external publisher agents until someone has reviewed the publisher’s data terms.
4. Export the agent inventory from All agents (the agent registry). Review it. Block or remove ownerless agents and anything shared that nobody can explain. Reassign what is worth keeping.
5. Set agent feedback sharing to the narrowest option your programme can live with.

Done when: a new hire cannot build and org-share an agent on their first day without being in a group you named.

Step 2: Fix the data before the agents read it

Do this before you scale any agent, and before any GitHub harness agent touches a knowledge source.

1. Run a Microsoft Purview data risk assessment (DSPM for AI) and a SharePoint Advanced Management content management assessment. You are hunting overshared sites, ownerless sites, inactive sites, Everyone except external users use, broken inheritance, and company-wide sharing links.
2. Apply interim protection while you fix it. Turn on Restricted Content Discovery in SharePoint Advanced Management to exclude sensitive sites from Copilot discovery. Configure Purview DLP for Microsoft 365 Copilot to keep labelled sensitive content out of Copilot grounding and responses. Use DLP for Copilot prompts to restrict responses when prompts contain specified sensitive information.
3. Run site access reviews. Site owners review down to file level, remove excessive access, rescope links to named people and groups, and correct broken inheritance. Confirm ownership for every site that a review cannot assign.
4. Label as you go. Apply site sensitivity labels. Configure auto-labelling and default labels in Purview so new content lands labelled, not unlabelled.
5. Set secure defaults for new sites. Use Restricted Access Control by default for business-critical sites at provisioning. Restrict Anyone links and company-wide sharing groups at tenant level.
6. Only remove the interim Restricted Content Discovery and DLP protections for a site after its permissions are actually fixed.

Done when: you can name the sites your agents are allowed to ground on, and you have evidence the rest are not overshared, instead of a feeling that they are probably fine.

Step 3: Ring-fence the environments

Power Platform admin center.

1. Do not build production agents in the default environment. Create dedicated Managed Environments for development, test, and production, outside the default environment.
2. Put those environments in an Environment Group. Publish group rules so the settings that matter are set at group level and environment admins cannot loosen them locally. Rules to use include sharing limits, generative AI settings, maker welcome content, and solution checker.
3. Turn on Environment routing, so makers who open Copilot Studio or Power Apps land in their own personal developer environment, not in a shared one.
4. Restrict who can create Production, Trial, and Developer environments, in tenant settings. Environment sprawl is governance sprawl.
5. Lock down access to each production environment with a security group, and use Dataverse security roles deliberately. Know who can create and edit agents, and who can read conversation transcripts. A System Administrator can read and update all agents and all transcripts in an environment. Treat that role accordingly.
6. Set the maker welcome message. State your privacy, data, and publishing rules where the maker will actually see them.

Done when: the GitHub harness has its own environments, and nothing governed shares an environment with anything casual.

Step 4: Write the data policy, line by line

Power Platform admin center. Go to Security, then Data and privacy, then Data policy. Create a tenant-wide baseline policy that adds all environments, so new environments inherit it, then add tighter environment policies for production and for any GitHub harness environment.

For each connector below: search it on the Assign connectors page, then either Block it, or Configure connector and set Connector endpoints to allow and deny specific endpoints. Then verify in Copilot Studio: a blocked connector shows as disabled to the maker, and the Publish button becomes unavailable on a violation. On the Channels page, the error banner’s Details download lists the violations.

Rules that keep this step honest:

• Non-business is not a block. If a connector matters, move it to Blocked, or isolate it so it cannot share data with other connectors.
• Knowledge sources are three separate decisions. Decide documents, public websites, and SharePoint and OneDrive one at a time.
• Channels are separate decisions. Closing Direct Line does not close Teams.

Done when: you can open the policy and read, line by line, exactly what an agent in that environment cannot do, and you have watched a test agent fail to publish against it.

Step 5: Force end-user credentials

1. In PPAC, enable Block the use of maker-provided credentials for authentication for every production environment and for every GitHub harness environment or group. It is off by default. Turning it on is the fix.
2. In Copilot Studio, set each production agent’s authentication to Authenticate with Microsoft, or Authenticate manually where a different identity provider is required. Never No authentication in production. Step 4 already blocks the unauthenticated path at policy level. This sets it per agent as well.
3. Inventory existing agents that run on maker credentials. For each one, either convert it to end-user credentials, or replace the maker account with a deliberately scoped service account that you own, document, and review like any other service identity. Do not leave a person’s mailbox and file access standing behind a shared agent by accident.

Done when: no agent in production acts with more access than the person chatting with it, unless that exception is written down and owned.

Step 6: Contain the GitHub Copilot harness specifically

Apply Steps 3 to 5 first. Then add this layer before the first GitHub harness agent leaves development.

1. Dedicate the environments. GitHub harness agents get their own development, test, and production Managed Environments, in their own Environment Group, with the tightest sharing limits and generative AI settings you publish. No harness agents in the default environment. No exceptions for a quick test with real data.
2. Publish the sharing limits in the group rules. Set who can be granted Editor and Viewer, prefer individuals only with no security groups, and cap the number of viewers per agent while an agent is pre-catalogue. Remember the limits are share-time only and only cover authenticated agents. They are a brake, not a wall.
3. Apply the Step 4 data policy to the harness environments at the tightest setting. Block HTTP or endpoint-filter it. Block the Skills connector if skills are not approved. Block the Microsoft Copilot Studio connector if event triggers and autonomous evaluations are not approved. Endpoint-filter knowledge sources to named sites only.
4. Scope Work IQ like it matters. A harness agent connected to email, calendar, files, Teams messages, and people data inherits the oversharing you did or did not fix in Step 2. Only connect the organisational data the use case needs. If the use case does not need mail, it does not get mail.
5. Govern skills as code. Skills live under source control. Every skill gets a named owner and a review before it is reused across agents. Exports as Markdown or packages are releases, not file shares. If a skill has not been reviewed, it does not run in production.
6. Gate memory by use case, not by hope. Until you have verified a retention control in your own tenant, approve persistent memory only for use cases where per-user retained context is the point of the agent, and tell your privacy team exactly that. Write the limitation into the approval.
7. Budget the credits before you build. GitHub harness work bills in Copilot Credits, usage based. Set the funding route (pay-as-you-go or prepaid credits) per environment in PPAC, watch consumption in the PPAC Copilot area, and review it on a schedule. A harness agent that retries and replans is, by design, an agent that can spend more than your estimate. That belongs in the business case.
8. Give every harness agent an identity. Starting in July 2026, Copilot Studio automatically creates a Microsoft Entra Agent ID for every new agent. Onboard harness agents to Microsoft Agent 365 so each one has an Entra identity you can scope with Conditional Access and access governance, and observe in one place. Govern the agent as an identity, not just as a file in an environment.
9. Require evaluations before promotion. There is no topic tree to sign off. Promotion from test to production requires recorded evaluations against the knowledge and tools the agent will actually use, including cases designed to make it reach outside its scope. If it reaches, it does not ship.

Done when: a harness agent can only run in a governed environment, only reach approved data with the user’s own credentials, only spend against a budget someone owns, and only ship after an evaluation someone signed.

Step 7: Gate publishing, not just building

1. Route Copilot Studio agents that belong in Microsoft 365 or Teams through the catalogue flow. Maker submits. Admin opens the agent in Requested agents in the Microsoft 365 admin center. Admin reviews capabilities, data sources, and custom actions on the Details tab. Then Publish or Reject. No third option, no silent approvals.
2. Assign availability deliberately. Available to and Deployed to are separate decisions. Scope both to specific users or groups for anything new. Entire organisation is an earned state.
3. Keep a register. Export the agent inventory on a schedule. Every agent in production has a named owner, a harness, an environment, a data policy, and a review date. Ownerless agents get reassigned or removed. Use the Agent Management Rule for ownerless Agent Builder agents, and do the rest manually, because there is no bulk rule for the rest yet.
4. Re-review on change. A new connector, a new knowledge source, a new skill, or a harness change is a new approval, not an edit.

Step 8: Monitor like the defaults are against you

1. Watch Microsoft Purview Audit for Copilot interaction events, and route alerts into Microsoft Sentinel if you run it. Know the limit: audit gives metadata and a thread ID, not the conversation.
2. Fix transcript retention before you need a transcript. Extend Dataverse retention for conversation transcripts beyond the 30 day default for governed agents, or export transcripts through Azure Synapse Link for Dataverse to a data lake you control.
3. Watch capacity and credits in PPAC. Set a review rhythm for Copilot Credits consumption on harness environments, and for Copilot Studio capacity on standard environments. Surprises here arrive as a bill or as throttling, and both arrive late.
4. Re-run the Step 2 assessments on a schedule. Oversharing grows back. Sites are created, links are shared, inheritance breaks again. An agent estate on top of an unmeasured data estate drifts out of governance on its own.
5. Log your own exceptions. Every blocked connector you unblock, every maker credential you allow, every unauthenticated agent you permit, gets an owner, a reason, and an expiry date.

Part 4: The gate: when to allow what

Allow Agent Builder when

• The agent is personal or team-scoped, read-only, and grounded on data the users already work with.
• The user is in your pilot or approved group, sharing is scoped, and the data estate behind them passed Step 2.

Allow Copilot Studio, standard harness, when

• The process is predictable enough to draw. Topics and rules cover the paths.
• The agent runs in a Managed Environment, under a data policy you wrote, with end-user credentials, and it passed the catalogue gate.

Allow the GitHub Copilot harness when all of these are true

• The work is genuinely multi-step and reasoning-heavy, and the standard harness strains against it. File-heavy work, cross-tool orchestration, and goals that need replanning are the honest cases.
• The agent has dedicated governed environments, a tight data policy, scoped Work IQ access, reviewed skills, an owned credit budget, an Entra identity, and recorded evaluations.
• The business owner can say, out loud, what the agent is allowed to do when its first plan fails. Because it will try something else. That is the product working as designed.

Say no, or not yet, when

• The use case needs the harness because nobody wants to define the process. An undefined process plus a replanning runtime is not innovation. It is delegation to a system you cannot audit in advance.
• The knowledge source is overshared and the owner will not fix it.
• The agent needs maker credentials to work and nobody will own the exception.
• The agent needs to be anonymous, external-facing, and grounded on internal data at the same time. Pick two.
• Nobody owns the credit bill. Usage-based billing with no owner is a surprise with a date on it.

Not everything should be an agent. Not every agent should be a harness agent. Saying no to the wrong rung is how the right rungs stay credible.

Part 5: Pre-flight checklist

Copy this. Work it top to bottom before any agent programme launch, and again before the first GitHub harness agent ships.

Tenant

• Agent Builder user access set to specific users or groups
• Agent Builder sharing set to specific users or groups, or off
• External publisher agent types disabled until terms are reviewed
• Agent inventory exported, ownerless and unexplained agents blocked or removed

Data

• Purview data risk assessment and SharePoint content assessment run
• Restricted Content Discovery and Purview DLP for Copilot in place as interim protection
• Site access reviews done for every grounding source, excessive access removed
• Sensitivity labels applied, auto-labelling and defaults configured
• Secure defaults set for new sites, Anyone links and company-wide groups restricted

Environments

• No production agents in the default environment
• Managed Environments for dev, test, and production, in an Environment Group
• Group rules published for sharing limits and generative AI settings
• Environment routing on, environment creation restricted
• Production access by security group, Dataverse roles reviewed, maker welcome message set

Data policy

• Tenant baseline policy covers all environments, including future ones
• Unauthenticated chat blocked
• HTTP blocked or endpoint-filtered
• All three knowledge source connectors decided one by one
• Skills, event triggers, and telemetry connectors decided
• Every channel decided, Direct Line included
• Every unapproved connector blocked, not left in Non-business
• Policy verified by watching a test agent fail to publish against it

Identity and credentials

• Maker-provided credentials blocked in production and harness environments
• Every production agent set to Authenticate with Microsoft or Authenticate manually
• Remaining maker-credential exceptions converted to owned service accounts, documented

GitHub harness, if used

• Dedicated harness environments, separate from standard agents
• Work IQ access scoped to what the use case needs, nothing more
• Skills under source control, owned, and reviewed
• Memory approved per use case, privacy limitation written into the approval
• Copilot Credits funding set and consumption reviewed on a schedule
• Agent onboarded to Agent 365 with an Entra Agent ID
• Evaluations recorded, including out-of-scope attempts, before promotion

Publishing and monitoring

• Catalogue review flow in use, availability and deployment scoped to groups
• Agent register current: owner, harness, environment, policy, review date
• Purview Audit and Sentinel monitoring in place, limits understood
• Transcript retention extended or export running, past the 30 day default
• Exceptions logged with owner, reason, and expiry

Appendix A: GitHub proper, the other harness problem

Skip this appendix if your organisation does not use GitHub Copilot, the GitHub MCP server, or a GitHub connector. If it does, the naming collision will confuse your governance work, because three different things share the GitHub name in an agent estate:

1. The GitHub Copilot harness in Copilot Studio. Covered above. Your data does not go to GitHub.
2. GitHub Copilot, the coding service, including its cloud coding agent and agent mode in editors. Runs on GitHub and on developer workstations.
3. The GitHub MCP server and GitHub connectors, which hand an agent a GitHub token and a set of tools.

The pattern is the same as the rest of this kit: capable by default, governed only where an admin did the work.

A.1 What can go wrong, in GitHub’s own words

• The cloud agent firewall is not a full boundary. GitHub documents that the Copilot cloud agent firewall only applies to processes started by the agent through its Bash tool. It does not apply directly to MCP server processes, or to processes started in setup steps. GitHub also states that sophisticated attacks may bypass it, and that it should not be considered a comprehensive security solution.
• Content exclusions do not cover agent surfaces. GitHub documents that content exclusion is not supported in Edit and Agent modes of Copilot Chat in VS Code and other editors, and that the cloud agent does not account for content exclusions at all. A file you excluded from suggestions can still be seen and changed by an agent.
• Enterprise policies do not bind everyone in your repos. GitHub warns repeatedly that Copilot policies govern the users you assign licences to. A user with a personal Copilot Pro or Pro Plus plan working in your enterprise repositories is not restricted by your policies. Blocking is a separate enterprise control, not the normal policy toggle.
• MCP enforcement is name-based. GitHub documents that MCP allowlist enforcement works on server name and ID matching, which can be bypassed by editing configuration files, and that strict enforcement preventing installation of non-registry servers is not yet available. GitHub’s own recommendation for the highest security is to disable MCP servers in Copilot until strict enforcement is available.
• The token is the boundary for the GitHub MCP server. With no toolset restriction, the server defaults to toolsets that include creating and updating files, pushing files, deleting files, creating branches and repositories, merging pull requests, and writing issues. Pair that with a classic personal access token with repo scope, and the agent holds read and write access to every repository that token can reach. Lockdown mode on the MCP server is a content filter for public repository content. GitHub’s server documentation is clear that it is not an authorisation boundary and does not change what the credential can read or write.

A.2 Manual configuration for GitHub

Block or pilot the cloud agent, at enterprise level

Enterprise owners can block Copilot cloud agent for all users, including personal-plan users, from the enterprise page: AI controls, then Agents, then Copilot cloud agent, then Block. The same path exists for Copilot code review. If you pilot instead, enable at enterprise level or let organisations decide, and let each organisation scope which repositories it applies to. Do the same for MCP: the MCP servers in Copilot policy is off by default for Business and Enterprise seats. Either leave it off, or set a registry URL and restrict access to registry servers only, knowing the name-matching limitation above.

Lock the firewall at organisation level

Organisation Settings, then Copilot, then Internet access. Enable the firewall at organisation level rather than letting repositories decide. Enable the recommended allowlist. Disable repository custom rules so repository admins cannot add their own. Configure cloud agent and code review sections separately. Keep the secrets in the dedicated copilot environment minimal. Only secrets placed in that environment reach the cloud agent, so nothing production belongs there.

Harden the MCP server, per developer machine

• Fine-grained personal access token, named repositories only, least permissions, short expiry. Never a classic token with repo scope for an agent.
• Read-only mode on: the read-only flag on the local server, or the read-only environment variable in Docker.
• Name the toolsets explicitly. Do not accept the defaults.
• Lockdown mode on if the agent ever reads public repositories.
• Token in an environment variable or secret manager, never committed in a configuration file in the repo.
• Never enable automatic tool approval in the editor. A 2025 vulnerability (CVE-2025-53773) showed a prompt injection could write the auto-approve setting into workspace settings and put the agent into unattended shell execution. Assume any content the agent reads is an attack surface, because it is.

Set GitHub Actions and branch rules as the last line

• Set workflow permissions to read-only at enterprise, organisation, and repository level (Settings, then Actions, then General, then Workflow permissions). Leave the option for Actions to create and approve pull requests off. Note the trap: anyone with write access can raise permissions inside a workflow file, so workflow files themselves need owner review.
• Do not send write tokens or secrets to workflows from fork pull requests, and require approval for fork pull request workflows.
• Protect the default branch with a ruleset: require a pull request, require approvals, require review from Code Owners, dismiss stale approvals, require status checks. CODEOWNERS on its own only requests review. The ruleset is what requires it. Cover workflow files, agent setup files, and infrastructure paths in CODEOWNERS at a minimum.
• Turn on secret scanning and push protection (Settings, then Code security and analysis, per repository, and at organisation level for all repositories). Secrets kept out of the repo are the only secrets an agent cannot read. Note that private repository coverage needs the paid security products.

Close the Copilot Studio side of GitHub

In your Step 4 data policy, block the GitHub connector, and any connector you have not approved, rather than leaving it in Non-business. If a GitHub-connected agent is approved, it gets a dedicated Managed Environment, its own credentials per environment, and Step 5 applies: end-user credentials, not the maker’s.

Know where Conditional Access does not reach

Entra Conditional Access governs GitHub access where GitHub is federated to Entra, for example Enterprise Managed Users with OIDC, or a SAML-configured organisation. A GitHub organisation using personal accounts and personal access tokens is not covered by an Entra policy, no matter how good the policy is. Say so in your risk register instead of implying coverage you do not have.

Sources

Microsoft Learn, checked October 2026:

• Agents overview and Harnesses overview, Microsoft Copilot Studio: learn.microsoft.com/en-us/microsoft-copilot-studio/agents-overview and /harnesses-overview
• Data loss prevention for Copilot Studio agents: learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention
• Sharing controls and limits for Copilot Studio agents: learn.microsoft.com/en-us/microsoft-copilot-studio/admin-sharing-controls-limits
• Security and governance guidance, Copilot Studio: learn.microsoft.com/en-us/microsoft-copilot-studio/security-and-governance and /guidance/sec-gov-phase2
• Agent settings and Manage shared agents, Microsoft 365 admin center: learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-settings and /manage-shared-agents
• Configure a secure and governed foundation for Microsoft 365 Copilot: learn.microsoft.com/en-us/copilot/microsoft-365/configure-secure-governed-data-foundation-microsoft-365-copilot
• Block the use of maker-provided credentials (release plan, 2025 wave 1): learn.microsoft.com/en-us/power-platform/release-plan/2025wave1/microsoft-copilot-studio/block-use-maker-provided-credentials-authentication
• Environment groups and Managed Governance, Power Platform: learn.microsoft.com/en-us/power-platform/admin/environment-groups and /managed-governance
• Tenant settings, Power Platform admin center: learn.microsoft.com/en-us/power-platform/admin/tenant-settings
• What’s New, Copilot Studio (harness preview June 2026, Agent 365 onboarding and Entra Agent ID entries): learn.microsoft.com/en-us/microsoft-copilot-studio/whats-new

GitHub Docs, checked October 2026:

• Customize the firewall for Copilot cloud agent, including its stated limitations: docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-the-firewall
• Content exclusion, including agent mode and cloud agent limitations: docs.github.com/en/copilot/how-tos/configure-content-exclusion/exclude-content-from-copilot
• Block agentic features at enterprise level: docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/block-agentic-features
• MCP allowlist enforcement reference: docs.github.com, Copilot reference, MCP allowlist enforcement
• GitHub MCP Server README (toolsets, read-only mode, lockdown mode): github.com/github/github-mcp-server

Flagged, not asserted

These points came up in research and are deliberately not stated as fact anywhere above. Verify each in your own tenant or on an official page before you rely on it.

• The exact general availability date of the GitHub Copilot harness. Learn documents a production-ready preview from June 2026 and usage billing guidance from August 2026. Secondary reporting of an August 2026 GA date was not confirmed on a Learn page.
• Whether the GitHub harness can or cannot be changed after an agent is built, beyond the preview upgrade path Learn lists. Plan as a rebuild either way.
• Sandbox network, file system, and process limits for the GitHub harness. Learn says secure sandbox and stops there.
• An admin retention toggle for GitHub harness memory. None was found on the Learn pages checked.
• A per-agent Copilot Credit spending limit in PPAC, and whether build and test activity burns credits. Learn confirms credit billing for harness agents. Limit settings appeared only in Microsoft community and CAT guidance.
• Per-tool governance for standalone MCP servers in Copilot Studio, and Advanced Connector Policies coverage for specific connectors. Learn documents connector-level blocking and the MCP side effect of blocking a connector.
• Whether transcripts and specific channels are logged in your tenant. Audit documentation notes channel exclusions. Test with your own agents.