Client Teamspace Leak Through a Shared Parent Page
Lumen Studio is a 180-person design agency with 95 guests across 30 client accounts. Each client has a dedicated page inside the Client Delivery teamspace, but that teamspace is open to every full member, so most client pages rely on page-level sharing. Last week a junior PM opened the Acme Hub page, used Share, and invited the client's marketing coordinator as a guest with Can view, intending to expose only a project brief. The Acme Hub has 14 child pages, including an internal rate card, contractor contact list, and retro notes. Two days later the ops lead saw the guest's name in the page visitor list and realized the contractor list had been viewed. The workspace allows guests, public link sharing is enabled, and there is no SCIM. Leadership wants client collaboration to stay easy but accepts tighter structure.
1. Diagnose why the Acme guest could see internal content, and state what the guest could and could not access.
Read the worked answer
The guest was invited to the Acme Hub page, not to a teamspace. In Notion, page permissions flow down the page tree: anyone with Can view on a parent page can open its child pages unless those children have been moved out of that tree. The guest therefore had Can view on the hub and all 14 descendants, including the rate card, contractor list, and retros.
Can view is read-only, so the guest could not edit or delete content, but viewing the contractor list was already a confidentiality breach. The guest could not see unrelated teamspaces or pages that were not descendants of the hub. The guest also could not see pages merely linked from the hub if those pages were not shared, because links do not grant access.
The root cause is content architecture, not the guest invite. Client-safe and internal material were mixed under one shareable parent, and the teamspace was open to all members, so page-level sharing became the only control. Public link sharing being enabled is a separate risk but did not cause this specific leak.
2. Design a target permission model for client collaboration that preserves ease of use.
Read the worked answer
Separate client-safe content from internal content at the teamspace level. Put client deliverables in a Client Delivery area whose pages contain only material approved for clients. Move rate cards, contractor lists, and retros to an Internal Ops teamspace, and never make internal pages children of a client-shared parent.
If 30 per-client teamspaces are too heavy, use one closed Client Delivery teamspace and add each client guest only to that client's page. Guests should not be added to a shared parent that contains internal descendants. For higher-touch accounts, create a private teamspace per client and invite the guest to the teamspace with Can view or Can comment. That makes the teamspace the permission boundary.
Use groups for internal staff and named guests for external users. Turn off guest sharing if guests do not need to re-share. Restrict public link creation to owners or a small admin group. Add a rule to the page template: client-shared pages may contain only client-safe content, and internal references must be plain text, not child pages.
3. What immediate containment and preventive controls should Lumen apply?
Read the worked answer
Immediate: remove the guest from the Acme Hub or replace page-level sharing with the intended narrow share. Check the page's visitor list and page history, and use the audit log if the workspace is on a plan that provides it to see permission changes and guest activity. Determine whether the contractor list contained personal data and trigger the privacy incident process if required. Do not delete the page before preserving evidence.
Preventive: disable public link sharing workspace-wide or restrict it to workspace owners. Require approval for guest invites, and turn off the setting that lets guests share pages if client collaboration does not need it. Restructure client content so internal pages are never descendants of a shared parent. Run a quarterly access review of guests and externally shared pages, and add a short training module on inheritance. The key judgement is that a guest invite is not a page-level action in a mixed page tree; the permission boundary must be designed before the invite.