Yes, the ChatGPT SharePoint and OneDrive connector can expose sensitive data, but not because of a flaw in OpenAI's product. The connector uses delegated Microsoft Graph permissions to read exactly what the signed-in user can already open. Connect it under an account that has quietly accumulated broad access, such as an IT administrator who has been made site collection admin across dozens of sites, and it can surface salary files, HR records, and other sensitive content that permission sprawl left reachable. The exposure is the collision of two things you already own: who signed in, and how overshared your SharePoint is.

This guide is written for the CIOs, IT directors, and security leads who are being asked to scale AI agents on top of a tenant where someone has already connected ChatGPT to OneDrive or SharePoint. It explains how the connector works, how it gets into a tenant, why an admin login can pull data nobody intended to share, how the risk differs from Microsoft 365 Copilot, and the exact test-and-remediate sequence to run before you let any AI reach your data.

Key takeaways

• The connector honors permissions, it does not bypass them. ChatGPT retrieves only content the connected Microsoft account can already access through delegated Graph permissions, so exposure reflects your existing access model, not a product vulnerability.
• Accumulated access is the amplifier. Admin roles don't grant automatic access to site content, but IT and admin accounts tend to collect site collection admin rights, group ownerships, and memberships over years. Connected under one of those identities, the connector inherits all of it.
• Admin consent is the usual entry point. Since August 2025, Microsoft's default consent policy stops ordinary users from granting third-party apps access to files and sites, so in most tenants the connector arrived because an administrator approved it, often on behalf of the whole organization.
• Data leaves your tenant boundary. Microsoft's own whitepaper warns that third-party AI connectors egress SharePoint content to external systems and may not enforce Purview sensitivity-label encryption or timely permission changes the way Microsoft 365 Copilot does.
• Prompt injection is a separate risk. A poisoned shared document can instruct the connector to hunt for and leak data, and permission cleanup alone does not stop that.
• Test with decoys, not real data. Start with discovery reports that never leave your tenant, then red-team the connector against planted canary files so the test itself doesn't egress the content you're trying to protect.

The fix is not to ban the tool reflexively. It is to control who can connect it, remediate the oversharing underneath it, and verify the result with a controlled test.

How does the ChatGPT SharePoint and OneDrive connector actually work?

The connector, now delivered as the real-time SharePoint app rather than the retired synced-index version, lets a signed-in user search, read, and summarize SharePoint and work OneDrive files from inside ChatGPT. OpenAI is explicit that it retrieves only content the connected Microsoft account can already access, and that SharePoint, OneDrive, and Microsoft 365 group membership continue to apply. The mechanism is Microsoft's own: delegated Graph permissions, where an app cannot reach anything the signed-in user could not reach.

The permissions it requests

When the app is connected, consent is granted for a specific set of Microsoft Graph scopes. Each one is read-oriented by default, but together they grant broad reach across the user's accessible content.

• Files.Read.All: Read every file the signed-in user can access in OneDrive and SharePoint.
• Sites.Read.All: Read content across all site collections the user can access.
• offline_access: Issue a refresh token so the app keeps access even when the user is offline.
• User.Read: Identify the user and read their basic profile.

When write actions are enabled by a workspace admin, the heavier Files.ReadWrite.All and Sites.ReadWrite.All scopes come into play. An approved Microsoft permission does not automatically enable an action, but the read scopes alone are enough to surface sensitive content. Microsoft now classifies all four file and site scopes as high-impact, which shapes who can approve them.

How the connector gets into your tenant

On consent, Microsoft Entra provisions a service principal for the OpenAI application (app ID e0476654-c1d5-430b-ab80-70cbd947616a) inside your tenant. Who can trigger that depends on your consent policy.

In August 2025, Microsoft enabled a Microsoft-managed default consent policy that requires administrator approval for third-party apps requesting Files.Read.All, Files.ReadWrite.All, Sites.Read.All, or Sites.ReadWrite.All. If your tenant runs that default, a standard user who tries to connect ChatGPT hits an “Admin approval required” prompt. Two paths still open the door:

• A custom consent policy that lets users approve these scopes themselves. Tenants that built their own policy before the change are not covered by Microsoft's default.
• An administrator approving the app. When an admin consents and ticks “Consent on behalf of your organization,” the grant applies tenant-wide, and every user can then connect ChatGPT to their files with no further prompt, ticket, or review.

