Guides › Connecting enterprise data to AI

How to Safely Connect Enterprise Data to AI Assistants

Connecting SharePoint, Google Drive, a CRM or a database to an AI assistant takes an administrator about ten minutes. Finding out afterward what the assistant can now reach takes months, and by then it has already answered the questions. This is a procedure for doing it in the other order: eight steps from inventory to rollout that apply whether the assistant is ChatGPT, Claude, Microsoft 365 Copilot, Gemini or something your team built, with notes on what each vendor's connectors do with permissions, training and retention, and a short list of what to write down so the decision survives an audit.

What a connector actually does

A connector gives the assistant a way to read a source on a user's behalf and put what it finds into the model's context. Three shapes are in use. Native connectors, the kind ChatGPT, Claude and Copilot ship for SharePoint, Drive, Gmail, Slack and the rest, authenticate as the user or as an admin-granted application and query the source live or from a synced index. MCP servers, custom GPTs and similar tool interfaces expose a source or an action to the model through a small program that someone wrote and that the platform does not verify. Internal retrieval systems, whether classic RAG, agentic retrieval or enterprise search, index the source into a store the organization runs and serve it to whichever model the organization chose. The AI knowledge base security guide covers the third shape in depth; this page treats all three as what they are, which is a retrieval path from your data to a model.

Two details decide most of the risk. The first is identity: whether the connector runs as the individual user, in which case it inherits that user's permissions including every over-permission, or as an application identity with its own grant, in which case everyone who can use the assistant inherits the application's reach. The second is whether the source is read on demand or synced. OpenAI's synced sources maintain a separate index of administrator-selected content; Anthropic's Google Workspace connectors retrieve on request and store what they retrieved with the chat; Copilot works inside the Microsoft 365 service boundary against the tenant's own index. A synced index is a second copy of the data with its own retention and its own permission snapshot, and it has to be governed as one.

The procedure

The eight steps below are in the order that catches problems before users do. Steps one through four are preparation and need no new tooling. Steps five through eight are the controls, and they are where most deployments are thin. Each step is summarized here and expanded afterward.

1. Inventory what the assistant can already reach

Before adding anything, list what is connected today. In ChatGPT Enterprise and Business, check the admin connector settings; OpenAI's documentation notes that new Enterprise workspaces start with a selected set of apps enabled and that Business workspaces enable apps by default. In Claude, Owners see connector enablement in organization settings. In Microsoft 365, the answer is every SharePoint site, OneDrive, mailbox and Teams channel the user's identity can open, which is the point of the next three steps. Include personal accounts in the inventory: anything an employee has connected to a consumer plan under their own login is outside every control below and is a policy question, covered on the is it safe to put company data in AI page.

2. Classify each source by what is in it, not where it sits

Sort candidate sources by the most sensitive thing they contain. A product wiki and a customer support desk might both be “documentation” to the business and are very different to a regulator. The useful categories are the ones that carry obligations: personal data under GDPR or state privacy law, health information under HIPAA, financial records under GLBA, controlled unclassified information under NIST SP 800-171 and CMMC, export-controlled technical data, and secrets such as credentials and keys. A source that holds any of the last four categories needs steps six and seven before it is connected to a third-party model, and some should never be.

3. Audit permissions on each source before connecting it

This is the step most teams skip, and it is the one that determines the outcome. For each source, sample real user identities across roles and enumerate what each one can open. In SharePoint and OneDrive, SharePoint Advanced Management reports oversharing by site; sensitivity labels and Restricted Content Discovery narrow what search and Copilot can surface while permissions are fixed. For drives and wikis, pull the sharing settings and look for company-wide and anyone-with-the-link defaults. For applications reached by API, compare what the API returns for a role against what the screen shows that role, because the two often differ. Write down what you found. The number of over-permissioned items is the assistant's day-one reach, and it is usually larger than anyone expected, which is why the data silos guide treats silo friction as a control that AI removes.

4. Decide scope: one source, one group, least privilege

Connect one source to one pilot group first, with the narrowest grant the platform allows. Prefer delegated (per-user) identity over application identity wherever the vendor supports it, so the assistant can never see more than the person asking. Where only an application grant is available, scope it to specific sites, folders or record types rather than the whole tenant. Decline the “connect everything” default even though it is the fastest path to a demo, because every source added later goes through steps three and five anyway, and a narrow first connection makes step eight meaningful.

5. Enforce entitlements at query time, not index time

If the connector or your retrieval system builds an index, find out when permissions are checked. A check at index time is a snapshot, and snapshots drift: people change roles, leave, or lose access to a project within weeks, and the index keeps returning what they could see on the day it was built. The control that holds checks the live entitlement on every query, before the content reaches the model. Native vendor connectors that run as the user generally do this; synced indexes and custom pipelines often don't. The RAG permissions guide covers the three places a check can sit and why post-filtering after retrieval also leaks.

