Configure Okta or Entra ID for Grok Bot identity and access

Grok Bot uses the member’s Cursor account. There is no separate Grok Bot app in Okta or Microsoft Entra ID — widen assignment and auth rules on the Cursor SSO app you already have. Official guide: Configure identity and access.

Cursor SSO is SAML 2.0 (Okta, Microsoft Entra, Google Workspace, OneLogin). This how-to details Okta and Entra, where device-trust policies most often need attention for the Bot’s Linux computer.

Two changes, two jobs

Change	What it controls
Assign the Cursor app	Who can sign in to Grok Bot through your Cursor team
Authentication rule for the computer browser	Who can sign in to IdP-provisioned apps inside the Bot’s Linux computer

Only the first change controls Grok Bot sign-in. The second never blocks Grok Bot sign-in, and it does not apply to plugin sign-in (plugins do not authenticate through the computer).

Before you start

• The user must be a member of your Cursor team. With auto-provisioning on, they join at first sign-in; otherwise provision, then have them sign in for a seat or invite them from the dashboard.
• SCIM (Enterprise): SCIM 2.0 provisioning/deprovisioning. Removing the user in the IdP removes them from Cursor.
• Do not create a second “Grok Bot” application.

Assign the Cursor app (Okta)

1. Admin Console → Applications → Applications → open your existing Cursor app.
2. Assignments → Assign → Assign to Groups (or Assign to People).
3. Add every group that should get Grok Bot — not only engineering.
4. If you use SCIM, assign the same groups to the Cursor SCIM app and push them. Users appear in Cursor only after SCIM assignment.
5. Confirm each group is also assigned to the SAML app. SCIM 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. Use separate groups for app assignment and Group Push.

Assign the Cursor app (Microsoft Entra ID)

1. Microsoft Entra admin center → Enterprise applications → open your existing Cursor enterprise app.
2. Users and groups → Add user/group.
3. Add every group that should get Grok Bot.
4. If you use SCIM, assign the same groups to the Cursor provisioning app, turn provisioning on, and scope to assigned users and groups.
5. Confirm the assignment grants SSO rather than report-only access.

Group-based assignment needs Entra ID P1 or P2. Nested groups are not included. Unassigning blocks SSO; with SCIM it also removes the user from Cursor.

Done when: a user outside the original engineering assignment opens Grok Bot and completes Cursor SSO without “User is not assigned to this application”; with auto-provisioning on they appear on the team after first sign-in.

Allow IdP app sign-in from the Bot computer

Inside the hosted computer, members sign in to company apps in the browser. The computer runs Linux, is not MDM-enrolled by default, and device-trust agents (Okta FastPass and similar) do not run there. Rules that require FastPass, a registered/managed/compliant device, or a phishing-resistant factor only FastPass can satisfy fail in that browser.

Do not turn FastPass or device compliance off company-wide. Add a higher-priority rule scoped to this unmanaged Linux session. Requiring managed devices for Grok Bot sign-in itself still works — that gates the member’s device via Cursor SSO, not the hosted computer.

Methods that work in the computer browser: password + a second factor that works in a remote browser (Okta Verify push, authenticator app); passkeys stored in a password manager on the computer (install via Team Setup).

Okta rule

In Okta Identity Engine the computer matches Other Desktop (no Linux checkbox). Repeat per IdP-provisioned app the Bot opens in the computer browser.

1. Admin Console → Security → Authentication Policies → open the policy on the app (Applications → app → Sign On).
2. Add a rule above FastPass, managed-device, and deny catch-all rules. Name it clearly (for example Grok Bot computer (Linux)).
3. IF: scope to a group (Cursor-assigned group if you do not want company-wide).
4. Device platform Other Desktop, Device state Any. Do not require Registered, Managed, or a device-assurance policy that depends on FastPass.
5. THEN: Allowed after successful authentication with Password + Another factor. Do not require phishing-resistant or hardware-protection factors.
6. Save and confirm the rule sits above the unmanaged-device deny catch-all.

Shared FastPass-on-managed-devices policies: add the Linux rule to the shared policy and scope by group, or give those apps their own policy. Classic Engine: allow Other Desktop without Device Trust = Trusted.

Entra Conditional Access

Blocking grants: compliant device, hybrid joined device, phishing-resistant strength only a platform/managed passkey can meet, approved client app / app protection.

1. Protection → Conditional Access → Policies.
2. Find every policy that applies those grants to the IdP apps the Bot needs.
3. Leave those on. Add a higher-priority policy for Grok Bot users on Linux, or exclude them from the blocking policies.
4. Users: Cursor-assigned group. Cloud apps: the IdP apps they must open on the computer (All resources only if you accept that scope).
5. Device platforms: include Linux, exclude Windows and macOS.
6. Grant: Require multifactor authentication only.
7. Start in report-only, then turn on. On existing compliant-device policies, exclude the group or exclude Linux.

For phishing resistance without a managed device, use an authentication strength a synced passkey can satisfy, and test from the computer before enforcing.

Done when: a user signs in to IdP-provisioned apps from the Bot’s computer without FastPass/device-compliance errors; plugin sign-in still works; laptop sign-ins are unchanged.

Revocation

Revoke the user in your identity provider to end in-computer application sessions. Organization admins can also terminate the member’s computer from the dashboard (Enterprise).

Pitfalls

• Creating a separate Grok Bot IdP app — use the existing Cursor app.
• SCIM assignment without SAML/SSO assignment — first sign-in still fails.
• Turning off FastPass org-wide instead of a scoped Linux / Other Desktop rule.
• Expecting the computer rule to fix plugin auth failures — plugins do not use the computer browser path.