AI Connector Inventories Should Come Before Copilot Agents Spread

Tools & Technical Tutorials

31 August 2026 | By Ashley Marshall

The risk is not that Copilot agents ignore permissions. The risk is that your permissions and connectors were never clean enough for AI-speed discovery.

The connector list is now the control surface

Most UK leadership teams still treat AI connectors as a deployment detail. That is backwards. Once Microsoft 365 Copilot agents, custom actions, ChatGPT connectors or internal agent tools can reach operational data, the connector list becomes a live control surface. It tells you which systems the assistant can query, which actions it might trigger, which policies apply, and which owner will be accountable when an answer includes the wrong material. The practical question is no longer simply whether a user has a licence. It is whether the organisation can explain what data and actions sit behind that user at the moment the AI is asked to help.

Microsofts own Copilot extensibility documentation is clear that agents may use prompts, conversation history and Microsoft 365 data to generate a response or complete a command. It also says synced Copilot connectors ingest external data into Microsoft Graph while other agent integrations keep external data in the app. That distinction matters because it changes where your inventory evidence must live. A connector that syncs content needs review of source scope, Graph indexing, sensitivity labels and access groups. A custom action needs review of API permissions, authentication, rate limits, approval points and logging. Treating both as just another app install leaves too much hidden from risk, finance and operations.

Start with a connector inventory rather than a policy document. For each connector, record the system, business owner, technical owner, data classes, user groups, action permissions, approval requirements, logging destination, retention period and last review date. Put the inventory in the same governance rhythm as SaaS access reviews. If the AI layer can find or act on something, the business needs a named owner for that route.

Permissions still work, but inherited access is not enough

The reassuring line about enterprise copilots is that they respect existing permissions. That is true, but it is not sufficient governance. Existing permissions in large Microsoft 365 tenants often include old SharePoint sites, broad Teams groups, inherited library access, dormant owners and documents that were shared widely during a project and never cleaned up. An AI assistant does not usually create that exposure. It makes the exposure searchable, summarised and easy to reuse at speed.

Microsofts guidance on managing Copilot agents describes two simple roles for shared agents: Can edit owners, who can edit and manage the agent, and Can chat users, who can interact with it. It also notes that admins may apply policies restricting sharing options, and that governance changes apply when implemented rather than automatically revoking existing agent access. That is the kind of detail that belongs in an operating checklist. If sharing restrictions change, somebody has to revisit existing agents and confirm whether their access still matches policy.

What this means in practice is that UK teams need two inventories side by side. The first is the connector inventory: what the AI surface can reach. The second is the permission exposure inventory: which sites, mailboxes, records and APIs are broadly accessible underneath that surface. For Microsoft 365, this means checking SharePoint permissions, sensitivity labels, external sharing, stale groups, overshared sites and agent ownership. For API actions, it means checking whether a user can trigger a write action indirectly through an agent even if the interface feels conversational. The counterargument is that this sounds like slowing adoption. In reality, it prevents the familiar pattern where a successful pilot becomes politically impossible to pause after sensitive content starts appearing in answers.

NCSC guidance points to sandboxes, observability and shutdown

The NCSCs August 2026 blog on managing the cyber risk of agentic AI gives UK organisations a useful benchmark for connector governance. It advises teams to use safeguards, sandboxing and active oversight, and asks designers to consider how systems behave when they do not function as expected. The strongest point is proportionate autonomy. A low-risk assistant that drafts summaries does not need the same control design as an agent that can update records, send messages, change configuration or place orders.

That is where a connector inventory becomes more than a spreadsheet. Each connector should have an autonomy rating. Read-only search across policy documents is one level. Retrieval from customer records is another. Write access to CRM, finance, HR, ticketing, deployment or admin systems is materially different again. For every connector above read-only, record the approval point, rollback route and emergency disable process. The NCSC explicitly highlights logging, audit and monitoring of agentic AI activity as part of security operations, easy attribution of AI activity, and the ability to pull the plug. These are operational controls, not abstract principles.

For a practical UK business, the first version can be simple. Tag each connector as observe, recommend, draft, execute with approval, or execute autonomously. Require human approval for external messages, payments, customer record changes, contract changes, admin changes and anything affecting regulated decisions. Feed logs into the same place your security team already reviews authentication, SaaS and endpoint events. The misconception is that sandboxing is only for engineering teams. In an AI connector context, a sandbox can also mean a test tenant, a copied dataset, a read-only service account, a fake payment rail or a CRM staging environment where the agent can prove behaviour before touching live work.

Data protection evidence has to sit at connector level

The ICOs AI guidance page is aimed at public, private and third sector organisations, and its AI and data protection risk toolkit is designed to help reduce risks to individuals rights and freedoms caused by an organisations own AI systems. That is directly relevant to connector-enabled assistants, because the privacy risk often comes from what the assistant can reach rather than from the model alone. A generic AI acceptable use policy will not tell you whether a sales agent can retrieve special category data, whether customer support notes contain health information, or whether a finance workflow exposes payroll data through a broad group.

