Authorizing meetings

Tenant administrators decide which AI teammates exist, which meetings they may join, and who may configure them. Authorization is an administrative choice, made once by people you designate, not a per-meeting negotiation.

Who holds authority

A Tenant Administrator has full control of the tenant: create, configure, suspend, or delete teammates, manage memory-sharing settings, assign administrative roles, and choose which teammates each Deployment Administrator looks after. A Deployment Administrator holds that role only on the teammates assigned to them. On those, it can configure standing instructions, voice, character, name, and backend binding, send them into meetings, and read their memory and audit history. On every other teammate it is a User, and a teammate created later is assigned to no one until a Tenant Administrator assigns it. It cannot create or delete teammates, share memory between teammates, change retention or other compliance settings, or assign roles.

Which meetings a teammate may join

A teammate joins a meeting when an administrator sends it in, right away or at a scheduled time. Before it joins, MeetCrew resolves the region the join is checked against. On Microsoft Teams that is the meeting organizer’s assigned tenant region, and a teammate refuses to join when that tenant holds no supported assigned region — the operating tenant’s admin is notified. On Zoom, Google Meet and WebEx there is no organizer signal, so the dispatching deployment’s own assigned region is used, which is in scope by construction.

Who may configure teammates

Configuration authority follows role assignment, and every write path is deny-by-default: absent an explicit role granting the requested capability, the request is refused. A Deployment Administrator’s authority is per teammate: a Tenant Administrator assigns and removes those teammates on the People page, and a removal applies from the very next request.