Skip to main content
Access management (/access) is one page for every principal that can reach the workspace. It replaces six older surfaces that each answered part of the question separately. API keys sit beside the people on purpose: a key authenticates as the person who created it, so a page about who can do what is wrong without them.

​
The tabs

A tab you cannot read is not shown. That is deliberate: an entry that leads only to a refusal is worse than no entry.
Old links keep working. ?tab=users, ?tab=api-keys, ?tab=roles-permissions, ?tab=sso and the other former slugs resolve to their current tab, and the URL is rewritten to the tab you are actually looking at, so a copied link reopens what the sender saw.

​
Built-in roles

Nine roles ship with the platform. Five of them exist specifically so a large organisation can separate duties instead of handing out admin.
security-admin is the role that makes the platform separable: an IT admin can add and remove people without being able to read a single prompt, dataset, or scan result.It carries roles.view and deliberately not roles.manage. roles.manage can add any permission to a role its holder already has, so granting it here would let a security-admin give themselves data access in two clicks and quietly make “no data access” a lie. Defining roles stays with admin; security-admin only assigns roles that already exist.
compliance-auditor is read-only on purpose. An auditor who can change the thing they audit is not an auditor. Its only writes are producing reports and running the audit-chain verification.

​
Custom roles

Admins can define custom roles from the granular permission catalog. A custom role is a named bundle of permissions, nothing more. Role names must be 2 to 64 characters, start with a letter, and use only letters, numbers, underscores and hyphens. A name that collides with a built-in role is rejected.
A built-in role cannot be deleted, and a custom role cannot be deleted while it is still assigned to somebody. Reassign those people first, then delete the role. Deleting a role also drops its permission overrides.

​
Permission catalog

Permissions are grouped by category and are the same keys the API enforces. A representative sample: The endpoint DLP permissions live in their own dlp. namespace and are listed in DLP permissions.
runtime_security.manage and runtime_security.policy.manage were broad umbrellas that have been split into the narrower keys above and the dlp. keys. Both still resolve to everything they used to grant, so no existing role loses access, but define new roles from the narrow keys.
compliance.verify is deliberately not implied by compliance.manage. The verifier’s numbers span every workspace on the deployment, because the audit hash chain is global, so it is granted only to admin and compliance-auditor rather than travelling with a broader key.

​
Explain access

The Explain access tab answers a specific, awkward question: why can this person do this, or why can’t they? Pick a person and a permission, and it traces the answer through their roles rather than leaving you to read the matrix yourself. Use it before changing a role. It is usually faster, and it tells you which role is actually responsible.

​
Per-resource access

Beyond workspace roles, datasets and projects carry their own sharing. The workspace role is the floor; a resource grant can raise it for one dataset or project.
Give a contractor viewer at the workspace level and share exactly the one project they need, rather than promoting their workspace role.

​
Invitations

Blindsight is invite-only: every account arrives by invitation, and there is no public sign-up.
1

Invite a person

From the People tab, enter one or more work emails and pick the roles they get. Only professional domains are accepted; consumer, disposable, and relay mail domains are rejected inline. The dialog shows the seats the invitations will use before you send.
2

They set a password

The invitee gets an acceptance link and chooses a password from it. Accepting activates the account; it does not sign them in. They then sign in normally, enrolling two-factor first if your workspace requires it. There is no display-name field: the name comes from you, or from their own profile later.
3

Manage pending invitations

Pending invitations show on the People tab and hold a seat until they are accepted. Resend issues a brand new link and kills the old one; Revoke kills it outright. Links expire after 7 days by default.
The full lifecycle, the work-email policy, and the limits on which roles you can hand out are in Inviting your team. What the invitee sees, through to their first sign-in, is in Accepting an invite.

​
Directory and SSO

SCIM provisions people from Entra, Okta, or Google into the workspace, and OIDC binds each sign-in to a directory user. The sign-in policy next to it controls the workspace’s own authentication rules. SAML is schema-ready in the backend but not enabled in this build. OIDC covers Entra, Okta, Google, and Ping. See Identity binding for how the same directory binds DLP devices to people.

​
API keys

Everything in the UI is also available over the REST API. To use it programmatically, mint a key from the Keys tab.
1

Create the key

Give it a descriptive name (CI pipeline, Lab upload script).
2

Scope it

  • Full access (*): every scope the platform defines, across Data Security and Runtime Security.
  • Full runtime access (runtime:*): the runtime: scopes only.
  • Or tick the individual scopes the key actually needs (datasets:read, runtime:scan, and so on).
A key can never do more than the person who created it. The full scope list is in the API reference.
3

Set an expiration

Never, 30 days, 90 days, or 1 year. Short-lived keys are safer.
4

Copy the token

Now. It is displayed exactly once. If you miss it, revoke and mint a new one.
Runtime Security keys can additionally be bound to specific Apps, so a key that leaks cannot be pointed at a different application.

​
Using the key

Pass it as Authorization: Bearer <token> on every API call.

​
Revoking a key

Click Revoke on any row in the Keys tab. Revocation is instant and audit-logged. Subsequent calls with that key return 401.

​
Rotation

Mint one key per pipeline. Rotate every 90 days. Store the new value in your CI’s secret manager, run jobs against both old and new for one rotation window, then revoke the old one.
Mint with Never expiry and rotate manually on a cadence. Name the key after the service so it is obvious in the audit trail.
Mint a short-lived key (30 days), use it, revoke when done. Treat ad-hoc keys like one-use tokens.

​
Your own profile

Every user has a profile page (/profile) with their display name and avatar, email and password reset, notification preferences per event type and channel, and their active sessions.

​
See also

Settings & licensing

Workspace-level configuration, quotas, and the license model.

DLP permissions

The dlp. namespace and what each key grants.

Audit trail

Every access change, recorded and hash-chained.

API reference

Scopes, routes, and try-it-out.