The second path is the one most often missed. A single well-intentioned approval, made to unblock one executive, can quietly open the connector to the entire organization.

Managed workspaces versus personal accounts

OpenAI's own workspace controls, such as SharePoint site allow and deny lists and sensitivity-label exclusions, apply only to managed ChatGPT Business and Enterprise workspaces. An employee connecting from a personal ChatGPT account sits outside those settings entirely. Microsoft Entra is the control that covers every account type, which is why consent and assignment rules, not OpenAI settings, have to be your primary gate.

Why could an administrator pull salaries and personal data through ChatGPT?

Because delegated access gives the connector read parity with whoever signed in, and administrator accounts tend to hold far more access than their role implies. Strictly speaking, the Global Administrator and SharePoint Administrator roles do not grant automatic access to site content or other users' OneDrives. Admins can grant themselves that access at any time, and over the years most do: they are added as site collection admin during migrations and troubleshooting, they own the groups behind dozens of Teams, and they sit inside the same “Everyone except external users” grants as everyone else. There is no privilege escalation and no breach of the permission model. The connector simply exercises, at the speed of a prompt, access that identity already held.

Two conditions turn that into a real finding. First, the accumulated access on the account: an IT or admin identity that has collected site collection admin rights, group ownerships, and memberships over time. Second, the accumulated oversharing underneath it, which is present in almost every tenant: sites shared with “Everyone except external users,” leftover “Anyone” links, and legacy project sites whose membership was never revisited. Before an AI connector, that content sat in practical obscurity. Nobody was going to browse hundreds of abandoned sites to find a salary spreadsheet. The connector removes the obscurity and makes it findable with one question.

So when a leader connects ChatGPT under their admin account and asks for salary or personal data, a result is the expected outcome of accumulated admin access plus oversharing, not evidence of a weak OpenAI-to-Microsoft control. Diagnosing which of the two factors dominates is exactly what a controlled test is for.

One more detail matters for containment. Global Administrators can sign in to an enterprise app even when it is set to require user assignment, so the accounts with the broadest reach are the ones an assignment rule won't stop. Keep privileged accounts out of AI connectors by policy, and have admins use separate, unprivileged identities for everyday work.

The connector did not create your exposure; it turned years of quiet permission sprawl into a search box.

This is the pattern BabyBots sees across Microsoft-stack enterprises: the AI tool is blamed for a data-governance debt that predates it. BabyBots runs fixed-fee connector-exposure assessments that separate the two causes and hand you a prioritized remediation plan, so you can tell your board whether the risk is the tool, the tenant, or both. You can read how we approach the underlying cleanup in our SharePoint oversharing readiness runbook.

The risk permissions don't cover: prompt injection

Oversharing is about what the connector is allowed to read. Prompt injection is about what it can be tricked into doing. At Black Hat 2025, researchers demonstrated an attack dubbed AgentFlayer, in which a document carrying hidden instructions was shared into a victim's drive. When ChatGPT read it through the connector, the instructions directed it to search the victim's connected files for secrets and leak them to an attacker-controlled destination, with no click required from the victim. OpenAI shipped mitigations, but the class of attack remains.

Permission cleanup narrows what a successful injection can reach, but it doesn't prevent one. Limit who outside the organization can share files into users' OneDrives and sites, keep write-enabled connector actions off unless there is a defined need, and include a planted injection document in your exposure test.

How is this different from Microsoft 365 Copilot?

Both Copilot and the ChatGPT connector respect existing permissions, and both make oversharing visible. The difference is where your data goes and which controls travel with it. Microsoft's security whitepaper on competitor AI connectors is blunt that third-party connectors create new pathways for Microsoft 365 data to leave the tenant and be processed in external systems.

Microsoft 365 Copilot vs. third-party AI connectors: data handling compared

Microsoft 365 Copilot

• Where data is processed: Inside your Microsoft 365 tenant boundary, grounded through Microsoft Graph.
• Sensitivity-label encryption: Checks usage rights, so a user without the EXTRACT right cannot have encrypted content surfaced, even when permissions would otherwise allow it.
• Permission changes: Evaluated against live Graph permissions at request time.
• Governance: Purview DLP for Copilot, audit, and Restricted Content Discovery apply natively.

