Calendar Permissions for AI Scheduling Agents: Design Consent Boundaries

Design the scheduling authority model in eight steps

Use one fixture: an organizer asks an agent to book four required people and one optional observer across two companies. Two calendars are connected, one Microsoft connection expires, and one required person will provide availability without connecting. The permission model must survive that mixed state.

1. 1

   Create one meeting intent and authority ledger

   Store meeting request ID, revision, organizer, purpose, duration, date window, deadline, IANA time zone, required people, optional people, approved substitutes, contact channels, approval mode, and completion definition. Beside it, record who grants each operation, its scope, effective time, expiry, revocation state, and evidence.
   • Calendar read, participant contact, reminder, booking, update, cancellation, and rescheduling are separate grants.
   • Every grant points to a person, organization policy, or provider permission—not model inference.
   • Changing participants or purpose can require a new meeting revision and new authority check.
2. 2

   Resolve identities before requesting access

   Map the organizer account, authoritative calendar, participant identity, company or tenant, provider, known time zone, required status, and approved contact address. Keep uncertain matches unresolved. A shared name or forwarded email is not enough evidence to read a calendar or send outreach in somebody else’s voice.
   • The organizer calendar used for the final write is explicit.
   • Tenant and provider identity survive model, worker, and client restarts.
   • An identity conflict returns to a human before any sensitive operation.
3. 3

   Request the narrowest useful provider access

   Use approved Google and Microsoft availability operations when free/busy is enough. Record provider, granted scope or permission class, account, retrieval time, query bounds, time zone, and errors. Do not collect event titles, descriptions, locations, bodies, or unrelated attendee lists merely because a broader scope makes development easier.
   • A denied, expired, throttled, or partial response is missing evidence rather than free time.
   • Event-write access is requested only when the approved booking path needs it.
   • Provider credentials are stored outside prompts, traces, and participant messages.
4. 4

   Give unconnected participants a consent-safe fallback

   Calendar connection should reduce effort, not become mandatory. Tell the participant who is organizing, the meeting purpose at the approved disclosure level, duration, bounded date window, displayed time zone, response deadline, and intended use. Ask for usable windows, provide decline and correction paths, and cap reminders.
   • Possessing contact information does not grant outreach authority.
   • A response authorizes use for the declared meeting, not future unrelated scheduling.
   • Silence is not availability, consent, or permission to widen the channel.
5. 5

   Normalize evidence without widening disclosure

   Represent connected free/busy and conversational availability as intervals with participant, source, time zone, freshness, confidence, and permission state. Keep original replies in restricted storage when audit or clarification requires them. Overlap logic needs busy or available windows, not the private reasons behind them.
   • Ambiguous date or zone triggers one narrow clarification rather than a guess.
   • A participant correction supersedes old evidence and invalidates affected proposals.
   • Routine observability uses redacted identifiers and stable reason codes.
6. 6

   Bind approval to the exact side effect

   When review is required, present the selected slot, meeting revision, required and optional attendee set, organizer calendar, event wording, and evidence freshness. Approval authorizes that package. Adding an attendee, changing the time, switching calendars, or altering disclosed context invalidates it unless policy says otherwise.
   • Sensitive MCP or REST operations remain confirmable and deniable by the authorized human.
   • Approval expiry and human reclaim stop queued work.
   • The agent cannot trade privacy or required attendance for a faster result.
7. 7

   Make retries permission-aware and idempotent

   Use separate idempotency keys for each outreach purpose, proposal approval, and booking command. Re-check authority before a delayed retry. If an event-write response is uncertain, reconcile the organizer calendar before another write. A grant that was valid on attempt one may be revoked before attempt two.
   • A repeated command returns the original result instead of repeating the side effect.
   • Revoked access stops retries and returns a bounded reconnect or human-decision path.
   • Duplicate provider notifications and participant replies do not widen consent or repeat messages.
8. 8

   Verify completion and close the grants

   Read back the canonical event and verify approved start, end, time zone, organizer, required attendees, optional attendees, and invitation state. Record which grants were exercised, which were unused, and which remain valid for declared follow-up. Apply retention and revocation policy to tokens, availability evidence, messages, and traces.
   • A tool or provider success without the approved attendee result is not completion.
   • Every terminal exception names the missing permission and one authorized owner.
   • Cancellation or rescheduling starts a new authority check rather than inheriting booking consent blindly.

Compare permission approaches by the scheduling work they authorize

The right design protects people without turning every missing token into a human email relay. Compare provider access, application authority, and the path to a completed meeting together.