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.
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: a SQL token for a SQL tool, or an MCP token for an MCP host such as Claude Code. A SQL token works with SQL over Flight only. An MCP token reads the Workspace through the Workspace API and cannot change anything. Each works 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. An MCP token needs one more decision. An agent outside Parable sends what it reads to its own model provider, which Workspace AI processors does not cover. Allow external agents, on the same page, is off until someone who manages sign-in turns it on. While it is off, nobody can create an MCP token, and every MCP token and every sign-in from an agent is refused. Turning it off revokes nothing. Once it is back on, MCP tokens work again with no reconnect, and a person who signed in from an agent may need to sign in again. SQL tokens are not affected. See API tokens, and Query Provider Pools with SQL to connect a SQL tool.Macs
Protection → Macs lists the Macs that send Parable Pulse activity to the Workspace: each Mac’s name, the person it enrolled as, when it enrolled, and whether it is active or revoked. A Workspace administrator revokes a lost or retired Mac there, and Parable refuses that Mac’s data within a minute. A revoke cannot be undone. A member does not see this page. A member stops their own Mac with Remove this Mac from the Workspace… in the Pulse menubar (Pulse Primer).Pros Access
Protection → Pros Access lists every request a Parable employee made to enter the Workspace. A second Parable employee approves each request, or the Parable employee auto-approves it and the named approver gets an email at once. The access ends after at most 3 weeks. A Parable Administrator enters without a request. The list shows who asked, the purpose, the approver, the times and whether the access read Provider data. Nobody can change the list. See Pros Access.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 Power 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.