Catalogue › Security and Privacy › connector-review

Connector review

Reviews the connectors, actions, tools, MCP servers and APIs an agent or automation uses, covering user versus maker authentication, least privilege, data policies, data leaving the tenant and confirmation for write actions, and classifies each finding as blocking or advisory with a fix. Use when an agent gains an action or tool, when a flow uses a new connector, or when a maker shares a connection.

Department: Security and Privacy
Lifecycle: Deliver, Assure, Launch, Improve
Maturity: builder, scaler, ai-enterprise
Risk tiers: 1, 2, 3, 4
Platforms: m365-agents, copilot-studio, power-platform, ai-foundry, entra, azure
Editions: starter, scale, enterprise
Reviewers: security-privacy
Status: draft
Copilot Cowork: Security and Privacy plugin for Copilot Cowork, or this skill on its own: Download SKILL.md
Licence: CC BY 4.0, by Simon Foote

Purpose

An agent that only answers can expose information; an agent that acts can change it, send it elsewhere and do so under someone else's identity. This reviewer skill examines every connector, action, tool, MCP server and API an agent or automation uses, and classifies each finding as blocking or advisory with a specific fix. Reviews go wrong when they check that a connector is "allowed" by policy and stop there, without asking whose credentials it runs on, what it can write, and where the data ends up.

When to use

An agent or automation at risk tier 2 or above reaches its security-privacy gate with actions or tools.
A maker adds a new connector, custom connector, MCP server, plug-in or API call to an existing solution.
A connection is to be shared with other makers or embedded in an agent used by others.
Data policy changes are proposed to allow a connector that was blocked.
An incident suggests an agent acted beyond what users expected.

When not to use

Reviewing what knowledge content the solution can reach and reveal - use security-privacy:data-exposure-review.
Lawful basis, transparency and retention for personal data moving through the actions - use security-privacy:privacy-assessment.
Designing the actions and their confirmation rules in the first place - use m365-agents:agent-use-case-design.
Setting organisation-wide connector policy and environment strategy - use platform-governance:connector-policy.
Detailed authentication and connector engineering for Copilot Studio builds - use copilot-studio:studio-authentication and copilot-studio:studio-connectors.

Questions to ask first

What does each connector, action or tool do - read, create, update, delete, send - and in which system?
Whose identity does it run under: the signed-in user, the maker, a shared account or a service identity?
Does it need all the permissions it has been granted, or could a narrower scope work?
Does any data leave the organisation's tenant or reach a third-party service, and under what agreement?
Must a person confirm before a write or send action takes effect?

Required inputs

An inventory of connectors, actions, tools, MCP servers and APIs, with operations used, authentication mode and permissions.
The environment, its data policy classification and governance zone.
The agent brief or automation design with audience and risk tier.
Action test results from m365-agents:agent-testing, including confirmation and failure tests.

An action with an unknown authentication mode or unknown permissions is a blocking finding from tier 2 until it is documented. Never assume a connector runs as the user.

Decision framework

Classify every finding. From risk tier 2 a blocking finding stops release and is not traded against dates; below tier 2 findings are advisory to the owner, but anything that would be blocking sends the solution back to risk classification.

Finding	Blocking when	Advisory when	Typical fix
Authentication mode	Maker or shared credentials let users act or read beyond their own rights	Service identity with narrow, documented scope and an owner	Switch to user authentication, or a dedicated service identity with least privilege
Least privilege	Broad scopes (all mailboxes, all sites, admin roles) where narrow ones would work	Slightly wider scope than needed on low-sensitivity data	Reduce scopes, split read from write
Data policy	Connector sits outside the environment's data policy or relies on an exception with no owner	Policy allows it but grouping is untidy	Move to a correctly governed environment, document the exception
Data leaving the tenant	Organisational or personal data reaches an external service with no agreement or assessment	External service is assessed and contracted	Remove, replace, or complete supplier and privacy assessment
Write and send actions	Actions change records, send messages or move money without user confirmation	Low-impact writes to the user's own content	Add explicit confirmation, show what will change, log the action
MCP servers and custom APIs	Unvetted server or API, unknown owner, or tool descriptions that could be manipulated	Vetted, owned server with documented tools	Vet, assign owner, pin versions, restrict tools exposed
Logging and failure	No record of actions taken, or failures leave partial changes	Logging exists but is not reviewed	Enable action logging, define safe failure behaviour

