What can the assistant reach?
List every connected app, workspace, repository, folder, inbox, calendar, database, and personal-record source. Do not treat a connector name as proof of a narrow scope.
Permissions guide · Updated 2026-09-06
Approve the workflow, not broad access by default.
A connected AI assistant can turn a useful drafting or search tool into an operator across files, messages, calendars, repositories, personal records, and other systems. Approve it only after the team can explain the exact job, the smallest required access, the actions that still need human or professional review, and the path to revoke access later.
Four questions before approval
What can it do after access is granted?
Separate reading and summarizing from actions such as sending, editing, approving, merging, deploying, deleting, or changing billing and access.
Which actions still require a person?
Keep a named human approval gate for customer-facing messages, production changes, legal commitments, payments, destructive actions, access changes, and other high-consequence decisions.
How will access be reviewed and removed?
Set a permission-review date, name the owner, and document how to revoke connectors, service accounts, delegated tokens, and departed-user access.
Match each action to a control
Connector access is only half the approval. Decide what the assistant may do with that access, then put the review gate at the action that creates the real consequence. Record evidence that the gate was applied so the approval can be audited and revisited later.
Separate provider access from action approval
Treat provider authorization, workspace app access, enabled actions, and ask-before-action settings as separate controls. A user approving the provider's requested scopes does not prove that every supported write action should be available, and enabling an app does not replace a decision about when the assistant must ask before acting. Review each layer before rollout and again when the app gains a new action.
OpenAI's September 3, 2026 Enterprise and Edu release notes are a current example: the new OneNote plugin can create or update notes through supported actions. OpenAI's admin guidance separately says provider scope approval does not automatically enable new app actions. Verify the current vendor controls for the exact app and plan you are approving.
Read and summarize
Default control
Allow only the folders, inboxes, calendars, repositories, or record sources needed for the approved workflow. Exclude sensitive locations that do not change the result.
Approval evidence
Record the approved locations, excluded locations, data owner, and the date the scope was last reviewed.
Draft or edit
Default control
Keep changes in a reviewable draft, branch, or proposed-edit state. Name the person responsible for approving the final version.
Approval evidence
Keep the draft or branch history and name the reviewer who accepts, rejects, or changes the proposed work.
Send, publish, merge, or deploy
Default control
Require an explicit human approval at the final action boundary. Do not treat an earlier connector approval as permission for every future action.
Approval evidence
Capture the final approver, the exact item approved, and the outbound, merge, or deployment result.
Delete, pay, or change access
Default control
Keep these actions outside the assistant by default. Approve an exception only with narrow scope, strong logs, and a tested recovery path.
Approval evidence
Document the exception owner, limit, recovery or rollback test, and an audit trail for every completed action.
Add a separate review for sensitive personal data
Some assistants now connect to personal records, not only workplace apps. OpenAI's July 23, 2026 ChatGPT Health rollout is a current example: eligible U.S. adults can connect supported medical records and Apple Health data, then choose when that context may be used. OpenAI says connected health information and conversations that use it are not used to train its foundation models or target ads. That vendor control matters, but it does not replace your own approval for data scope, currentness, high-consequence use, and revocation.
Name the sensitive data class
Separate health records, wellness data, financial data, legal material, and employee or customer records from ordinary workspace content. A connector approved for low-risk files is not automatically approved for these categories.
Check provenance and freshness
Record where the data came from, whether it can lag the source system, and which high-consequence facts must still be checked against the original record before anyone acts.
Approve use, not only connection
Decide whether the assistant may use sensitive context once, ask every time, or retain an ongoing permission. Keep the narrowest default and make the user-facing override and revocation path explicit.
Keep professional escalation
Require a person or qualified professional for diagnosis, treatment, legal advice, financial commitments, employment decisions, and other high-consequence judgments. The assistant may help prepare questions or summarize context; it should not become the final authority.
Verify the current vendor controls before approval. For this example, review OpenAI's Health launch guidance and Health Privacy Notice. OpenAI also warns that connected information may be incomplete or outdated and that Health supports, rather than replaces, medical care.
Review again when the approval boundary changes
A calendar reminder is useful, but material changes should trigger a new decision immediately. Re-open the approval record, compare the new scope with the original boundary, and record who approved the change.
A connector or data scope changes
Review again when a new app, workspace, folder, inbox, repository, record source, or sensitive-data class is connected. Prior approval applies only to the locations and data classes that were actually reviewed.
The assistant gains a new action right
Review again when read-only access expands to drafting, editing, sending, publishing, merging, deploying, deleting, paying, or changing access. Move the human gate to the action that creates the new consequence.
Retention, data use, or model routing changes
Review again when the vendor, plan, administrator setting, model, subprocessor, retention period, or data-use policy changes. Confirm whether the original privacy and professional-boundary decision still holds.
Ownership or operating context changes
Review again when the workflow owner, approver, team, customer population, risk level, or offboarding path changes. Revoke stale access first when nobody can still defend the original approval.
Choose one decision path
Approve a narrow pilot
Use one team, one low-sensitivity workflow, read-only access where possible, and the smallest connector scope that can prove the use case.
Pause for controls
Pause when the assistant needs broad workspace or sensitive-data access but ownership, source currentness, logs, approval gates, retention, professional escalation, or offboarding are not yet clear.
Reject the connection
Reject when the proposed access is broader than the buyer job, cannot be revoked cleanly, or bypasses an existing review, professional, or security boundary.
If you approve the narrow pilot, carry the same workflow, owner, review window, and stop conditions into the pilot record before expanding seats or connector scope.
If the pilot proves value and a paid or wider rollout is next, review plan terms, security controls, data handling, renewal terms, and the exit path before signing or expanding the commitment.
Record the approval boundary
Write down the approved workflow, connected locations, allowed actions, required human or professional gates, owner, review date, and revocation steps. Use the copyable checklist to turn this decision into a reusable handoff instead of relying on a one-time conversation. If the decision is to revoke or replace the assistant, continue into offboarding to inventory dependencies, export needed data, verify access removal, and close the vendor lifecycle cleanly.