--- name: jumpcloud-access-audit description: Trace JumpCloud entitlements — who can reach which SSO app or resource and through which groups, plus admin privilege and access-request posture for access reviews (SOC 2 / ISO 27001 style). Use when the user asks who has access to something, why someone has an app, or wants an entitlement report. For shadow IT / license waste use jumpcloud-saas-spend; for raw Directory Insights timelines use jumpcloud-audit-events; for alerts and health-rule triage use this skill’s alerts/health tools after entitlement scope is clear. license: MIT compatibility: Requires the JumpCloud MCP server (https://mcp.jumpcloud.com/v1) connected with an admin account or API key. metadata: author: jumpcloud version: "1.1.0" --- # Auditing access in JumpCloud Access is granted **indirectly**. A user is a member of a group; the group is bound to an SSO application or a policy. So "does Alice have production AWS?" is never answered from Alice's user record — it is answered by walking the graph. Every tool in this skill is read-only. Audit, then report; remediation is a separate, explicitly requested step. ## The two directions **Person → access.** What can this individual reach? ``` user_get → confirm identity user_group_membership → their groups (per group from user_groups_list) application_associations_list → apps each group grants devices_list → machines they can log into saas_application_accounts_list → SaaS accounts, including ones outside SSO ``` **Resource → people.** Who can reach this thing? ``` applications_list / application_get → the app application_associations_list → groups and users bound to it user_group_membership → expand each group to individuals ``` Always report the **path**, not just the verdict. "Alice has Salesforce via the `sales-team` group" tells someone what to change; "Alice has Salesforce" does not. Cross-cutting questions — "which users have access to more than five applications", "groups with no members", "applications nobody uses" — go to `search_api_execute` in a single call rather than an expansion loop. ## Privileged access Console administrators are a separate population from directory users, and they are the highest-value target in the tenant. - `admin_list` and `admin_get` — who holds console access and at what role. - `provider_admins_list` — MSP admins with reach across managed organizations. An admin here can be invisible in a single-org review. - `idp_policies_list` and `idp_policy_get` — conditional access rules. A strong MFA policy that exempts a group is a finding. Flag: admins without MFA, admins who are not employees, dormant admin accounts, and roles broader than the person's function needs. ## SSO applications and SaaS applications are different systems This is the single most common mistake in a JumpCloud audit. **An SSO application ID is not a SaaS application ID.** They are separate resources with separate identifiers, and passing one where the other is expected fails or, worse, silently returns the wrong app's data. To get SaaS account data for an SSO app, bridge them by name: 1. `application_get` on the SSO app → read its `name` / `displayLabel`. 2. `saas_applications_list` → find the SaaS app matching that name. 3. Use **that** SaaS app's ID with `saas_application_accounts_list`. Reading the results: - Each account has a **`loginMethods`** array. `"SSO"` present means the user has logged in via SSO; absent means they have not. Do not infer SSO usage from anything else. - SaaS apps carry a status: `NEWLY_DISCOVERED`, `APPROVED`, `UNAPPROVED`, `IGNORED`. `NEWLY_DISCOVERED` is the shadow-IT queue and is the thing worth surfacing. - Access restrictions (`WARNING`, `BLOCK`, `DISMISSIBLE_WARNING`) apply **only** when status is `UNAPPROVED`. A restriction set on an app in any other status does nothing. - A SaaS app's **`owner` is a JumpCloud end user, not an administrator.** Resolve owners with `users_list` using `searchTerm`. Never use `admin_list` for this. For a complete picture of SSO login activity, read both sides: `di_events_get` with service `sso` shows login attempts, while SaaS account data shows provisioned access and usage. Neither alone is the whole story — DI can show a login for an account that SaaS management doesn't track, and vice versa. The **jumpcloud-saas-spend** skill covers the review workflow, license waste, and the full `saas_application_review` contract. The **jumpcloud-audit-events** skill covers building an incident timeline from `di_events_get`. ## Dormant, orphaned, and wasted | Question | Where to look | |---|---| | Accounts never activated or never logged in | `search_api_execute`, then `di_events_get` to confirm | | Suspended users still holding licenses | `users_list` + `saas_application_accounts_list` | | SaaS accounts with no matching directory user | `saas_application_accounts_list` — orphans survive offboarding | | Licenses paid for and unused | `saas_licenses_list`, `saas_application_licenses_list` | | Shadow IT | `saas_applications_list` — discovered apps not yet reviewed | | Empty or unbound groups | `user_groups_list` + `user_group_membership` | | Pending entitlement requests | `access_requests_list`, `access_request_get` | Orphaned SaaS accounts are the classic offboarding failure: the directory account is gone, so the person is invisible in a user-centric review, but the SaaS account still authenticates. Check from the SaaS side, not the directory side. ## Investigating activity `di_events_get` is the audit trail — logins, admin actions, directory changes. Use it to establish what actually happened rather than what the current state implies. Anchor every investigation to a window and a subject. Pull the events, build a timeline, and separate what the log shows from what you infer. A burst of failed logins followed by a success is a pattern worth naming; it is not, by itself, proof of compromise, and you should say which one you are asserting. Corroborate before concluding: `alerts_list` and `alert_occurrences` for what the platform already flagged, `health_rules_list` for the detections configured at all. A quiet alert log may mean nothing happened, or that nothing was watching. ## Producing a review For SOC 2, ISO 27001, or a periodic user access review, work in this order: 1. **Scope it.** Which applications, which population, which period. Write the scope down in the output — an access review without a stated scope is not evidence. 2. **Enumerate.** For each in-scope application, `application_associations_list`, then expand groups to named individuals. 3. **Cross-reference.** Filter the roster against active users. Anyone entitled but suspended, deleted, or dormant is a finding. 4. **Cover the privileged tier separately.** Admins and provider admins get their own section; reviewers look for it. 5. **Report with timestamps and paths.** Every row should say who, what, via which group, and as of when. Note explicitly what you could not check — an org may lack the SaaS management feature, and a silent gap reads as a clean result. Present findings ranked by exposure: privileged access first, then external or orphaned accounts, then dormancy and license waste. Propose remediation but do not perform it — the `jumpcloud-user-lifecycle` skill covers revocation once the user decides to act.