Finding

Blocking when

Advisory when

Typical fix

Authentication mode

Maker or shared credentials let users act or read beyond their own rights

Service identity with narrow, documented scope and an owner

Switch to user authentication, or a dedicated service identity with least privilege

Least privilege

Broad scopes (all mailboxes, all sites, admin roles) where narrow ones would work

Slightly wider scope than needed on low-sensitivity data

Reduce scopes, split read from write

Data policy

Connector sits outside the environment's data policy or relies on an exception with no owner

Policy allows it but grouping is untidy

Move to a correctly governed environment, document the exception

Data leaving the tenant

Organisational or personal data reaches an external service with no agreement or assessment

External service is assessed and contracted

Remove, replace, or complete supplier and privacy assessment

Write and send actions

Actions change records, send messages or move money without user confirmation

Low-impact writes to the user's own content

Add explicit confirmation, show what will change, log the action

MCP servers and custom APIs

Unvetted server or API, unknown owner, or tool descriptions that could be manipulated

Vetted, owned server with documented tools

Vet, assign owner, pin versions, restrict tools exposed

Logging and failure

No record of actions taken, or failures leave partial changes

Logging exists but is not reviewed

Enable action logging, define safe failure behaviour

Each finding names the risk, the rule behind it, the fix and an owner. Disagreement escalates to the accountable executive for risk acceptance in writing.

Practitioner approach

Start with an inventory, because makers rarely have one. List every connector, action, tool, MCP server and API call, the operations actually used, and the system each touches. Separate reads from writes and sends; a solution with only reads is a different review from one that can change records or contact customers.

For each item, establish whose identity it runs under. This is the most important question in the review. A connection created with the maker's credentials and embedded in a shared agent lets every user act with the maker's rights. If the maker is an administrator, the agent is too. User authentication keeps each person within their own access; a dedicated service identity can be acceptable where its scope is narrow, documented and owned.

Then test least privilege. Compare the permissions granted with the operations used. Broad delegated or application permissions, such as access to all mailboxes or all sites, are blocking when a narrower scope would serve. Ask the maker to show why each scope is needed.

Check the data policy position. Confirm the environment, its governance zone and that each connector is permitted there without an undocumented exception. Exceptions are legitimate, but each needs an owner, a reason and a review date.

Follow the data out. For each external service, ask what data is sent, whether personal data is included, where it is processed and stored, and whether a supplier assessment and agreement exist. Personal data leaving the tenant also goes to security-privacy:privacy-assessment.

Give MCP servers, plug-ins and custom APIs particular care. Find out who runs the server, how it is authenticated, which tools it exposes and whether tool descriptions or returned content could steer the agent into unintended actions. Expose only the tools the agent needs, and pin versions so behaviour does not change silently.

Review write and send actions with the action test evidence. Each should show the user what will happen and wait for confirmation, run under the expected identity, log what it did, and fail without leaving partial changes. Prefer a deterministic flow for multi-step changes over letting the model improvise a sequence.

Be proportionate. A tier 2 agent that reads one list with user authentication might pass with one advisory note. Record findings with risk, fix and owner, and close the review only when blocking fixes are evidenced.

Outputs

The connectors and actions section of the ai-risk-assessment: inventory, authentication mode, permissions, data policy position, external data flows, confirmation rules, findings classified as blocking or advisory with fix and owner, and the verdict.
Any written risk acceptance from the accountable executive.
Requests to the platform team for policy changes or exceptions, with rationale.

Microsoft platform considerations

Authentication options, data policies, environment routing, Managed Environments controls, connector classification and MCP support differ between routes and change often. Confirm current behaviour in the source records (ms-copilot-studio-security-governance, ms-managed-environments, ms-agents-extensibility) before relying on a control, and record what was checked.

Adoption considerations

Makers often choose maker authentication because it is easier to get working. Publish a short pattern guide showing the approved alternatives, so the secure route is also the easy one and reviews find fewer blocking issues.

Knowledge considerations

Not applicable to most connector findings, because this review concerns actions and data flows rather than grounding content. Where a connector indexes content for grounding, that content is reviewed in security-privacy:data-exposure-review.

Security and privacy considerations

This skill is the security review of connectors and actions. Personal data flows go to security-privacy:privacy-assessment; grounding exposure goes to security-privacy:data-exposure-review.

