Join our Newsletter — 33% off our NHI Course
Home› Guides› Twilio Segment Security: Workspace Roles, Source Keys and…
Guide Privacy & Data Protection

Twilio Segment Security: Workspace Roles, Source Keys and Data Privacy

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 8 November 2026 12 min read
On this page

Twilio Segment sits in the middle of your customer data flows, collecting events from every website, app and server and forwarding them to analytics, advertising and warehouse destinations, so a mis-scoped role or token in Segment reaches every downstream system at once. Segment's security controls are mostly customer-side: workspace roles and resource scoping, PII Access, SSO and MFA enforcement, Public API tokens, source write keys, the Privacy Portal and end-user deletion. This guide explains how those controls fit together, how to keep Workspace Owner small, how to manage tokens and write keys as non-human identities, what Audit Trail records and how to forward it, and a privacy-focused hardening baseline. It is written for Segment workspace owners, data engineers, and the security and privacy teams who govern customer data.

This is an independent guide from NHI Mgmt Group, based on Twilio's public Segment documentation as of November 2026. It is not sponsored or reviewed by Twilio. Product features change, so confirm settings against Twilio's current documentation.

Key takeaways

  • Workspace Owner is the master key. Owners hold full edit rights, PII Access by default, sole access to the Privacy Portal and Audit Trail, and are the only people who can create Public API tokens.
  • Build access from scoped roles. Make people Workspace Members and add Source, Unify and Engage, Warehouse or Tracking Plan roles scoped to specific resources or Labels.
  • PII Access is a separate grant. Without it, fields classified Red or Yellow are masked; it never widens a user's resource scope, so grant it only where people need to see raw values.
  • Require SSO and MFA. Both are off until an owner turns them on in Advanced Settings; Segment recommends requiring SSO for most customers.
  • Forward the Audit Trail. It keeps 90 days in the app; Audit Forwarding sends events to a dedicated source so you can alert and retain them in your own systems.

How identity and access work in Twilio Segment

Segment organises everything in a workspace: sources that collect data, destinations that receive it, warehouses, Unify spaces for identity resolution, Engage audiences and journeys, Protocols tracking plans and functions. Users and groups are granted roles that apply to the whole workspace or to specific resources. When a user holds both user-level and group-level permissions, they receive the higher of the two.

Authentication

  • SSO: Segment supports SAML 2.0 with any SAML identity provider and has prebuilt connections for Okta, OneLogin and Microsoft Entra ID. SSO is on the Business tier. Verify your domain under Authentication > Domains with a DNS TXT record or meta tag; a domain can be claimed by only one workspace.
  • Require SSO: off by default. Turn it on in Workspace Settings > Authentication > Advanced Settings after signing in through SSO yourself, and grant exemptions only to named accounts that cannot use it.
  • Just-in-time and SCIM: users who arrive through the identity provider are created as minimal-access, read-only members. Use SCIM with role mapping to assign roles from identity provider groups. See the SCIM Provisioning Guide.
  • MFA: for password sign-in, users enrol an authenticator app or SMS (US and Canada only), and workspace owners can turn on Require MFA in Advanced Settings. SSO users get MFA from the identity provider, and Twilio Unified Login users configure it in their Twilio account. Segment also advises protecting the email account used for Segment, since email access can lead to account access.

Admin roles and privileged access

RoleWhat it grants (per Twilio)Scope optionsUse for
Workspace OwnerFull read and edit of everything, including team permissionsWhole workspaceTwo to four platform owners
Workspace MemberNothing by itself; access comes from assigned rolesNoneEveryone else, as the base
Source AdminEdit sources, settings, connected streaming destinations, schema, write key and debuggerAll current and future, a list, or a LabelEngineers owning specific sources
Source read-onlyRead sources, schema, transformations and debuggerAs aboveAnalysts and support
Unify and Engage admin / read-onlyEdit or read Unify settings and Engage audiences, traits, journeysAll, a list, or Label-based spacesMarketing operations
Warehouse destination admin / read-onlyEdit or read warehouse destinationsAll warehousesData platform team
Tracking Plan admin / read-onlyEdit or read Protocols tracking plansAll tracking plansData governance
End User Privacy adminEdit End User Privacy settings, suppression and deletion workflowsPrivacy settings onlyPrivacy operations
Observability admin / read-onlyFailure log collection data, including PII collections; requires PII AccessAll dataSmall on-call group
  • Keep Owners few: owners are the only people who can create Public API tokens, view the Audit Trail and use the Privacy Portal, and they hold PII Access by default. Two to four named people is a workable range; avoid giving it to agencies.
  • Scope with Labels: on Business, label sources and spaces by environment or region (for example production and EU) and scope roles to the label so new sources inherit the right access.
  • Watch cross-resource rights: connecting a source to a warehouse needs Source Admin and Warehouse destination admin; connecting destinations to an Engage space needs Unify and Engage admin plus Source Admin on the linked source. Combining these on one person lets them send a source's data anywhere.
  • Grant PII Access deliberately: it applies only within a user's existing scope, does not give Privacy Portal access, and is required for Observability roles. Review the list quarterly. See the Access Reviews Guide.

