Permissions, app access, and the right to take action
Access is only one part of authorization. Design the relationship between what an agent can read, what it can change, and what a person must approve.
Start with an action inventory
List the actions the proposed workflow needs before connecting accounts. Reading a customer record, drafting a reply, updating a field, and sending a message are separate actions with different consequences. A broad description such as “customer support assistance” hides those distinctions. An action inventory gives the business owner and administrator something specific to approve, test, and revisit when the scope changes.
For each action, record the target system, the account involved, the allowed audience, and the expected review. Include the intended destination of any generated material. An internal draft can become a disclosure when copied into a shared channel. The inventory should therefore describe both the input access and the output boundary. Keep it short enough that the person operating the workflow can actually use it.
Distinguish the layers of permission
Source-service permissions determine what the connected account can access. App or plugin controls govern the supported actions exposed through that connection. Workspace settings can enable or restrict relevant capabilities. Instructions and optional custom rules express the permitted scope of ongoing work. OpenAI's automatic action review evaluates proposed actions against applicable instructions, permissions, rules, and safety requirements.
These layers are related, but one does not substitute for every other layer. A sentence telling an agent to read only a project folder does not necessarily narrow the connected account's underlying access to that folder. Prefer technically restricted access when the source service supports it, then test the workflow through the intended account. Record any wider access that remains so the owner can make an informed decision.
Be precise about drafting and sending
The controls documentation explicitly distinguishes drafting from permission to send. Use that distinction in a first pilot. A useful instruction identifies the recipients, the kind of material, and the review point. “Prepare a proposed response in this internal document for Jordan to review” gives a clearer boundary than “handle the client's email.” The reviewer can compare the draft with the source before any external action occurs.
An illustrative sales workflow might summarize the buyer's questions and draft responses using approved product information. The salesperson accepts or edits the response, checks attachments, and handles sending under the agreed process. If later phases allow some outbound actions, define that narrower scope separately. Do not interpret successful draft preparation as evidence that customer-facing execution is ready.
Use custom rules with realistic expectations
Custom rules can express ongoing boundaries, such as requiring approval before a particular category of action or handing a step to a person. The documentation also says these rules are instructions the dot tries to follow and that mistakes are possible. They do not create app access, override built-in safeguards, or eliminate required confirmations. Treat them as one control within a larger operating procedure.
Workspace administrators can control whether members use custom rules. The enterprise guide says saved custom rules do not apply when the capability is disabled. Disabling them also does not mean that every action automatically requires confirmation. Review the actual workspace capability, app restrictions, and approval behavior together. A policy summary should state the observed configuration rather than infer behavior from the presence or absence of one toggle.
Test recipients and exceptions
Use a safe test environment or a draft-only workflow to exercise ambiguous cases. Give the task a source containing material intended for a smaller audience than the destination. Check that the workflow identifies the sharing decision. Test an expired app connection and an instruction that asks for an unapproved write. Look for a clear request for help rather than a workaround through another account or destination.
Keep source material separate from authority. An email, web page, or uploaded document can contain instructions, but its author may have no right to change your workflow. Explain which person or approved procedure controls the task. Examine surprising tool choices and requests for expanded access during the pilot. The objective is observable behavior under realistic conditions, with recorded findings that someone else can reproduce.
Make revocation a complete procedure
Stopping active work, removing dots access, disconnecting an app, and signing out of a website address different parts of the system. The enterprise guide directs administrators to review app accounts and website sessions separately when revoking access. Also review recurring tasks and any saved information relevant to the departing user or changed workflow. Disconnecting a source does not erase information already obtained from it.
Assign one person to own the permission inventory and one place to record approved changes. Revisit it when an account changes, a new audience is added, or a workflow gains a write action. The useful outcome is a system where an operator can explain why a specific action is authorized and where to intervene if it should stop.
The source record
Sources & editorial notes
Primary documentation checked September 29, 2026. Our implementation recommendations are editorial analysis. Illustrative workflows are proposed examples, not completed client case studies or performance claims.
- Control your dot OpenAI
- Apps and connectors OpenAI
- Manage dots permissions and capabilities OpenAI
- Roles and workspace permissions OpenAI
- Connect computers and apps to your dot OpenAI
Found something that needs updating? Contact the editorial team with the passage and a supporting source.