Responsible AI considerations

Actions that affect people (sending messages, updating records about individuals, approving requests) need human confirmation and an audit trail. From tier 3, responsible-ai:human-oversight reviews the oversight design.

Evaluation requirements

Blocking fixes need evidence: the changed authentication setting, the reduced permission set, a re-run of the confirmation and failure tests. Advisory findings need an owner and a date.

Value measures

Track, at portfolio level, the share of agents with actions using user or documented service identities, the number of policy exceptions with owners and review dates, and time to close blocking findings. The security and privacy lead owns these measures.

Scale notes

Starter

Keep first agents read-only or limited to standard connectors with user authentication; review any write action in a short session with the maker and owner.

Scale

Maintain an approved connector and action pattern list, require the inventory for every agent with actions, and review exceptions in the CoE cadence.

Enterprise

Federate standard-pattern reviews to business-unit reviewers, with the central team reviewing custom connectors, MCP servers, service identities and tier 3 and 4 solutions. Track exceptions across the estate.

Hand-offs

Back to m365-agents:agent-use-case-design with changes to actions, identities and confirmation rules.
To security-privacy:privacy-assessment for personal data leaving the tenant.
To m365-agents:agent-release-readiness with the verdict.
To platform-governance:connector-policy for policy and environment changes.

Reviewer gates

This skill is the security-privacy gate for connectors and actions. It applies as a blocking gate from risk tier 2 and as an advisory check below it. Blocking findings stop release and are not traded against dates; disagreement escalates to the accountable executive for written risk acceptance.

Failure modes

A maker's connection is embedded in a shared agent, giving every user the maker's access.
A connector is "allowed by policy", so nobody checks what it writes or where data goes.
An MCP server is added from an unvetted source and its tools change without notice.
Write actions run without confirmation, and a misunderstood request updates live records.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

Pass a shared agent that runs actions on maker or shared credentials beyond users' own rights.
Treat data policy permission as proof that a connector is safe.
Trade a blocking finding against a launch date.
Allow write or send actions with consequences outside the user's own content without confirmation.

Source records for this skill

Copilot Studio security and governance

Source id: ms-copilot-studio-security-governance
Publisher: Microsoft (product-documentation)
Link: https://learn.microsoft.com/en-us/microsoft-copilot-studio/security-and-governance
Authoritative for: Security and governance controls for Copilot Studio agents, including data policies, environment routing and maker controls.
Volatility: high; review every 30d; last reviewed 2026-10-29
What you may do: Read and cite. Summarise in your own words; do not reproduce the text.

Managed Environments overview

Source id: ms-managed-environments
Publisher: Microsoft (product-documentation)
Link: https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-overview
Authoritative for: Governance features available to Power Platform Managed Environments.
Volatility: high; review every 45d; last reviewed 2026-10-29
What you may do: Read and cite. Summarise in your own words; do not reproduce the text.

Implement a zoned governance strategy (Copilot Studio guidance)

Source id: ms-copilot-studio-zoned-governance
Publisher: Microsoft (product-documentation)
Link: https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/sec-gov-phase2
Authoritative for: Segmenting agent-building into governance zones by purpose and risk, and the controls available at each level.
Volatility: medium; review every 90d; last reviewed 2026-10-29
What you may do: Read and cite. Summarise in your own words; do not reproduce the text.

Ways to extend Microsoft 365 Copilot

Source id: ms-agents-extensibility
Publisher: Microsoft (product-documentation)
Link: https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/overview
Authoritative for: The extensibility options for Copilot, including agents, connectors, skills and tools, and how to choose between them.
Volatility: high; review every 30d; last reviewed 2026-10-29
What you may do: Read and cite. Summarise in your own words; do not reproduce the text.

Data, privacy and security for Microsoft Copilot

Source id: ms-copilot-privacy
Publisher: Microsoft (trust-and-compliance)
Link: https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-privacy
Authoritative for: How Copilot uses organisational data, permission-trimmed grounding, stored interaction data, data residency and extensibility controls.
Volatility: high; review every 30d; last reviewed 2026-10-29
What you may do: Read and cite. Summarise in your own words; do not reproduce the text.

Credit

This skill was created by Simon Foote as part of CopilotForge, licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Credit the author when you share or adapt it.