Configure identity and access
This guide is for admins running Okta or Microsoft Entra ID. It covers giving people outside your engineering organization access to Grok Bot through your Cursor team, and letting members sign in to IdP-provisioned apps from the Bot's computer. For the broader security model, see Grok Bot for Teams and Enterprise.
Grok Bot uses your Cursor account, so there is no separate Grok Bot app in Okta or Entra ID. Everything in this guide happens on the Cursor app you already have. Cursor single sign-on is SAML 2.0 and works with Okta, Microsoft Entra, Google Workspace, and OneLogin; this guide details the two where device-trust policies most often need attention.
What you'll change
You'll make two changes, and they do different jobs:
- Assign the Cursor app so users outside your engineering organization can access Grok Bot through your Cursor team.
- Add an authentication rule so users can sign in to IdP-provisioned apps from the Bot's computer, which runs Linux and doesn't run device-trust agents.
Only the first change controls Grok Bot sign-in. The second never blocks it, and it doesn't apply to plugin sign-in, because plugin authentication doesn't go through the computer.
Before you start
Grok Bot access requires the user to be a member of your Cursor team. Members sign in with their Cursor account, so your existing Cursor SSO applies. With auto-provisioning on, a user joins the team at first sign-in; otherwise, provision the user, then have them sign in to Cursor for a seat or invite them from the Cursor dashboard.
If you use SCIM, provisioning is SCIM 2.0, available on the Enterprise plan, and deprovisioning is automatic: removing the user in your identity provider removes them from Cursor.
Assign the Cursor app
A user can sign in only if they have a Cursor account, and they get one through assignment to your existing Cursor SSO app, plus the SCIM app if you use SCIM. If Cursor is assigned only to engineering, everyone else fails with User is not assigned to this application, or their invite never completes. Don't create a second Grok Bot application; widen assignment on the Cursor app you already have.
- Go to Admin Console > Applications > Applications and open your existing Cursor app.
- Open Assignments and select Assign > Assign to Groups. To assign individuals instead, select Assign to People.
- Add every group that should get Grok Bot, not only engineering.
- If you use SCIM, assign the same groups to the Cursor SCIM app and push them. Users appear in Cursor only after they're assigned to the SCIM app.
- Confirm each group is also assigned to the SAML app. SCIM assignment without SSO assignment still blocks first sign-in.
If you use org-level identity in Cursor, map the directory group to the Grok Bot team after it syncs; see Organizations. Use separate groups for app assignment and Group Push.
The assignment works when:
- A user outside the original engineering assignment can open Grok Bot and complete Cursor SSO without User is not assigned to this application.
- With auto-provisioning on, that user appears on the Cursor team after first sign-in, without a manual invite.
- With auto-provisioning off, that user is on the team after they sign in to Cursor for a seat, or after you invite them from the dashboard.
Allow sign-in to IdP apps from the computer
Inside the hosted computer, members sign in to applications through your own identity provider in the browser, so your session policies govern those sessions. The computer runs Linux and isn't enrolled in MDM, and device-trust agents like Okta FastPass don't run on it. Any rule that requires FastPass, a registered or managed device, a compliant device, or a phishing-resistant factor only FastPass can satisfy fails in the computer browser.
Don't turn FastPass or device compliance off for the whole company. Add a higher-priority rule scoped to this unmanaged Linux session. This change covers only the IdP-provisioned apps the Bot opens in the computer browser; it isn't required for Grok Bot sign-in or for plugin sign-in.
These sign-in methods work in the computer browser:
- Password plus a second factor that works in a remote browser, such as Okta Verify push or an authenticator app.
- Passkeys stored in a password manager on the computer, installed with a Team Setup script.
Requiring managed devices for Grok Bot sign-in itself still works. Grok Bot uses your Cursor SSO, so a device-aware sign-in policy in your identity provider applies to it. That policy gates sign-in on the member's device, not the hosted computer.
In Okta Identity Engine, the computer matches the Other Desktop device platform; there is no Linux checkbox. Repeat these steps for each IdP-provisioned app the Bot opens in the computer browser.
- Go to Admin Console > Security > Authentication Policies and open the policy attached to the app. To find the policy, open Applications, then the app, then Sign On.
- Add a rule above the FastPass, managed-device, and deny catch-all rules. Name it so you can find it later, for example Grok Bot computer (Linux).
- In the IF conditions, scope the rule to a group. The Cursor-assigned group works if you don't want the rule company-wide.
- Set Device platform to Other Desktop and Device state to Any. Don't require Registered, Managed, or a device assurance policy that depends on FastPass.
- In the THEN conditions, set access to Allowed after successful authentication with Password + Another factor. Don't require phishing-resistant or hardware-protection factors.
- Save the rule and confirm it sits above the unmanaged-device deny catch-all.
If several apps share one FastPass-on-managed-devices policy, add the Linux rule to the shared policy and scope it by group, or give those apps their own policy. On Classic Engine, allow Other Desktop without requiring Device Trust = Trusted.
The change works when a user can sign in to IdP-provisioned apps from the Bot's computer without a FastPass or device-compliance error, plugin sign-in works as before, and laptop sign-ins are unchanged.
Revocation stays with you either way: revoking the user in your identity provider ends their in-computer application sessions, and an admin can terminate the member's computer at any time.
Limitations
- Okta FastPass doesn't run on Linux, so the Bot's computer can't satisfy FastPass or managed-device rules.
- The computer isn't enrolled in MDM by default.
- Group-based assignment in Entra ID requires P1 or P2 and doesn't include nested groups.
FAQ
No. Grok Bot sign-in uses the Cursor account, so your existing Cursor app controls access. Widen assignment on that app instead of creating a new one.
No. Plugin authentication doesn't go through the computer, so authentication rules for the computer browser don't apply to it.
No. Scope the new rule or policy to the Linux platform and the Cursor-assigned group, and laptop sign-ins keep your existing requirements.
Yes, they can no longer sign in through SSO. With SCIM, unassigning also removes them from Cursor automatically; without SCIM, remove them from the team in the dashboard.