Integrations, API tokens and service accounts

Segment has three main kinds of machine credential. Each is a non-human identity with an owner, a purpose and a rotation plan.

CredentialCreated whereWhat it can doKey controls
Public API tokenSettings > Workspace settings > Access Management > Tokens (Workspace Owner only)Workspace Owner or Workspace Member access through the Public APIChoose Member where possible, server-side only, Bearer header, store in a secrets manager
Source write keySource > Settings > API KeysSend events into that sourceGenerate New Key adds a second active key; delete the old one after cut-over
Destination and warehouse credentialsDestination or warehouse settingsSegment writes into your tools or warehouseDedicated least-privilege accounts on the receiving side

Public API tokens

  1. Pick the access level: a token is created with Workspace Owner or Workspace Member access. Use Member for automation that does not need full control.
  2. Describe it: the description should name the pipeline, owner and ticket so tokens in the Audit Trail actor filter are recognisable.
  3. Keep it server-side: Twilio states the Public API is for server-side use only, with the token in the Authorization header as a Bearer token.
  4. Store it in a vault: Twilio notes tokens are often exposed through commits to public repositories. Segment works with GitHub secret scanning and revokes valid tokens found in public repositories, notifying owners; on such a notice, review the Audit Trail for that token's actions. See the Secrets Management Guide.

Write keys

A write key identifies a source and tells Segment where events belong. Keys used in browser or mobile sources are visible to anyone who inspects the page, so treat them as identifiers rather than secrets and protect data quality with Protocols tracking plans that define the events you expect. Keys used by server sources should be kept in a secrets manager. To rotate, open the source, go to Settings > API Keys and choose Generate New Key: the original stays active until you delete it, so deploy the new key, confirm events arrive in the debugger, then delete the old one. This needs Source Admin or Workspace Owner.

Destinations, functions and Twilio credentials

  • Destination credentials: give each destination a dedicated account or key in the receiving tool with only the write rights it needs, and record it in your non-human identity inventory. See the Service Account Security Guide.
  • Warehouse users: create a dedicated warehouse user for Segment limited to its schema.
  • Functions: Function Admin can change code that processes every event; keep it to engineers and review function settings that hold secrets.
  • Twilio account credentials: if you also use Twilio messaging, manage those API keys separately. See the Twilio Credentials Security Guide.

Logging and detection

The Audit Trail shows the last 90 days of user and system activity across sources, destinations, warehouses, tracking plans, audiences, journeys, users and workspace settings. It is available on Business to Workspace Owners at Settings > Admin, filterable by action and by actor (users and access tokens), and exportable to CSV.

Audit Forwarding

Turn on Settings > Workspace Settings > Audit Forwarding and select a dedicated HTTP API source, which Twilio recommends. Forwarded events go through the normal pipeline, so you can route them to your SIEM or warehouse, apply filters and keep them beyond 90 days.

Event areaExample detectionsATT&CK mapping
Users and workspaceNew Workspace Owner, PII Access granted, Require SSO or Require MFA turned offT1098 Account Manipulation
Access tokensToken created, token acting outside its normal patternT1528 Steal Application Access Token
Destinations and warehousesNew destination connected to a production source, warehouse settings changedT1537 Transfer Data to Cloud Account
SourcesNew write key generated, source deleted or disabledT1078.004 Cloud Accounts (when actor is unexpected)

Metrics

  • Workspace Owner count: target two to four.
  • Users with PII Access: trend down to those with a documented need.
  • Public API tokens at Owner level: target zero or a documented few.
  • Write keys older than policy: server-side keys past your rotation interval.
  • Audit Forwarding health: forwarded events received each day, target no gaps.
  • Deletion requests completed within SLA: share finished inside 30 days.

