Connectors / Okta
What Deixic does with Okta.
Read and act
Help suspend or deactivate accounts and remove assigned admin roles.
How Deixic helps with Okta.
- Read information
- Review users, groups and apps from Okta as evidence and to check state.
- Choose the actions
- Deixic supports actions on users and roles. Grant only the tools and permissions the task needs.
- Keep your decisions
- Deixic checks your policy before a change; sensitive changes wait for a named approver. The action record keeps the decision and result.
6 of 6 changing operations require approval. See how approvals work.
Example workflow
Review admin roles and what a departed user still holds
Look up this Okta user. List their admin roles, group memberships, and application assignments, and read the recent log events for the account. Return the access that should be gone after termination.
- Take the termination from the HR system and resolve the Okta user by ID with the user lookup. Confirm the status the lookup returns.
- Read the user's admin roles, group memberships, and application assignments. Keep access held through a group separate from direct assignments, so removing the group is not mistaken for removing the user.
- Read the system log for the account to see recent sign-ins and changes. For CC6.2, return the remaining access with identifiers.
- Prepare the supported suspension, deactivation, session clearing, or admin-role removal for a named approver. After approval, run the selected changes and read the same user and role assignments again. Keep the approval and observed result with the job.
Check before you continue: A user record stays in Okta after the account is closed. Check the status field, not the presence of the record. Group rules can re-add a user to a group after a manual removal.
Provider reference: Okta user lifecycle APIAssign roles to a user
Use your existing agent with Deixic. Calls you route through Deixic follow your access and approval policy.
Provider access
Supported Okta reads and actions.
Choose the reads and actions your task needs. Your connection’s permissions and your agent’s access determine what it can use.
Read data
- Users Read
- Groups Read
- Apps Read
- Logs Read
- Factors Read
Actions
- Users Write
- Roles Write
Permissions
Choose the access for Okta.
Choose a key for the intended project or account, keep test and production credentials distinct, and check any resource restrictions before the first task.
Find Okta in the appManage connected accounts
- Connection
- API key
- Supported operations
- Read and act
- Reads
- 5
- Actions
- 2
- Provider permissions
- Grant only the permissions needed for the task.
What you need to connect
- Okta org domain
- API token
Deixic checks calls routed through its gateway and requests approval when your policy requires it.
Reference and troubleshooting
Okta operation reference, troubleshooting, and questionsSOC 2 for Okta
Guides for work in Okta
An Okta agent should explain the access before it changes anything
Design an Okta agent workflow that resolves the user, traces group and application assignments, and separates an access investigation from an identity change.
How do MCP permissions work when agents use company tools?
Answers to MCP authentication, per-tool authorization, user identity, token passthrough, and approval questions for agents using company systems.
Connectors for related work
Tell us what you need from Okta.
Bring one task. We’ll show you the access it needs and how Deixic helps.
Request early access