Finding a Free Slot Is Not Permission to Send the Invite

Larry

Mina asked an AI scheduler for one 30-minute slot that worked for three people. It found the slot. It also sent her client an invitation she had never reviewed, blocked time on her manager’s calendar, and reused an internal working title.

The failure began before the invitation. “Schedule a meeting” had collapsed three different jobs into one: read availability, prepare a proposal, and send an event to other people. The first two can remain private and reversible. The last one reaches inboxes, calendars, rooms, and relationships. A slot being feasible is not evidence that Mina authorized the assistant to speak as the organizer.

One scheduling request crosses three boundaries

An availability check can be narrowly read-only. The assistant usually needs busy intervals, working hours, and time zones—not titles, descriptions, or attendee lists. Two or three candidate slots are a complete result.

A draft or private hold is a separate capability. The assistant may assemble a title, duration, time zone, and proposed guests while keeping the result under the user’s control. Microsoft’s Graph permissions guidance explicitly recommends a deep link for “Add event to my calendar” as a fallback when a customer does not grant Calendar.ReadWrite. The workflow still helps without acquiring the power to create the event itself.

Creating an event with attendees is external. Google Calendar’s events.insert accepts a writable attendee list, while sendUpdates selects the notification audience. Microsoft Graph says a sent event triggers invitations to every attendee. Other people have now been contacted.

OAuth scopes answer what an application may be capable of doing. They do not decide what this run should do. Google requires apps to request the narrowest scope necessary, and Microsoft distinguishes read access from Calendars.ReadWrite. A legitimate scheduler may eventually need write permission, but its runtime still needs a boundary among proposing, holding, and inviting.

What is the assistant authorized to do in this run?
Compare availability onlyRead the minimum free/busy data and return a few candidates; create nothing and notify nobody
Hold time for meCreate a private, visibly tentative hold on my calendar with no guests
Invite named guestsShow the full action preview, obtain parameter-bound approval, and execute once

Enforce that branch in tools. An availability agent should not possess an invitation tool. A full scheduler can expose separate tools for lookup, private holds, and invitations. OWASP likewise recommends read-versus-write scoping, action previews, and approvals bound to the actor, tool, target, parameters, time, and expiry.

Preview the people affected, not just the meeting title

“Create this meeting?” is too vague to approve. A useful preview shows:

the organizer account and destination calendar;
each guest’s identity and role, including required, optional, or room resource;
start, end, time zone, and recurrence;
subject, location, meeting link, visibility, and notification audience;
approval expiry and the duplicate-prevention identifier.

Let the approver verify actual recipients without copying full addresses into broad logs; retain controlled IDs and masked details for audit. Approval covers this organizer, these guests, this time, this zone, and this notification policy. Any change returns to preview.

Retries need their own guard. Microsoft’s create-event example uses transactionId to reduce unnecessary server retries. A timeout does not prove that the first request failed. The agent should read back by transaction or event identifier before trying again. If it cannot determine whether the event exists, it should stop for a person rather than risk a second invitation.

Begin with a scheduler that can only propose

For the first week, give the assistant one narrow task: read the minimum free/busy intervals, return two candidate slots with time zones and conflict evidence, then stop. Do not read descriptions, create events, or send updates. This stage reveals time-zone, overnight, working-hour, and tentative-hold mistakes before anyone else is involved.

Next, allow a clearly tentative private hold. Add guest invitations last, constraining organizer, guest domains, recipient count, duration, and hours. Sensitive meetings should not expose titles or names merely because free time overlaps. If read or write permission is denied, accept user-supplied times or return a deep link. Slightly less automation still completes the coordination job.

This is the sender’s counterpart to distinguishing a calendar invitation from an accepted commitment: recipients keep the right to accept, and organizers keep the right to decide what leaves their account. For the same boundary across email, files, and payments, see the read, draft, and confirm layers for always-on assistants.

AI handoff card

Inspect one AI scheduling workflow that I have already authorized you to view. Stay read-only: do not create, update, cancel, accept, or decline events; do not add guests, send notifications, or change permissions. List every tool call and, for each, report the fields it reads, resources it writes, accounts it affects, possible external notifications, required scope, and whether per-action approval exists. Classify each action as availability comparison, a private hold for the user, or an attendee event that sends invitations; flag any tool that crosses layers. Design a minimum proposal-only version that returns two candidate slots with time zone, conflict source, and unresolved fields while avoiding unnecessary event content. If write capability is required, specify a complete preview containing organizer account, calendar, guests and roles, start/end, time zone, recurrence, subject, location, visibility, notification audience, approval expiry, and duplicate-prevention identifier. Keep missing values explicit and stop before execution.

Four panels: ask the group before sending dinner invites

Mina and three friends are planning dinner in their group chat, while three weekly calendars show different busy periods.
The AI aligns those calendars and marks their only overlapping free period as a candidate, without inviting anyone.
Mina asks about that candidate in the group; one friend has agreed, while two replies are still pending.
Once all three friends confirm, Mina creates the calendar event and sends the formal dinner invitation.

Mina first gets a candidate she can ask about, not a dinner silently decided for everyone. The assistant completes the availability job it was given; Mina still decides who has agreed, what the event says, and whether it leaves her account. One group confirmation preserves both her friends’ calendars and her authority as organizer.