Hardening baseline

Privacy controls

  • Privacy Portal: the Inbox shows properties seen in the last 7 days from web, mobile, server and cloud event sources, pre-classified Red, Yellow or Green by default matchers. Review it weekly, add fields to the Inventory, and write custom matchers (up to 100) for your own identifiers. Red and Yellow fields are masked for anyone without PII Access.
  • End-user deletion and suppression: issue regulations from Settings > End User Privacy or the Public API (up to 5,000 userIds per call). SUPPRESS_WITH_DELETE and DELETE_ONLY also forward deletions to destinations that support programmatic deletion; contact the others directly. Segment's SLA is 30 days for its internal stores, not your warehouse, S3 or destinations.
  • Device-mode destinations: data sent directly from the device bypasses Segment's suppression point, so prefer cloud-mode destinations where you need suppression to apply.
  • Consent: Twilio states suppression is not a substitute for obtaining consent before collecting data. See the Consent Management Guide.

Phased rollout

  1. Inventory (week 1): export users, groups, roles and PII Access holders; list tokens, sources, destinations and warehouses; export the Audit Trail to CSV as a baseline.
  2. Identity (weeks 1 to 3): configure SAML SSO, verify domains, connect SCIM with role mapping, test with a pilot group, then turn on Require SSO with documented exemptions. Turn on Require MFA for any remaining password users.
  3. Roles (weeks 3 to 5): move people from Owner to Member plus scoped roles; apply Labels; record previous assignments so you can restore access if a pipeline owner is blocked.
  4. Credentials (weeks 4 to 6): recreate Owner tokens as Member tokens where possible, rotate server write keys with the two-key method, and move all secrets into a vault.
  5. Monitoring and privacy (weeks 5 to 8): enable Audit Forwarding, build alerts, set up Privacy Portal reviews and a tested deletion workflow.

Choosing between options

  • Labels versus resource lists: labels suit growing workspaces where new sources appear often; explicit lists suit small, stable estates.
  • Owner versus Member tokens: Member tokens fit most automation; reserve Owner tokens for provisioning tooling that manages users or settings.
  • Small teams: without Business features, focus on few owners, Require MFA, careful token handling and CSV exports of what is available.

Common misconfigurations

  • Everyone is Workspace Owner: gives every user PII Access, token creation and the Privacy Portal.
  • Require SSO left off after SSO setup: users keep password sign-in alongside SSO.
  • Owner-level tokens in CI pipelines: a leaked token then controls the whole workspace.
  • Old write keys never deleted: the second key is added, but the first stays active indefinitely.
  • Audit Trail never forwarded: evidence older than 90 days is gone when an investigation needs it.
  • Deletion assumed complete everywhere: warehouse, S3 and destinations without programmatic deletion need their own process.

Framework mapping

Control areaSegment settingNIST SP 800-53 Rev 5NIST CSF 2.0
Account managementSSO, SCIM, JIT, user and group rolesAC-2PR.AA-01
Least privilegeMember base role, scoped roles, Labels, PII AccessAC-6PR.AA-05
AuthenticationRequire SSO, Require MFAIA-2PR.AA-01
Authenticator managementPublic API tokens, write key rotationIA-5PR.AA-01
Audit loggingAudit Trail, Audit ForwardingAU-2, AU-6, AU-11PR.PS-04, DE.CM-03
Data protectionPrivacy Portal classification, deletion and suppressionSC-28PR.DS-01

Practitioner checklist

  • Limit Workspace Owner to two to four named people and make everyone else a Workspace Member with scoped roles.
  • Configure SAML SSO, verify domains, map roles through SCIM and turn on Require SSO.
  • Turn on Require MFA for any users who still sign in with a password.
  • Grant PII Access only where raw values are needed, and review it quarterly.
  • Create Public API tokens at Member level where possible, describe each one, and store them in a vault.
  • Rotate server write keys with Generate New Key and delete the old key after cut-over.
  • Enable Audit Forwarding to a dedicated HTTP API source and alert on owner, token and destination changes.
  • Review the Privacy Portal Inbox weekly and run deletion requests through a tracked workflow.

Standards and references

Related NHI Mgmt Group resources: SaaS Security Guide · Data Minimisation · GDPR Compliance Guide for Security Teams · API Key Management Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org