Build the data protection evidence into the inventory. For each connector, identify whether personal data is involved, whether special category data might appear, the lawful basis relied on, the retention rule, the data processor or controller position, and whether a DPIA or legitimate interests assessment exists. Record whether prompts, retrieved snippets, tool calls and outputs are logged, where they are stored, and who can inspect them. If the connector sends queries to an external service, record what leaves the tenant and what stays inside the app.

What this means in practice is that the AI governance meeting should not ask, do we allow Copilot agents? It should ask which connectors are approved for which groups and which evidence is missing. A connector to a policy library may be approved quickly. A connector to HR case notes, complaints, legal files or pricing systems needs a higher bar. The Data Use and Access Act has also prompted the ICO to review relevant guidance, which is a reminder to keep connector evidence live. A one-off approval made before the underlying guidance or product behaviour changed is not enough.

A minimum viable inventory can be built in a week

Do not wait for a perfect governance platform. A useful connector inventory can start as a controlled spreadsheet, a lightweight service catalogue or a ticketing workflow. The important thing is that it captures enough evidence to support approval, review and incident response. Begin with your obvious AI surfaces: Microsoft 365 Copilot agents, Copilot Studio agents, ChatGPT business connectors, Slack or Teams bots, CRM assistants, support desk AI, data warehouse assistants and internal automation agents. Then add the less visible routes: API keys held by automation scripts, browser agents with saved sessions, shared service accounts and developer prototypes that have escaped into day-to-day work.

The minimum fields are straightforward: connector name, platform, source system, data types, action permissions, owner, user group, authentication method, environment, logging location, approval point, disable route, last review date and risk rating. Add a free text field for known limitations, such as cannot distinguish archived files, relies on inherited SharePoint permissions, uses a shared mailbox, or can trigger outbound email. That final field is often where the real risk appears.

Run the first pass with IT, security, operations and one person close to the business process. Ask them to identify what the connector can read, what it can write, what it can expose, and what would happen if it followed a malicious or mistaken instruction. Use recent support tickets, HR cases, sales quotes or customer records as test prompts in a safe environment. The output should not be a long theoretical risk register. It should be a ranked list of connectors to approve, restrict, sandbox, redesign or retire. The value is speed: in one week, leaders can move from vague concern to a concrete picture of the AI access layer.

The board question is evidence, not enthusiasm

The business case for connectors is strong. They make assistants useful because they connect models to the actual places work happens: SharePoint, Teams, CRM, service desks, finance systems, knowledge bases and line-of-business APIs. The wrong lesson would be to block connectors until the risk disappears. The better lesson is to approve connectors with evidence. Leaders should expect the same maturity they already ask of identity, cloud, data and supplier management.

For each high-impact connector, ask five board-level questions. Who owns it? What data can it reach? What actions can it trigger? How do we monitor and attribute its activity? How do we switch it off without breaking the wider workflow? If those answers are missing, the connector is not ready for broad rollout. If the answers are clear, adoption can move faster because security, data protection and operational accountability have a shared record to work from.

The common misconception is that AI governance must be a heavyweight central committee. For most UK mid-market firms, the first phase should be a small approval loop with strong evidence: business owner, technical owner, risk reviewer and data protection input where personal data is involved. Refresh the inventory quarterly, and after major vendor changes, model changes, connector updates or permission restructures. This turns AI governance from a blocker into a maintenance habit. It also gives finance and operations something useful: a map of which AI connections are creating value, which ones are duplicative, and which ones carry risk without enough benefit.

Frequently Asked Questions

What is an AI connector inventory?

It is a live record of every AI connector, agent action or tool integration, showing what system it reaches, what data it can access, what actions it can trigger, who owns it and how it is monitored or disabled.

Do Copilot agents bypass Microsoft 365 permissions?

They are designed to respect existing permissions, but that does not remove risk. If SharePoint, Teams or mailbox permissions are already too broad, an AI assistant can make that exposure easier to find and reuse.

Which connectors should be reviewed first?

Start with connectors that reach customer records, HR files, finance systems, legal documents, admin tools, support tickets, outbound messaging or any system where an agent can write data or trigger actions.

Who should own the connector inventory?

IT or security can maintain the record, but each connector needs a business owner as well as a technical owner. Data protection input is needed where personal data or regulated decisions are involved.

How detailed does the first version need to be?

Enough to answer what the connector can read, what it can write, who can use it, where logs go, what approval point exists and how it can be switched off. A controlled spreadsheet is acceptable for the first pass.

How often should UK businesses review AI connectors?

Review high-risk connectors at least quarterly and after major permission changes, vendor changes, model updates, connector updates or incidents. Lower-risk read-only connectors can follow the normal SaaS access review rhythm.

Is this only a Microsoft 365 Copilot issue?

No. The same inventory pattern applies to ChatGPT business connectors, Copilot Studio agents, CRM assistants, helpdesk AI, data warehouse copilots, browser agents and internal automation tools.

What is the biggest mistake to avoid?

Do not approve an agent because the interface looks harmless. Review the underlying connector, data scope, action permissions and logging before broad access is granted.