Short answer: connect a ChatGPT app with the narrowest permission level that can complete the job, keep sensitive or irreversible actions behind approval, and verify workspace, provider and app restrictions before relying on an automated step. OpenAI’s current Help Center describes four permission choices—Always ask, Allow read actions, Allow low-risk actions and Allow all actions where eligible—but a choice in the selector is not proof that every app, account or workspace supports every action.
This guide is for marketing and operations owners designing a connected-app workflow. It explains what the levels mean, where the boundary moves from reading to acting, and what to record before a message, file, sharing, access, purchase or deletion action can happen. It does not certify a connected app or replace your organisation’s security review.
What the four permission levels mean
| Level | Useful default for | Boundary to verify |
|---|---|---|
| Always ask | New or consequential workflows where a person should approve each action. | The approval card, the exact action, the target and the information shown before approval. |
| Allow read actions | Research, lookup and reporting that do not write to a connected service. | Which objects, documents, messages or records are exposed, and which provider scopes apply. |
| Allow low-risk actions | Repeatable, reversible actions that the app and account classify as low risk. | OpenAI says settings can be overridden by app, account, workspace or provider controls; important actions may still require approval. |
| Allow all actions | Only an eligible, reviewed workflow with an explicit owner and rollback path. | OpenAI describes this as elevated risk and not a standard account/workspace selector for every user or app. |
These labels describe permission policy, not a guarantee of quality. A low-risk action can still update the wrong record if the instruction, identity, target or source data is wrong. The connected provider may also require a separate scope or confirmation.
Separate reading, proposing and acting
Before selecting a level, write the workflow as three different capabilities:
- Read: retrieve only the fields, documents or messages required to answer the question.
- Propose: generate a draft, recommendation or change list for a person to inspect.
- Act: send, edit, delete, purchase, share, move, rename, upload, invite, schedule or change a customer-facing record.
The third category deserves a separate action boundary even when it follows a harmless-looking prompt. OpenAI’s examples of important actions include sending or editing messages, deleting data, purchasing or refunding, uploading or moving files, and changing sharing, access or security settings. Treat the target and the side effect—not just the wording of the prompt—as the risk unit.
A least-privilege setup for a marketing workflow
- Name the outcome: for example, prepare a weekly campaign summary or draft a customer-support reply.
- List the source fields: include the minimum account, audience, consent, spend, customer and creative data required. Exclude secrets and unrelated records.
- Start read-only: confirm the app returns the expected source and respects the provider’s access scope.
- Use a proposal state: keep drafts, recommendations or staged changes separate from a live send, publish or write.
- Add one reversible action: define the exact target, approver, log entry and rollback before enabling low-risk actions.
- Escalate consequential actions: require approval for sensitive, irreversible, external-facing, financial, access or sharing changes.
- Re-check after change: read back the target record or activity log; do not infer success from the assistant’s prose.
What can override the setting
OpenAI’s guidance says permission choices can be constrained by the app, account, workspace, connection and provider. A saved approval therefore does not override a workspace policy or a provider scope. Before rollout, record:
- the ChatGPT account, workspace and connected app;
- the provider identity and scopes;
- the selected permission level and approval behavior;
- the data classes the app can read;
- the actions the app can take and the actions that remain approval-gated;
- the person who reviews logs, denials, failures and rollback.
Permissions are also distinct from memory, retention and model-training choices. Document those controls separately so a team does not treat an action permission as a data-governance decision.
The approval-card checklist
When an approval card appears, review the proposed side effect rather than clicking through the summary:
- Does the named app and account match the intended provider?
- Is the target record, file, audience, recipient or channel correct?
- Is the action read, draft, reversible write or consequential write?
- Are the source values current and within the workflow’s data boundary?
- Would a duplicate send, update or upload create harm?
- Can the action be undone, and who owns the rollback?
If any answer is unknown, deny or keep the workflow in proposal mode while the owner verifies the setting. An approval card is a control point, not evidence that the output is factually correct.
Stop conditions before enabling low-risk or all actions
Keep the permission at Always ask or read-only when identity, target, scope, source freshness, consent, audit logging or rollback is unresolved. Stop the workflow if it requests credentials, expands beyond the approved provider scope, encounters conflicting records, attempts a destructive operation, or cannot produce a usable activity log. If a workspace administrator or provider blocks the action, do not work around the restriction with another connector.
Questions to document with security and operations
- Which actions are classified as low risk for this app, and who can change that classification?
- What happens when a task runs without an approver or when a provider returns partial success?
- How are denials, failed actions, duplicate attempts and sensitive-data access logged?
- Which retention, memory and model-training settings apply to the connected data?
- Can the workflow be disabled and its last action reversed without deleting the evidence needed for review?
Frequently asked questions
Is Allow low-risk actions the same as Allow all actions?
No. OpenAI describes Allow all actions as an elevated option for eligible apps, while important or sensitive actions can remain approval-gated and other account, workspace or provider controls can apply.
Can a workspace admin override an app permission?
Workspace, app, connection and provider settings can constrain what the account can do. Check the effective policy in the target workspace; do not assume a saved selector overrides it.
Should a marketer enable app actions for a customer-facing workflow?
Only after the team defines the data boundary, approval owner, audit trail and rollback. Start with read or proposal mode and add one reversible action at a time.
Bottom line
Use read access for discovery, proposal mode for judgment and the narrowest reversible action for automation. Treat Allow all actions as an exception requiring an accountable owner, provider-level scope review, approval/rollback design and a fresh read-back. OpenAI’s permission controls help make that boundary visible; they do not make an unverified workflow safe by themselves.
Related DMT guides
For adjacent workflow boundaries, see the guide to ChatGPT Work scheduled tasks, the ChatGPT Sites publishing boundary and the guide to OpenAI agent plugins and MCP.
Definition: app permission
An app permission is the effective rule that controls which connected service data ChatGPT may read and which actions it may attempt, subject to app, account, workspace and provider controls.
About the author
About the author: Tayeeb Khan publishes Digital Marketer Tayeeb, a research-focused resource for marketers and digital teams. This checklist separates documented product controls from account-specific verification and does not substitute for security or privacy review.
Editorial note: this article is based on OpenAI’s current Help Center and Academy guidance, independent privacy context and practitioner questions. App availability and permission behavior vary by account, workspace, provider and region. No private connected-app test or security assessment was performed.
