Skip to main content

Protection

Sources

Docs: Configure login Web App: Open Protection from the Workspace sidebar, then choose Login. Protection gives Workspace managers one place to control how people sign in and how an identity provider keeps access current. The safe path is simple: keep a working method active, configure the replacement completely, test it, and only then switch the Workspace over.

What Protection controls

Login methods

Choose one active way for the Workspace to sign in:
  • Magic Link sends a short-lived sign-in message by email and requires no identity-provider setup.
  • Social Login sends the team to the selected Google or Microsoft provider.
  • OIDC connects providers such as Okta, Microsoft Entra ID, or JumpCloud.
  • SAML connects any compatible SAML 2.0 identity provider.
Only one method is active at a time. Parable keeps the current method available until the replacement has the required configuration and passes its connection test.

Automatic user provisioning

SCIM can mirror people added, updated, or deactivated in your identity provider. This reduces manual invites and helps remove access when someone leaves. SCIM becomes available after compatible SSO setup is complete. Choose the default Workspace role deliberately: it is the starting access granted to a person provisioned through the identity provider.

AI processors

Protection → AI Processors shows every AI processor that can receive the Workspace’s data and its retention terms. A Workspace administrator can switch processors off, after seeing which features would stop, and choose the models features use. See Workspace AI processors.

Provider Policies

Protection → Provider Policies decides which rows of each Provider table the people in each Workspace role read. A Policy applies to every read of the table in the Workspace, a Parable’s Primary included, and to SQL tools. A Workspace administrator writes it as rules that give roles All rows, Rows where (SQL conditions) or Hidden, plus what Everyone else reads. See Provider Policies.

Access tokens

Protection → Access Tokens is where a member whose role can query the Provider Pools creates a personal access token for a SQL tool. A token works with SQL over Flight in this Workspace only and expires within a year. A Workspace administrator sees and revokes every member’s token. Someone who manages sign-in can turn tokens off, since a token does not go through the Workspace’s sign-in method. See API tokens, and Query Provider Pools with SQL to connect a SQL tool.

Who can change Protection

Protection settings affect everyone in the Workspace. Only a Workspace manager with the required access should configure or activate a login method, choose the default provisioning role, or regenerate a provisioning token. Someone who can use Ponder or view a Parable does not automatically receive permission to change sign-in settings. Workspace roles and responsibilities remain separate from the instructions a Persona or Skill provides. Only Workspace administrators change Provider Policies, and only a person changes someone’s roles: with Provider Policies, roles decide which rows each person reads. Agents can do neither. Only a person chooses the roles an invitation gives or sets the default role. An invitation an agent such as Ponder sends gives the default role, and a Workspace with no default role refuses it.

A safe change sequence

1

Keep the current method active

Confirm at least two Workspace managers can still use the current sign-in path before changing anything.
2

Configure the replacement

Enter only the values required by your identity provider. Keep client secrets and provisioning tokens in your approved secret manager.
3

Choose the default role

For SSO or SCIM, select the least-privileged role a newly provisioned person needs. Access can be expanded later through ordinary Workspace management.
4

Test the connection

Complete the provider sign-in test from an account that represents the intended audience. A saved configuration is not the same as a working one.
5

Activate and verify

Switch methods only after the test succeeds, then verify a second manager can sign in before ending the change window.

Keep recovery possible

  • Do not paste client secrets, certificates, bearer tokens, or one-time sign-in links into tickets, Ponder messages, or screenshots.
  • Record who owns the identity-provider application and who can recover it.
  • Coordinate certificate or client-secret rotation before expiry.
  • Treat a default-role change as an access change, not a copy or convenience setting.
  • If a test fails, leave the current method active, correct the provider setup, and test again.

Next

Read Configure login for the complete sign-in and Workspace setup flow, Workspace AI processors for where AI features send the Workspace’s data, and Provider Policies for which rows each role reads.