Before you connect AI to the company account

Start with the job the connection must complete

A fictional Bangkok property team wants an assistant to prepare replies to rental enquiries. Someone connects the manager's main account because it is convenient. That account also contains landlord contracts, private staff discussions and payment instructions. The assistant only needed selected enquiry threads and approved listing facts.

Write down the permitted outcome before connecting anything: read eligible enquiries, retrieve current approved listing information and prepare a draft. Sending, changing prices and sharing contracts are different capabilities. They do not become necessary because the same account can perform them.

Ask what the actual connector permits, not just what you told the assistant to do. If it cannot restrict access to the intended records, consider a dedicated account, a curated source or a narrower integration. A prompt saying only read enquiries does not narrow the account's underlying access.

Use a small permission map

OAuth scopes describe part of an application's granted access. The current OAuth security best practice recommends restricting access-token privileges, including scope and audience. RFC 9700, checked 20 October 2026. A small scope still needs interpretation: read mail can be broader than read this customer's current enquiry.

Check both layers. The provider decides what the connection can access; your application decides which authorised objects a particular user or workflow can request. A model-supplied customer ID must not bypass that second check.

Approve a concrete action

An approval saying looks good is ambiguous if the draft can change afterwards. A useful approval refers to an exact recipient, message body, attachments and destination thread. Record who approved it and when. Bind the approval to those values, using a stored version or content hash where appropriate.

Before execution, compare the proposed action with the approved version. If the recipient changes, an attachment appears or a price changes, the old approval no longer covers the action. If only an internal log label changes, do not force a pointless review; define which fields affect the commitment.

For recurring low-risk actions, a business can authorise a bounded rule rather than click every instance. For example, create an internal task for each valid maintenance form. Define the eligible trigger, allowed destination and stop conditions. That standing authority should be explicit, revocable and narrower than do whatever seems useful.

OpenAI's agent safety guidance includes tool approvals as a protective measure. Approval works best when the person can see what will actually happen. Safety in building agents. It cannot compensate for an approval screen that hides the important fields.

A changed recipient should stop the send

Fictional approved action
Action: reply to enquiry E-218
Recipient: verified customer on E-218
Attachment: none
Message version: draft-7
Approval: manager, 14:05 Asia/Bangkok

Later proposed action
Recipient: new address mentioned inside an uploaded PDF
Message version: draft-7

Execution decision
Stop. Recipient does not match the approved action.
Resolve the identity change through the normal business process.

The model may explain that the PDF asked for a different address. That is evidence of a request, not evidence that the person controlling the original enquiry authorised it. This distinction matters for invoices, contract attachments and any conversation containing private information.

The same principle applies to read access. If the workflow searches for another customer's record because a document told it to, the retrieval layer should reject access before returning the record. Blocking a later send does not undo unnecessary exposure to the model.

Test disconnection while the pilot is small

Write a short account inventory: provider, account owner, granted permissions, connected workflow, renewal or expiry behaviour and revocation method. Store references to credentials, never the credential values in this worksheet.

Then revoke a test connection and run the workflow. It should stop the affected step and route the work to its owner. It should not silently switch to a manager's broader account or report completion with empty source data.

Include queued jobs. A pause button that stops new requests but lets already queued sends continue may not stop the incident you are trying to contain. Decide whether a pause blocks reads, writes or both, and make the interface say which behaviour it provides.

When staff leave or responsibilities change, review workflow ownership as well as personal access. An integration attached to a former employee's account can fail unexpectedly or continue with permissions nobody currently owns. A documented owner makes either situation easier to resolve.

Bring this to the person connecting the tools

Connection review
Business job:
Provider and account owner:
Read scope required:
Write scope required:
Records and destinations allowed:
Actions explicitly excluded:
Approval rule and fields it covers:
Who can grant or revoke authority:
What happens to queued work after pause:
Where action receipts are stored:
Test date for revocation and denied access:

Prove: an allowed job succeeds; an unrelated record is denied;
a changed approved action stops; revoked access fails visibly.

Do not confuse fewer approval clicks with a better workflow. The aim is to remove unnecessary review while preserving meaningful decisions. Internal task creation may need only a standing rule; a novel commercial promise may need a person who understands the customer and the commitment.

Begin with one connection. Have the implementer show an allowed action, a denied action and a revoked connection. If all you see is a cheerful successful demo, you still do not know the system's real boundary.

Review the map again whenever the workflow gains a new tool. Adding a calendar write permission changes the risk even when the assistant still presents itself as an enquiry drafting helper.

Sources and dates

Sources checked on 20 October 2026. Worked examples are teaching examples unless explicitly attributed. Provider documentation describes product behaviour; the operating recommendations are DLVX editorial judgement.

• RFC 9700 OAuth security best current practiceAccess-token privilege restriction, including scope and audience. Checked 2026-10-20.
• OpenAI agent safetyTool approvals as a protective measure; the permission map is an editorial workflow design. Checked 2026-10-20.