Before ChatGPT apps touch company data, draw a permissions map
By Greg Nowak. Updated 17 August 2026.
Connecting ChatGPT to company tools can remove a great deal of copying, searching and routine administration. It can also create a permission boundary that nobody fully understands. The OAuth screen is only one part of that boundary.
OpenAI’s current terminology includes plugins that can package skills and apps, with connector-backed capabilities that search, retrieve, sync or act on external systems. Whatever label appears in the interface, the operational question is the same: who can use the connection, what company information can it reach, and what can it change?
Answer that before rollout—not after a sensitive document appears in an unexpected answer or an assistant gains permission to update a live system.
The permission boundary is a chain, not a switch
Enabling an app or plugin does not automatically grant access to every record in the connected service. Access depends on several controls working together: workspace availability, the user’s role, approved connector actions, the authenticated account and its permissions in the source system.
That separation is useful, but it creates room for mismatched assumptions. The ChatGPT administrator may think the source system will limit access. The source-system owner may assume ChatGPT is read-only. The employee may approve a broad OAuth request because the workflow looks harmless.
A permission map gives those people one shared document to review.
| Control layer | What to record | Sensible starting position |
|---|---|---|
| Business purpose | The specific task and the people who need it | Approve one named workflow, not general access |
| Workspace availability | Which roles or pilot groups can use the plugin or app | Start with a small group |
| Source identity | User account, shared connection or service identity | Prefer named, company-managed identities |
| OAuth and source permissions | Scopes plus the records the identity can actually reach | Use least privilege and remove obsolete access first |
| Read and write actions | Search, retrieve, create, edit, send, share or delete | Begin read-only; approve write actions individually |
| Data movement | Live retrieval, synchronization, indexing and storage | Sync only sources with clean permissions and ownership |
| Approval and audit | Confirmation rules, logs, review date and removal process | Require confirmation for consequential actions |
Start with the workflow, then separate reading from acting
“Connect our CRM” is too broad to govern. “Let account managers retrieve the latest approved account summary” is specific enough to assess. It identifies the users, source, records and expected output.
Now divide the capability into three stages:
- Retrieve: find approved information the user could already access.
- Draft: prepare a proposed email, note, task or update without changing the source system.
- Execute: send, create, edit, share, move or delete something in a business system.
Retrieval is not risk-free, but execution deserves a higher bar. Keep write actions disabled until the read-only workflow has been tested. When a write action is justified, document exactly which action is permitted and require a human confirmation for irreversible or externally visible changes.
Audit the data path, not only the OAuth scopes
OAuth scopes describe what an integration may request. They do not tell you whether the connected account already has excessive access, whether a shared drive is open too broadly, or whether confidential material has been copied into a supposedly safe knowledge base.
Check the real path from source to answer. Test with users in different roles. Search for a document one role should see and another should not. Include archived, private and recently removed material. Confirm what happens when somebody changes team or leaves the company.
Also record whether information is synchronized into an index or fetched live. These are materially different operating models. Microsoft, for example, distinguishes synced connectors that index content from federated connectors that retrieve it at runtime. Its connector guidance also warns that a “visible to everyone” setting can overshare indexed content. The useful lesson is vendor-neutral: permissions, synchronization and removal behavior must be reviewed together.
Test hostile content as well as normal prompts
Connected content is not automatically trustworthy. A document, ticket or web page can contain instructions intended to influence the assistant. OpenAI’s current developer guidance recommends assuming that prompt injection and malicious inputs will reach the integration.
Your pilot should therefore include misleading instructions embedded in source content, malformed inputs and attempts to trigger an unapproved action. Validate permissions and inputs on the server side; do not rely on the model to enforce access rules. Avoid placing secrets in prompts or interface data, redact personal information from logs where practical, and keep enough audit information to investigate unexpected behavior.
Turn the pilot into a lightweight operating routine
A smaller company does not need a fifty-page AI policy. It does need an owner and a repeatable review:
- Inventory enabled plugins, apps and connectors.
- Assign a business owner and a technical owner to each one.
- Review scopes, source permissions and approved actions before launch.
- Test with a limited group using realistic sensitive-data scenarios.
- Record where logs live and who reviews them.
- Recheck access when roles, vendors, actions or data sources change.
- Disable connections that no longer have an active owner or business purpose.
Treat newly introduced actions as new capabilities, not harmless product updates. A connection approved for search should not silently become approved for editing or sending.
When a custom integration is the cleaner choice
A custom plugin or app may be appropriate when a team needs a narrow workflow, controlled authentication and predictable tools. Custom does not mean inherently safer, however. It makes your company responsible for authorization, input validation, retention, logging and the design of approval steps.
The best design is often deliberately modest: expose only the records required for the job, return only the necessary fields and keep consequential actions behind explicit confirmation.
Make the map useful to the people running the business
The finished permission map should be readable by an operations lead, not only a security specialist. If the owner cannot explain what a connection can read, what it can change and how it is removed, the connection is not ready for company data.
If you are planning a ChatGPT, Microsoft 365 or cross-platform AI rollout, Greg can help you inventory the connections, test the risky paths and leave your administrators with a permissions model they can maintain.
Related on GrN.dk
- Your AI Agent Has Shell Access. What Can It Reach?
- ChatGPT Apps with Full MCP Access: Governance Comes First
- Logistics Optimization in 2026: Fix the Flow Before You Buy More Tech
Need help with this kind of work?
Plan an AI permissions review with Greg Get in touch with Greg.