Third-party AI connector (for example, the ChatGPT SharePoint app)

• Where data is processed: Content egresses to the vendor's environment outside your tenant boundary.
• Sensitivity-label encryption: Microsoft warns enforcement of label encryption semantics can be inconsistent across connectors, so encrypted content may not be honored the same way.
• Permission changes: Synced patterns can leave a window where revoked access is not yet reflected in the vendor's copy; real-time patterns still egress content on each call.
• Governance: Controls split between Microsoft Entra, your SharePoint posture, and OpenAI's own workspace settings, which you must configure separately.

The practical takeaway: Copilot keeps the blast radius inside controls you administer, while a third-party connector adds an external processing path you govern only partially. Neither removes the need to fix oversharing first.

How do you test for data exposure before you scale AI agents?

Do not test with live user accounts or real admin credentials, and do not make real sensitive data the test payload: every query run through the connector sends whatever it retrieves to OpenAI. The reliable method starts with discovery that never leaves your tenant, then runs a controlled red-team against decoy content. Get written sign-off on scope from security and legal before you begin.

1. Run in-tenant discovery first. Use Data Access Governance reports, “Everyone except external users” insights, and Purview DSPM oversharing assessments to map what is reachable without sending anything outside Microsoft 365.
2. Plant canary documents. Create clearly fake but realistic files, such as a decoy salary spreadsheet or mock board minutes, each tagged with a unique marker string, and place them in the overshared locations discovery surfaced.
3. Build test identities that mirror real people. Create accounts at three tiers, a standard end user, a department-level user, and a privileged or admin-equivalent account, and give each the same group memberships and site access as a real role profile. A fresh account with no memberships surfaces almost nothing and gives false comfort. Make the privileged account time-bound and delete it when the test ends.
4. Connect the app and run adversarial prompts. Authorize the connector under each identity, ask for salary information, personal identifiers, board materials, and pricing, and record which canaries each identity can surface.
5. Test the label boundary. Apply encrypting sensitivity labels to some canary files and confirm whether the connector honors the encryption or returns the content anyway.
6. Probe the timing gap. Revoke access to a test site, then immediately re-query to see whether previously reachable content still appears, exposing any stale-permission window.
7. Test for prompt injection. Include a decoy document containing hidden instructions and confirm the connector does not act on them.
8. Escalate on a finding. If the test surfaces real exposure, stop expansion and bring a remediation plan before going further, rather than discovering it in production.

This sequence answers the only question that matters before scaling agents: if we let AI reach our data today, what walks out, and under whose identity.

How do you lock the ChatGPT connector down?

Containment is a layered job across Microsoft Entra, SharePoint, and the OpenAI workspace. Run these in order.

1. Confirm your user consent policy. Under Enterprise apps, Consent and permissions, User consent settings, check which policy your tenant uses. Microsoft's managed default already blocks users from granting file and site scopes; if you run a custom policy that allows them, tighten it or choose “do not allow user consent.”
2. Turn on the admin consent workflow. Pair the restriction with a request-and-review queue so legitimate needs route to named reviewers instead of dead-ending into shadow IT. Assign at least two reviewers, set a request expiry, and make “never consent on behalf of the organization for AI connectors by default” an explicit reviewer rule.
3. Require user assignment on the OpenAI app. In the enterprise app's Properties, set “Assignment required” to Yes and assign only approved users or groups. User consent is then disabled for that app and unassigned users cannot obtain tokens. Remember that Global Administrators bypass this setting. To block the app outright, set “Enabled for users to sign in” to No.
4. Find and revoke existing grants. Tightening the setting does not remove consents already given. Inventory the delegated permission grants on the OpenAI service principal, both tenant-wide and per-user, remove any that were not approved or delete the service principal, and revoke affected users' sign-in sessions to invalidate outstanding refresh tokens.
5. Monitor for new connections. Alert on consent events in the Entra audit log, filter sign-in logs on the OpenAI app ID, and use Microsoft Defender for Cloud Apps app governance to flag OAuth apps that hold high-privilege Graph scopes.
6. Use OpenAI's workspace controls as a complement. In a managed ChatGPT workspace, an admin can set SharePoint site-collection allow and deny lists and exclude files carrying specific Purview sensitivity labels. These filter on OpenAI's side, apply at site-collection level rather than individual files, and do nothing for personal accounts, so they supplement Entra rather than replace it.
7. Remediate the oversharing underneath. Close the real exposure with the Microsoft tooling you already own: Data Access Governance reports, SharePoint Advanced Management, Restricted Content Discovery, and disabling “Everyone except external users” at tenant level. Our Copilot oversharing remediation playbook walks the full assess-contain-remediate-sustain sequence.
8. Make sensitivity-label encryption the durable control. Labels that encrypt content and gate the EXTRACT right protect data wherever it travels, but because connector enforcement can be inconsistent, validate the behavior in your test rather than assuming it.

