Okta identity inventory¶
Okta supplies identity and group context so Venturi can map AI usage to the right person, team, and admin review queue without storing prompt or completion content.
Release state
This is a Phase-1 connector setup guide. It covers read-only identity inventory setup and validation. SCIM provisioning and SSO administration remain documented separately in SCIM provisioning and Single sign-on.
Required access¶
Create an Okta API token or OAuth service app with read-only access to:
| Scope | Purpose |
|---|---|
okta.users.read |
Read user profile, status, and lifecycle metadata for attribution context. |
okta.groups.read |
Read group membership and team context. |
okta.apps.read |
Optional; helps map application assignments when your Okta policy model uses app groups. |
Do not grant write scopes. Venturi does not need user, group, policy, or app mutation permissions.
Setup¶
- In Okta, create a dedicated service integration for Venturi.
- Limit the integration to read-only user and group scopes.
- Record the Okta org URL, client identifier, and token material in your tenant's secrets flow.
- In Venturi, open Administration -> Connectors -> Okta.
- Enter the org URL and token reference, then run Test connection.
- Confirm the first sync shows users, groups, and a last-sync timestamp.
Verification¶
After setup, verify:
- user and group counts are non-zero and match your expected tenant scope;
- suspended or deactivated users are marked as inactive, not deleted from historical attribution records;
- the connector appears as read-only in the connector inventory;
- the Coverage & unknowns page no longer lists identity inventory as a would-close source for connected teams.
Rotation and offboarding¶
Rotate the Okta token on the same cadence as your other read-only SaaS connectors. If you remove the connector, existing historical attribution remains auditable, but new workforce joins, moves, and leaves stop updating until the connector is restored.