A connector is an entitlement surface, not just a data pipe
OpenAI’s current connectors guide is explicit about what these tools do: they let models connect to and control external services, whether through OpenAI-maintained connectors or remote MCP servers. The common executive story is that this gives the model a richer enterprise search layer. The less obvious reality is that each connector creates an entitlement surface. The moment you connect Gmail, Drive, SharePoint, Teams, or Dropbox, you are no longer just improving retrieval. You are deciding which outside system the model may query, which tool definitions it may import, and which connected service now sits inside the workflow.
Scopes decide what the model can actually reach
The same OpenAI guide says the available tools in each connector depend on the OAuth scopes granted to the token. That is a useful technical detail and a major governance signal. Google Drive tools depend on `drive.readonly`. Outlook Email depends on `Mail.Read`. SharePoint search can require `Sites.Read.All` and `Files.Read.All`. Teams search needs `Chat.Read` and `ChannelMessage.Read.All`. Those scope names are the real boundary, not the cheerful promise of “company-wide search.” If leadership cannot point to a connector-by-connector map of approved scopes, exposed tools, and permitted data classes, then the organization has connected systems faster than it has defined access policy.
Approval defaults are there because data sharing is the risk
OpenAI defaults MCP and connector calls to approval because data may be shared with a connector or remote MCP server before the request completes. The connectors guide says approvals help maintain control and visibility over what data is being sent, and OpenAI’s safety guidance adds a blunt instruction: keep tool approvals on. That matters because connector risk is not only destructive writes. Private data leakage can happen on reads too. A model may send more information to an MCP than the user expected, or use a broad search tool to retrieve material from a system that was connected for convenience rather than genuinely approved for the workflow. Approval policy is the review layer that stops “search everything” from quietly becoming “share too much.”
Third-party retention and contingency planning still apply
OpenAI’s data-controls guide says `/v1/responses` data is stored for at least 30 days by default when `store=true`, and it separately reminds teams that data sent to MCP servers is subject to those third parties’ own retention policies. NIST pushes the same issue from the governance side. The AI RMF Core says roles and responsibilities should be documented, personnel and partners should receive AI risk-management training, and oversight roles should be differentiated. The Govern playbook says policies should address third-party software, data, and supply-chain issues, while the Manage playbook calls for post-deployment monitoring plans that include appeal and override, incident response, recovery, and change management. Connector rollouts sit directly in that lane: if a third-party connector becomes unavailable, over-scoped, or harder to audit than expected, someone still owns the contingency path.
Executive move: publish a connector entitlement map before the rollout
Before approving a broader AI search rollout, require one page that lists every connected system, the OAuth scopes granted, the tools exposed, the data classes reachable through each tool, the workflows allowed to call them, the approval policy, the logging path, the third-party retention stance, and the owner who can revoke access. Then ask one field question: when the assistant returns a sensitive result from the wrong system, who traces how it got there and disables the path first? If the answer is vague, the issue is not search quality. The issue is that the organization still lacks a connector entitlement map, and without that map, “company-wide search” is just a cleaner label for ungoverned access expansion.
Key takeaways
- Treat every connector as an entitlement surface with its own scopes, tool list, and approved data classes.
- Keep connector approvals explicit because read access can still create private-data leakage and policy violations.
- Publish a connector entitlement map before expanding enterprise AI search across more systems.
Related surfaces
- Enterprise delivery model — See how LockedIn Labs frames governed implementation boundaries before enterprise-wide rollout.
- Trust Center — Inspect the security, retention, and review posture expected around production AI systems.
- About LockedIn Labs — Review the implementation-first firm stance behind this operating-model view.
- Source-authority briefing — Connect connector reach to the source hierarchy the model is actually allowed to trust.
- Trusted-runtime briefing — Tie connector approvals to the runtime boundary that still owns tracing, policy, and recovery.
- Workload-identities briefing — Extend the argument into which non-human identity is allowed to reach which connected systems.
- Contact LockedIn Labs — Discuss one connector rollout that already spans multiple systems without a scope inventory or approval matrix.