Frequently asked questions

Does the ChatGPT connector respect SharePoint permissions?

Yes. The app retrieves only content the connected Microsoft account can already access. The exposure comes from how much standing access that account has, not from the connector overriding permissions.

Can a regular employee connect ChatGPT to our SharePoint without IT approval?

Not on Microsoft's current default consent policy, which has required admin approval for third-party file and site access since August 2025. They can if your tenant uses a custom policy that allows those scopes, or if an administrator has already granted consent on behalf of the whole organization. Check both your consent settings and the app's existing grants.

Why did an administrator see salary and personal data when they tested it?

Because the connector inherited the access that admin account had accumulated, such as site collection admin rights and group ownerships, and surfaced content that oversharing had already made reachable. Admin roles don't grant that access automatically; it builds up over time.

Is Microsoft 365 Copilot safer than the ChatGPT connector?

For data residency, generally yes, because Copilot processes content inside your Microsoft 365 tenant boundary and applies Purview controls natively, while third-party connectors egress content to an external system. Both still surface overshared content, so neither removes the need to remediate SharePoint access first.

If we already have ChatGPT connected, what should we do first?

Inventory existing grants to the OpenAI application, set it to require user assignment, and run in-tenant discovery reports. Then run a canary-based exposure test before expanding any AI access, and pause to remediate if it surfaces anything.

Does blocking the connector solve the underlying problem?

No. Blocking one tool leaves the oversharing in place, and the next AI connector or Copilot rollout will surface the same content. The durable fix is to remediate permissions and apply sensitivity labels so your data is governed regardless of which AI reaches it.

Where this is heading

Every enterprise is about to connect more AI, not less, to the content in Microsoft 365. Each new connector, agent, and copilot is another identity-shaped doorway into the same data, and the ones that cause incidents are rarely the tools themselves, they are the overshared sites nobody cleaned up. The organizations that scale AI safely are the ones that treat connector governance and data-readiness as the prerequisite, controlling consent, remediating access, and labeling sensitive content once so every future AI inherits the guardrail. The connector question is really a governance question, and answering it now is what lets you say yes to the next agent with confidence.

Secure your tenant before the next connector goes live

If someone has already pointed an AI tool at your SharePoint, you need to know what it can reach before you scale further. Book a BabyBots connector-exposure assessment: we map your exposure with in-tenant discovery, run a controlled canary test across privilege levels, separate tool risk from tenant risk, and hand you a prioritized remediation plan in a single working engagement. Start at babybots.ai.

Sources

• OpenAI Help Center - SharePoint app and setup in ChatGPT
• OpenAI Help Center - Managing SharePoint site access and sensitivity-label exclusions
• Microsoft - Security risks for customers using other AI tools to egress Microsoft 365 data (whitepaper)
• Microsoft Learn - Configure how users consent to applications (Microsoft Entra ID)
• Microsoft Learn - Manage app consent policies (Microsoft-managed default policy)
• Microsoft Learn - Configure the admin consent workflow (Microsoft Entra ID)
• Microsoft Learn - Restrict a Microsoft Entra app to a set of users (assignment required)
• Microsoft Learn - About the SharePoint Administrator role (site access)
• Cyberdom - The hidden risks inside ChatGPT in Entra ID (app ID and delegated permissions)
• Nudge Security - The hidden dangers of ChatGPT's integrations with Google Drive and OneDrive (AgentFlayer, Black Hat 2025)
• Microsoft Learn - Configure a secure and governed foundation for Microsoft Copilot