The machine
- Segments: user populations defined by Entra attributes (department, custom attributes) — the quality of IB is exactly the quality of those attributes.
- Policies: segment-pair rules — block (two-way) or allow-only. Policies compile into effective communication constraints.
- Evaluation: at ACTION time — add-to-chat, join-meeting (via the chat roster, hence the large-meetings interaction), add-to-team, calls, screen-share initiation. Existing memberships get swept by background processing after policy changes, not instantly.
Modes matter on containers: teams/groups carry an IB mode (open, implicit, owner-moderated…) deciding how membership constraints apply; meetings in IB tenants run the roster check regardless of the organiser's own segment status (the large-meetings module's trap).
Deployment order (the only sane one)
Attribute hygiene FIRST (the segments' raw material) -> segments defined and VALIDATED by count -> policies in simulation/audit posture, reviewing would-block reports -> activate -> background processing completes (large tenants: this takes real time; comms plan for the people who lose existing chats).
Interactions that page people
| Interaction | Effect |
|---|---|
| Large meetings | Chat-roster join gate + 750 pre-add arithmetic (see large-meetings) |
| Shared/private channels | Membership checks apply per channel type; shared-channel external members are outside IB's tenant scope |
| Federation/guests | IB governs YOUR users' pairings; external identities aren't segment members |
| Existing chats at activation | Blocked pairs' chats become inert (no new messages) — the visible, ticket-generating moment |
| App-only visibility | Purview cmdlets for IB are RBAC-gated app-only (our execution audit records Get-InformationBarrierPolicy as not served) — human-context review is part of the operating model |
What to watch (proofs)
- Segment membership counts vs HR expectations: the compiled segment sizes (Purview IB pages / cmdlets in human context) — a segment 10x expected = attribute drift feeding IB garbage.
- Policy application state: IB status per policy (applied/processing/errors) — 'active' before processing completed protects less than believed.
- The lived experience: test pairs across each blocked boundary — chat attempt blocked with the IB message; meeting join blocked at roster — screenshots dated for the compliance file.
- Attribute drift over time: the source attributes' change audit (HR sync logs) — IB decay is upstream decay; monitor the inputs, not just the policies.