Setting Up Your Organization in the Operator Console
End-to-end checklist for security admins to stand up a Zeuslock tenant: organization, SSO, detection profile, alert channels, pilot group, and device pairing.
What you will configure in the next 30 minutes
The Operator Console at app.zeuslock.ai is where you turn a fresh Zeuslock tenant into a production-ready DLP platform. Sign in with the email you used to register — your initial account is provisioned as Owner. This guide walks an operator through the canonical sequence: create the org, invite the team, wire up SSO, pick which findings to enable, route alerts, ship a policy to a pilot group, and only then open the doors to the whole company.
Work through the steps in order. Each one is short, but skipping ahead — especially the pilot group — tends to produce false-positive storms that erode trust in the platform.
The setup sequence
- Create the organization. Go to
Settings → Organization → New. Enter the legal entity name (this appears on incident exports and DPAs), pick the primary region —eu-west-3(Paris) is the default and the right choice for any EU-resident workload — and set the default language for console UI and end-user notifications. Region cannot be changed once incidents are recorded; language can. - Invite the security team. Navigate to
Settings → Members → Invite. Zeuslock has four roles, each scoped to the principle of least privilege:- Owner — billing, tenant deletion, role assignment. Keep this to two people maximum.
- Admin — policies, integrations, SSO, custom detectors. The day-to-day operator role.
- Operator — review incidents, triage, comment, escalate. No policy edits.
- Auditor — read-only on everything including audit logs and CSV export. Designed for compliance and internal audit.
- Connect SSO. Open
Settings → Authentication → Single Sign-Onand pick your identity provider. Sub-steps are below. - Configure the default detection profile. Under
Policies → Detection Profile → Default, enable the four finding families that produce signal from day one:credentials(api_key, password, private_key, JWT, Bearer tokens),PII(email, phone, SSN/NIR, passport, IP),financial(credit_card, IBAN, crypto_wallet, connection_string), andsource_code. Leavebehavioraloff until you have at least two weeks of baseline traffic — it relies on per-user norms that have to be learned. - Set alert channels. Under
Integrations → Alerting: connect Slack via the OAuth button (choose the channel that the on-call sec team actually reads), add a Microsoft Teams incoming-webhook URL, paste a generic HTTPS endpoint for your SIEM (Splunk HEC, Microsoft Sentinel, or anything that accepts HMAC-signed JSON), and enable the email digest at the cadence that matches your operations rhythm — daily for active security teams, weekly for smaller orgs. - Create your first group. Go to
Settings → Groups → Newand create a group namedpilot-security. Add the security team itself. This group will receive any new policy first, so that you catch surprises on your own team before they hit a sales rep at 4 p.m. on a Friday. - Generate the device-pairing token. Under
Settings → Devices → Pairing token, clickGenerate. Copy the token into your fleet management tool (Intune, Jamf, GPO, or Workspace ChromeOS policy) as the value of theZEUSLOCK_PAIRING_TOKENenvironment variable. The browser extension and desktop agent will self-enroll on first launch without any user interaction. - Optional: configure data residency. If your contract requires France-only processing, open
Settings → Data Residencyand set the region binding tofr-onlybefore any incident is recorded. This locks every byte of finding context, ML confirmation traffic, and audit log to French infrastructure. The binding is permanent once the first incident hits the tenant — there is no undo.
Step 3 in detail: connecting your identity provider
SSO removes the password problem and unlocks SCIM provisioning. Configure one IdP per tenant. All three flows below produce the same end-state: a SAML 2.0 federation plus, where supported, SCIM 2.0 user/group sync.
Okta (SAML 2.0 + SCIM)
In the Operator Console, copy the ACS URL and Entity ID from Settings → Authentication → SAML. In Okta, create a new SAML 2.0 application named Zeuslock, paste both values, set the NameID format to EmailAddress, and map attributes email, firstName, lastName, groups. Download the IdP metadata XML and upload it back into Zeuslock. For SCIM, enable Provisioning → To App, paste the SCIM endpoint and bearer token shown under Authentication → SCIM, and tick Create / Update / Deactivate users.
Azure AD / Entra ID (SAML 2.0 + SCIM)
In Entra, create an Enterprise Application from the gallery search Zeuslock, or create a non-gallery app with the same name. Configure Single sign-on → SAML with the ACS URL and Entity ID from the console. Map claim user.mail to NameID. For SCIM, in the Provisioning blade choose Automatic mode, paste the SCIM endpoint and bearer token, and assign the security group that should sync. Test with Provision on demand before enabling the schedule.
Google Workspace (SAML 2.0, SCIM not supported)
In the Google Admin Console, open Apps → Web and mobile apps → Add custom SAML app, name it Zeuslock, download the Google IdP metadata, and upload it into Settings → Authentication → SAML → IdP metadata. Set the ACS URL and Entity ID from the Zeuslock side. Workspace does not expose SCIM externally — instead, enable Just-In-Time provisioning in Authentication → SAML → JIT so that users are created on first SSO login.
Verification checklist before rollout
Do not invite the rest of the company until all three of the following pass:
- SSO works for 2-3 testers. Have at least three members of the security team log out, then log back in via your IdP. Confirm role mapping is correct and SCIM (if used) populated their group memberships.
- At least one Slack alert received. From
Integrations → Alerting → Slack, clickSend test alert. Confirm it lands in the right channel and that the on-call rotation actually sees it. - At least one real finding from your own browser. Install the extension on your own machine, paste the documented Visa test card
4111 1111 1111 1111into ChatGPT. Confirm the incident appears inIncidents → Livewithin ten seconds with the correct detector, the correct severity, and the right pilot-group attribution.
Roll out in the documented sequence: Monitor weeks 1-2, Anonymize weeks 3-5, Block week 6+. The platform supports going straight to Block on day one, but in practice that produces support tickets that you could have prevented with two weeks of pure observation.
Once verification passes, expand the pilot group to a second department, then to the full organization. The policy rollout playbook walks through the recommended cadence.