6. Substitute identifiers before anything leaves your boundary

For any source in a regulated category connected to a third-party model, replace real identifiers, meaning names, account and record numbers, addresses and similar keys, with consistent stand-ins before the content goes out as context, and restore them only for a reader who holds the entitlement. The model still reasons over the record. The provider never holds the identifiers. This is different from redaction, which removes the information and degrades the answer; the third-party platforms guide explains the mechanism. Enterprise terms govern what the provider does after data arrives. Substitution governs what arrives.

7. Turn on retrieval telemetry before the first user

Record every retrieval: which document or record, for which user, in response to which question, with the identifiers replaced by opaque IDs so the log holds no sensitive content. This is the only way to answer “what has the assistant shown people” after the fact, and it is the evidence an auditor will ask for. The provider's own admin logs cover prompts and app activity; OpenAI's Compliance Platform, for eligible workspaces, exposes app-activity and app-authentication records. They don't show you which of your documents were retrieved. Your own telemetry does. Open-source retrieval telemetry is enough to start.

8. Run the leakage test, set a threshold, then roll out

With one source connected to one group and telemetry running, ask the assistant a set of questions it should refuse or answer only partially for each pilot user: questions that touch documents outside their role, questions that join sources, questions that name specific people. Count how often it returns content the user was never cleared to see. The leakage self-test describes a reproducible version. Set a threshold, fix the permissions or the scope until the number is under it, and only then widen the group or add the next source. Repeat the test whenever a source is added, because each addition changes what joins are possible.

Platform notes: what each vendor's connectors do

The table summarizes what the three most common enterprise assistants state about their own connectors as of October 2026. Terms change; confirm against the current documentation and your contract before relying on any row. Gemini for Google Workspace publishes comparable statements and follows the same pattern.

What to write down

A connection decision that can't be reconstructed later is a liability, whatever its merits. For each connected source, keep a short record: the classification from step two, the oversharing findings and what was fixed from step three, the identity model and scope from step four, where the entitlement check sits from step five, whether substitution is in place and for which fields from step six, where the telemetry lands from step seven, and the leakage number and threshold from step eight with the date it last passed. Map each item to whichever framework you report against; the framework crosswalk covers MITRE ATLAS, OWASP, NIST AI RMF, ISO/IEC 42001 and the EU AI Act, and the posture assessment page turns the record into a coverage map.

Two adjacent routes have their own pages. Uploading files to ChatGPT Projects, custom GPTs, Claude Projects, Copilot Studio or Gemini rather than connecting a source is covered on the platform knowledge features page, including what each keeps and who can reach it. Building your own retrieval system instead of using a vendor connector is covered by the build procedure.

Where Hardshell sits

Hardshell runs steps five through eight as a product. It connects to the systems where data already lives without migrating them, inherits their permissions and checks entitlements at query time, substitutes stand-ins for real identifiers before content reaches a model provider, records every retrieval under opaque IDs, and measures leakage before rollout with findings mapped to MITRE ATLAS technique IDs. It works with ChatGPT, Claude and Copilot as a connector and with internal retrieval systems as a layer, and deploys as a cloud service, in a private cloud or as an offline bundle. The AI data risk assessment takes three minutes and shows which of the eight steps a deployment is missing.

Frequently asked questions

Is it safe to connect SharePoint to ChatGPT or Claude?

It is as safe as the SharePoint permissions are accurate, because both vendors state that the connector runs under the user's existing permissions. In most tenants those permissions grant far more than intended, so the honest answer is: after an oversharing audit and with telemetry on, for sources that don't hold regulated identifiers, yes; for sources that do, only with substitution in place or with an internal model.

Should we use the vendor's connector or build our own retrieval?

Vendor connectors are faster and run as the user, which is the right identity model. They give you less control over what is indexed, where the entitlement check sits, and what is logged. An internal retrieval system gives you all three and makes you responsible for all three. Either way, steps three through eight apply. The choice mostly decides who does the work.

Does an enterprise plan change the answer?

It improves what the provider does after data arrives: no training by default, a defined retention window, admin controls and audit records. It does not change what your connector sends, what your permissions allow, or what an employee pastes into a personal account. Treat it as necessary and pair it with the controls above.

How long does this take?

Steps one, two and four are a few days. Step three is the long one and depends on the tenant; a mid-size organization with a decade of SharePoint typically finds weeks of permission remediation, which is why the scope in step four should be narrow enough to start before the audit is finished everywhere. Steps five through eight take days with the right tooling and months without it.

What about agents and MCP servers?

Same procedure, wider surface. An agent decides for itself what to fetch, a tool result is a retrieval channel with a different name, and an MCP server is code the platform didn't verify. The AI connector and MCP security page covers the failure modes specific to them.