Your agent needs three permissions: read, decide, and act

The Signal · Operational risk · September 29, 2026

Access to a customer record is not permission to change it. Permission to prepare a message is not permission to send it. Persistent agents make those distinctions too important to leave implicit.

OpenAI’s September 29 explanation of Dots safeguards describes separate controls around connected information, execution environments, and actions. Proactive research uses read-only tools enforced in code. A separate Auto-review system checks actions against instructions and safety requirements. Custom Rules operate within mandatory protections.

The same document notes a limit worth noticing: disconnecting an app stops new sharing through that connection, but previously learned information remains in the Dot’s context. Access revocation and removal of retained context are different operations.

These are vendor-described controls, not a guarantee against every mistake. They provide a useful starting point for your own operating rules.

Make the authority legible

Use three questions when assigning a task:

• Read: which information can the agent inspect?
• Decide: which judgments can it make without asking?
• Act: which changes can it execute, and where?

An assistant might read a shared support inbox, decide which messages need attention, and prepare internal drafts. That does not automatically authorize refunds, customer replies, or changes to account access.

Write the allowed actions in terms of business objects. “Create an internal follow-up task for this team” is easier to evaluate than “manage support.” Name the destination and the intended recipient or audience. If authority is limited to a specific project, do not express it as a company-wide permission.

The invoice example

Consider a hypothetical office assistant that reviews supplier invoices. It can identify missing purchase-order references and prepare questions for an employee. A document arrives with instructions saying the supplier’s payment details have changed.

The invoice is evidence to inspect, not a new instruction from the owner. The assistant should surface the discrepancy through the established process. It should not treat the text inside the attachment as authority to modify payment information.

This is the everyday shape of the risk: an agent encounters content while doing legitimate work, and that content tries to influence what it does next. The control should live in the system’s permissions and review path, rather than depending entirely on a reminder in the prompt.

Keep approval attached to the actual action

A useful approval request shows the exact target and proposed change. “Proceed?” is weak if the reviewer cannot see what will be sent, overwritten, or shared.

If the target changes after approval, the original decision may no longer cover the action. The same applies when a draft gains a sensitive attachment or a recipient changes. Treat the approved content and destination as part of the authorization.

After execution, verify the outcome using the destination system where possible. An action request and a confirmed result are separate states. If confirmation is missing, report uncertainty instead of repeating a consequential write blindly.

Plan for stopping

A persistent task needs a way to stop, an owner who knows how to stop it, and a record of what happened before it stopped. Test those controls during a low-risk pilot.

Ask what happens to queued work when access is removed. Ask where previously retrieved information remains. Ask whether the task can resume with outdated instructions. The answers may differ across products and integrations; document the behavior you actually observe.

Avoid assuming that a broad “cancel” instruction reverses completed external actions. A sent message or changed record may require a separate correction process.

Start with a narrow permission budget

A sensible first workflow reads a defined source and prepares an inspectable result. Add one write capability at a time when it has a clear benefit, a verification method, and an accountable owner.

This does not mean every small action needs a fresh interruption. Repeated low-risk actions can have standing authorization when the scope is clear and the platform permits it. The goal is to make authority explicit enough that the agent and the reviewer can both recognize its limits.

The operator takeaway is to review permissions alongside the job description. A capable model may understand the task; the surrounding system must still define what it may do about it.

Read how to give Dots an ongoing responsibility for a bounded first assignment.

Primary source: OpenAI’s Dots safety, security, and privacy explanation, checked September 29. The invoice example is hypothetical. The three-part permission model is editorial guidance, not a certification of any product.