By Greg Nowak. Last updated 2026-07-02.
ChatGPT apps are becoming part of the work surface, not just a shortcut for fetching a file or summarising a web page. OpenAI’s current app model includes search, deep research, sync, interactive app experiences, custom apps, and write actions. For a small company, that changes the question.
It is no longer enough to ask, “Can our team use ChatGPT?” The better question is more operational: which connected apps can read company data, which ones can act on it, which sources can be indexed, and who has checked the route before information starts moving?
This is where otherwise sensible rollouts get messy. Someone enables a useful connector. An employee approves OAuth access. A sync feature starts indexing documents. Only later does the company realise that the real permission boundary is spread across ChatGPT settings, the third-party app, identity groups, domain rules, and the original source system. Each layer may look reasonable on its own. Together, they still need a map.
OpenAI’s Help Center shows how broad the operating model has become. Apps can bring external context into ChatGPT conversations, support deep research across sources, sync content in advance, and, in some configurations, create or update information in connected services. It also describes different permission prompt patterns, including always asking, asking before changes, asking before important actions, or allowing actions without a prompt where available. Business workspaces have apps enabled by default. Enterprise and Edu workspaces have them disabled by default. That difference alone is enough reason for smaller companies to stop treating app access as a personal productivity choice.
Read access is only part of the risk
The obvious concern is exposure: contracts, HR notes, finance sheets, customer records, private strategy documents, or internal decisions surfacing in an assistant. That matters. But the quieter risk is action permission.
OpenAI describes write actions such as creating or updating information in connected services. Its examples of important actions include sending or editing communications, deleting content, changing sharing permissions, uploading files, moving files, and handling sensitive information. A review that only asks “can this app read?” misses a large part of the control surface.
There is also a timing issue. Sync can make answers better because content is indexed before a user asks for it. But indexed content is useful only when the source permissions, document lifecycle, and deletion rules are understood. Microsoft’s Copilot connector documentation describes a similar enterprise pattern: connector content is ingested into an index with content, metadata, and access control lists, then kept current through periodic sync. It also notes that Copilot Chat is read-only by default unless extended with action connectors or plugins.
That separation between retrieval and action is a useful discipline for ChatGPT rollouts too. Keep “find and summarise” separate from “change, send, share, delete, or update.”
| Control area | What to document | Business decision |
|---|---|---|
| App availability | Which apps are enabled, and whether access is open to everyone or limited by group. | Begin with a short approved list, then expand after review. |
| OAuth scope | What the app can access in the underlying service after a user authorises it. | Decline broad scopes unless the workflow genuinely needs them. |
| Read versus write | Which capabilities retrieve information, and which can create, edit, move, delete, send, or share. | Keep write actions disabled or approval-gated until tested. |
| Sync and indexing | Which sources are indexed, how updates are reflected, and who checks stale or deleted content. | Sync only sources with clean permissions and a clear owner. |
| Domain controls | Whether staff can connect personal or external accounts, or only approved company domains. | Restrict connected accounts to company-controlled domains where possible. |
| Approval prompts | When ChatGPT asks before reading, changing, or taking important actions. | Use stricter prompts for sensitive tools and irreversible workflows. |
| Logs and audit | Where app calls, conversations, and admin changes can be reviewed. | Assign a regular review owner, not just an incident responder. |
Custom apps still need product thinking
OpenAI’s Apps SDK matters because some companies should not rely only on ad hoc user connections. A custom internal app can be the cleaner option when a workflow needs approved tools, predictable data boundaries, and a controlled user experience.
But custom does not automatically mean safe. It simply moves the design responsibility closer to the company.
Before building or approving a custom ChatGPT app, define its job in plain operational language. Can it retrieve support policy snippets? Draft a CRM note? Create a task? Update a project status? Search internal documents? Each answer points to a different permission model.
The stronger internal designs usually keep retrieval, drafting, and execution as separate steps. The assistant may find the policy. It may draft the note. But anything that leaves the assistant or changes a business system should have an explicit approval point unless there is a very clear reason not to.
For a smaller company, this does not need to become a heavy governance programme. A two-page register is often enough: app name, owner, data sources, OAuth scopes, read actions, write actions, approval rule, user groups, sync status, logging location, and review date. The rule is simple. If nobody can explain what an app can touch, it should not touch company data.
Compare ChatGPT with the tools staff already use
This work should not sit in an OpenAI-only silo. Microsoft and Google are moving in the same direction: AI assistants grounded in business systems and embedded into daily work.
Microsoft’s connector model shows how external sources become available to Copilot and Microsoft Search through indexed content, metadata, ACLs, and continuous sync. Google’s Workspace with Gemini guidance places Gemini across Gmail, Docs, Meet, Drive, Chat, NotebookLM, AppSheet, and admin-facing controls such as access management, conversation history settings, Workspace service access, and AI classification for sensitive Drive files.
The point is not that every vendor has identical controls. They do not. The point is that companies need one internal standard across all of them. If Microsoft 365 is governed by groups and sensitivity labels, Google Drive has its own sharing model, and ChatGPT apps add OAuth and action permissions on top, the company needs a shared vocabulary for risk. Otherwise the same document can be carefully protected in one tool and casually exposed through another.
The enterprise usage research on M365 Copilot Chat reinforces the urgency. The paper describes Copilot as an everyday assistant for knowledge work, with writing prominent alongside information retrieval, analysis, decision making, strategising, evaluation, and diagnosis. Employees are not keeping AI in a neat “search box” category. They are bringing it into the work itself. Permissions therefore need to cover what the assistant can know, and also what it may help decide, draft, share, and change.
A rollout audit that fits a smaller company
Start with inventory, not policy language. List every enabled ChatGPT app, every relevant Microsoft 365 or Google Workspace AI integration, and every source likely to contain business-sensitive material. Then classify each connection by capability: search, sync, deep research, read-only retrieval, write action, and custom tool. This quickly shows which integrations deserve deeper review.
Next, review identity and OAuth. Which accounts can connect? Are personal accounts possible? Are domain restrictions available and configured? Are user groups too broad? Do the underlying SaaS permissions still match current roles? ChatGPT permission prompts do not create new access by themselves. Available data and actions still depend on the connected app, the authorisation granted, and workspace controls. That makes OAuth review a governance task, not setup housekeeping.
Then test the paths that would hurt. Can a connected app surface sensitive documents, stale files, deleted-but-indexed knowledge, draft communications, external sharing links, or content containing hidden instructions? OpenAI notes that suspicious or hidden instructions in app content can affect approval or blocking decisions. Companies still need to test their own likely workflows, because business risk depends on context. A harmless draft in one team may be a regulated communication in another.
Finally, turn the audit into an admin runbook. It should say who can enable apps, who reviews new write actions, when sync is allowed, how approvals are configured, where logs are checked, and how an app is disabled when a role, vendor, or workflow changes. That is the practical layer that keeps AI governance from becoming a document nobody uses.
Greg can help scope this kind of rollout audit for OpenAI, Microsoft 365, or Google Workspace teams: inventory connected apps, separate read-only from write-capable actions, review OAuth and domain restrictions, document approval rules, test prompt-injection and sensitive-data paths, and leave the company with a lightweight operating model administrators can maintain.
Related on GrN.dk
- OpenAI File Search Turns Messy Internal Docs Into a Real Retrieval-Governance Project
- Web Search and Citation Controls Turn AI Research Assistants Into a Source-Governance Project
- Long-running AI automations need queues before they meet real ops
Need help with this kind of work?
Plan a connector permissions audit Get in touch with Greg.