What should I check before connecting an AI tool?

Watch the briefing

Watch the full video on YouTube

Full briefing transcript

You ask an AI tool for two possible meeting times. Its calendar connection also offers permission to cancel events. Do you need that permission for this job? In our fictional design, no. Matching access to the task comes before connecting. Reading availability and changing a calendar are different capabilities, and permission to perform an action is not the same as your instruction to perform that action.

Our original permissions diagram has three rows. Read availability exposes busy and free blocks. Read details exposes event titles, attendees, and notes. Write events permits creating, editing, or canceling entries. This is not a screenshot of a real product, and these are invented scopes. Actual apps may bundle permissions differently or lack a narrowly scoped option. We have not installed a connector, signed in, or opened anyone's calendar.

The task is simply to draft two possible times for a planning call. In the fictional workflow, availability blocks are enough; full event notes and write access are unnecessary. If a real connection requests broader access, stop and assess it against organizational policy and the provider's current documentation. Do not assume that an attractive connect button means the access is appropriate, or that a broad permission can always be reduced.

Our illustrative draft suggests September twenty third, eleven until eleven thirty, or two until two thirty. Both choices are provisional. The organizer must check actual availability before using them, and no invitation is sent. We wrote this output rather than running a calendar tool. Its teaching value is the boundary: suggestions remain text until a person reviews them and separately authorizes an action through an approved workflow.

Now introduce a different proposed action: cancel the existing planning meeting on September twenty third, ten until ten thirty. That cancellation is outside the request to suggest times. The arrow stops at human review; nothing is executed. Review the exact event, affected people, consequences, and authority before any such change. Even if a connector technically allows cancellation, that access does not turn a scheduling suggestion into approval to delete an appointment.

Check two layers: what the connection can access or change, and when the assistant asks before using that access. OpenAI's current app documentation distinguishes those layers and treats cancellation as a potentially important action; behavior depends on the app, account, and workspace controls. Verify your actual settings rather than expecting identical prompts everywhere. Also examine applicable data handling, training, retention, administrator rules, and how to disconnect or revoke access when it is no longer needed.

Match permissions to the task and require review for consequential actions. For our invented availability task, avoid unnecessary details and write permissions. For a cancellation, require a separate, explicit decision about the exact change, not a vague approval to connect. This diagram is a planning aid, not proof of connector safety. Before connecting a real tool, confirm its actual scopes and policies; before changing anything, review the proposed action.