Security & compliance

Least-privilege data access

Updated on Oct 5, 2026 · 1 minute read

Roles decide what a person can do; data scope decides which conversations they can see. Keeping these two axes separate is what lets ArcGlass apply least privilege to your most sensitive data — your field conversations — without turning administration into a full-time job. For the role side, see Access control & roles.

Two visibility postures

Open (the default)

Every member with content access sees all of the organization's conversations. This is the simplest posture — no configuration, ideal for a single team or a small company where everyone is meant to see everything.

Scoped — visibility follows the reporting structure

Turn on scoped visibility and access becomes least-privilege, driven entirely by your org chart. In a scoped organization, a person sees:

Their own conversations — the meetings and emails they actually took part in.
Their team's conversations — everyone who reports to them, transitively down the reporting tree.
Conversations at the accounts they're staffed on — so a rep working a deal sees that account's activity even when they didn't personally attend every call.

🌳

Down the tree, never sideways. A manager sees their reports' conversations; a rep does not see a peer's. You see your own and everyone below you in the reporting structure — not colleagues at the same level, and not your manager's. Managers gain team visibility the moment RevOps or HR draws the reporting line — there are no per-user access lists to build or maintain.

How the boundary is drawn

By identity, not by who uploaded. "Your own" means conversations where you were a participant — resolved from your verified identity, not from which account imported a recording. If you sign in with one address but appear in meetings under another, both resolve to a single you, so nothing is accidentally hidden or exposed.
From the org chart, not a separate ACL. The reporting relationship you already maintain (in ArcGlass or via SCIM) is the access policy. Change a manager and visibility follows on the next request — nothing else to update.
Only the Organization Owner is org-wide by role. Everyone else is bounded by the tree. An individual can be granted an explicit organization-wide override when a role genuinely needs it (for example a RevOps analyst), and that grant is itself auditable.
Administrative roles see no conversation content at all. IT Admin, billing, and people-management roles carry no content visibility — scoped or open.

🔑

Scope is enforced at a single choke point: every content list and detail passes through one row-visibility filter, and identity always comes from the verified session — never a user id, org id, or role supplied in a request.

What a list does — and doesn't — do

A Company List is a convenience for filtering, not a grant. Sharing a list lets a teammate narrow their view to the same set of companies — it never widens what they can see. The underlying rows are still bounded by their own data scope. Access and organization are deliberately separate concerns.

Beyond scope: confidential conversations

Scope limits who sees what by role and reporting line. Some internal conversations — HR, compensation, legal — shouldn't be visible to the whole company even in an open org. Those are handled separately by the sensitivity screen, which can restrict a conversation to its attendees or keep it out of company-wide analysis entirely. See Sensitive emails & meetings.

SecurityAccess control & roles → SecuritySensitive emails & meetings → EnterpriseSSO & SCIM →