Skip to main content
Okta provides agent tools for identity troubleshooting and access management. Reference them in using @ mentions so your agent can answer access questions and fix common problems without a handoff.

​
Diagnose access problems

Most access tickets are a variant of “why can’t I get in”. The System Log holds the answer, and @Search Okta System Logs lets the agent read it and explain what happened in plain language.

Search system logs

Searches Okta System Log events for one person, so the agent can explain what happened instead of guessing. Covers sign-ins and lockouts, MFA enrollments and challenges, group membership changes, app assignments, policy evaluations, and admin actions.Tool name: @Search Okta System LogsInput fields:
  • userEmail (required) - filter logs to events where this user is the actor or target.
  • since - ISO 8601 start timestamp for the time range. Defaults to 24 hours ago.
  • until - ISO 8601 end timestamp for the time range.
  • eventType - filter by a single Okta event type, for example user.session.start or policy.evaluate_sign_on.
  • keyword - free-text search across event fields.
  • limit - maximum events to return (1-100). Defaults to 50.
Output data:
  • events - each event’s published timestamp, eventType, displayMessage, severity, actor, outcome, and target. The outcome.reason field usually names the exact cause of a failure.
  • totalCount - how many events came back.
Common use cases:
  • Explain a failed sign-in or a locked account
  • Find the MFA prompt a user started but never completed
  • Show when someone lost a group membership, and what they lost access to with it
  • Confirm whether a just-granted app assignment took effect
Example rule:

When someone reports they cannot sign in or an app is denying them access, use @Search Okta System Logs for their email over the last 24 hours before replying. Tell them what the log shows in plain language, for example a failed MFA challenge or a removed group membership. If the fix is a password or MFA reset, offer it. Only escalate if the log does not explain the failure.

This tool needs the okta.logs.read scope on your Okta app. If the scope is missing, the tool fails when the agent first calls it rather than at setup, so grant it before you write rules that depend on it.

​
Common event types

Useful values for the eventType filter when you want to narrow a search: Leave the filter empty to see everything for a person in the time range, which is usually the right first move.

​
Look up people and groups

Looks up a user by email and returns their profile and account status. Use it to confirm you have the right person before acting, or to check whether an account is active, suspended, or deprovisioned.Tool name: @Get Okta UserInput fields:
  • userEmail (required) - the user to look up.
Output data:
  • found - true when the user exists in Okta.
  • firstName, lastName, email - the user’s profile.
  • status - account status: ACTIVE, SUSPENDED, DEPROVISIONED, or similar Okta statuses.
Common use cases:
  • Confirm an account exists before resetting credentials or changing access
  • Check whether an account is locked or suspended before trying to unlock it
  • Verify the status of a newly created or recently deprovisioned account
Example rule:

Before resetting credentials or changing a user's access, use @Get Okta User to confirm the account exists and check its current status. If the status is DEPROVISIONED, tell the requester the account is gone and suggest activating it first.

Returns every Okta group a user belongs to. Useful for explaining what access someone currently has, and for spotting the group they are missing.Tool name: @List Okta User GroupsInput fields:
  • userEmail (required) - the user whose groups to list.
Output data:
  • groups - each group’s name and description.
  • totalCount - how many groups the user belongs to.
Common use cases:
  • Show a user which groups they are currently in
  • Identify the missing group when someone cannot access a resource
  • Audit group membership during offboarding
Example rule:

When someone asks what they have access to in Okta, use @List Okta User Groups to fetch their group membership and summarize it. If they mention a specific app or resource, explain which group would grant access and whether they are in it.

Checks whether a user is in a specific group. Call this before adding or removing someone so the agent does not report a change it did not make.Tool name: @Check Okta Group MembershipInput fields:
  • userEmail (required) - the user to check.
  • groupName (required) - the name of the Okta group.
Output data:
  • isMember - true when the user is in the group.
Common use cases:
  • Confirm membership before adding or removing someone to avoid a no-op error
  • Check whether a user is in the group that grants access to a specific resource
  • Verify a group change took effect
Example rule:

Before adding or removing a user from an Okta group, use @Check Okta Group Membership to confirm their current status. If they are already a member when adding, or already absent when removing, tell the requester nothing needs to change.

Sends an Okta Verify push notification to the user’s enrolled device and waits up to 60 seconds for them to approve or deny. Use it before a sensitive action to confirm the requester actually owns the account, especially when the request arrives over chat where anyone could claim to be anyone.Tool name: @Verify Identity with Okta Verify PushInput fields:
  • userEmail (required) - the user whose identity to verify. The push goes to their enrolled Okta Verify device.
Output data:
  • verified - true when the user approved the push.
  • status - approved, rejected, timed_out, no_factor, or user_not_found.
  • message - explanation of the outcome to relay to the requester.
Common use cases:
  • Confirm identity before a password or MFA reset when the request comes over chat
  • Gate sensitive group or app changes behind a second factor
  • Detect impersonation: a rejected status means the account owner denied the request
Example rule:

When someone asks you to reset their Okta password or MFA, tell them a push notification is coming, then use @Verify Identity with Okta Verify Push. If status is approved, proceed with the reset. If rejected, stop and tell them someone may be impersonating them. If timed_out, offer to try again. If no_factor, skip push verification and escalate to a human.

Tell the user a push is coming before calling this tool, because it blocks for up to 60 seconds while waiting. Members can verify themselves; only workspace administrators can send a verification push to someone else.

​
Fix credentials

Sends a forgot-password email to the user. This does not touch MFA. If the user also needs factors cleared, use @Reset Okta MFA in the same rule.Tool name: @Reset Okta PasswordInput fields:
  • userEmail (required) - the user to reset.
Common use cases:
  • Reset a forgotten password
  • Re-trigger the password reset email when the first one expired
  • Reset credentials before reactivating a suspended account
Example rule:

When someone says they forgot their Okta password, use @Reset Okta Password for their email and confirm that a reset email is on its way. If they also mention losing MFA access, use @Reset Okta MFA in the same response.

Clears every enrolled factor so the user can re-enroll on their next sign-in. Use it when someone lost a device or got a new phone. This does not change the user’s password.Tool name: @Reset Okta MFAInput fields:
  • userEmail (required) - the user to reset.
Common use cases:
  • Clear factors when a user gets a new phone or replaces a lost device
  • Remove a compromised factor before asking the user to re-enroll
  • Unblock a user who cannot pass a second factor after a device change
Example rule:

When someone says they have a new phone or lost their MFA device, use @Reset Okta MFA to clear their enrolled factors and tell them they will be prompted to re-enroll on their next sign-in. If they also forgot their password, use @Reset Okta Password in the same response.

Clears the locked-out status on an account locked after too many failed login attempts, so the user can sign in again. This does not change the password or MFA factors. Pair it with @Get Okta User to confirm the account is actually locked before unlocking.Tool name: @Unlock Okta UserInput fields:
  • userEmail (required) - the user to unlock.
Common use cases:
  • Unblock a user who hit the maximum failed login attempts
  • Unlock an account after a brute-force lockout
  • Restore access without changing credentials
Example rule:

When someone says their Okta account is locked, use @Get Okta User to confirm the status is LOCKED_OUT, then use @Unlock Okta User and tell them they can try signing in again. If the account is not locked, explain what you found instead.

Anyone can reset their own password or MFA. Only workspace admins can reset someone else’s. When a non-admin asks, the agent explains the limit and suggests the other person self-serve.

​
Manage access

Adds a user to a group by name. Check membership first with @Check Okta Group Membership to avoid an error when the user is already in the group.Tool name: @Add User to Okta GroupInput fields:
  • userEmail (required) - the user to add.
  • groupName (required) - the name of the Okta group.
Common use cases:
  • Grant access to a resource controlled by a group
  • Add a new hire to their team’s groups during onboarding
  • Restore group membership after an accidental removal
Example rule:

When someone requests group access in Okta, use @Check Okta Group Membership to confirm they are not already a member, then use @Add User to Okta Group. Confirm the change in the reply and tell them what access the group grants.

Removes a user from a group by name.Tool name: @Remove User from Okta GroupInput fields:
  • userEmail (required) - the user to remove.
  • groupName (required) - the name of the Okta group.
Common use cases:
  • Revoke access to a resource controlled by a group
  • Remove someone from a team’s groups when they change roles
  • Clean up group membership during offboarding
Example rule:

When someone's group access needs to be removed, use @Check Okta Group Membership to confirm they are in the group, then use @Remove User from Okta Group and confirm the removal in the reply.

Assigns a user to an application. If the application name is ambiguous, the tool returns the matching candidates so the agent can confirm which one was intended.Tool name: @Add User to Okta ApplicationInput fields:
  • userEmail (required) - the user to assign.
  • appName (required) - the name of the Okta application.
Output data:
  • appName - the application name as resolved by Okta.
  • exactMatch - true when the name matched exactly. When false, the tool returned candidates; confirm the resolved name with the requester before taking further action.
Common use cases:
  • Grant access to a SaaS app during onboarding
  • Assign a user to an app after they join a new team
  • Restore an app assignment removed during an access review
Example rule:

When someone requests access to an Okta application, use @Add User to Okta Application with the app name from the request. If exactMatch is false, confirm the resolved application name with the requester before proceeding.

Removes a user’s application assignment. If the application name is ambiguous, the tool returns matching candidates for the agent to confirm.Tool name: @Remove User from Okta ApplicationInput fields:
  • userEmail (required) - the user to remove.
  • appName (required) - the name of the Okta application.
Output data:
  • appName - the application name as resolved by Okta.
  • exactMatch - true when the name matched exactly. When false, confirm the resolved name with the requester before reporting the change as done.
Common use cases:
  • Revoke app access when someone changes teams or leaves a project
  • Remove an app assignment during offboarding
  • Clean up unused app assignments after an access review
Example rule:

When an admin asks to remove someone's access to an Okta application, use @Remove User from Okta Application. If exactMatch is false, confirm the resolved name with the requester before telling them the change is done.

Creates a new Okta group, with an optional description. If a group with the same name already exists, Okta returns an error.Tool name: @Create Okta GroupInput fields:
  • groupName (required) - the name for the new group.
  • description - what the group is for.
Output data:
  • groupId - the new group’s Okta ID.
  • groupName - the created group’s name.
Common use cases:
  • Create a group for a new team or project
  • Set up a group to control access to a new application
  • Provision a group as part of bulk onboarding
Example rule:

When someone asks to create an Okta group, confirm the name and purpose with them, then use @Create Okta Group. Reply with the group name and its Okta ID so the requester can reference it.

Deletes a group. Every member loses the membership immediately.
Deleting an Okta group removes every member’s membership immediately and cannot be undone. Confirm with the requester before running this tool.
Tool name: @Delete Okta GroupInput fields:
  • groupName (required) - the name of the group to delete.
Common use cases:
  • Remove a group after a project ends
  • Clean up unused groups during an access audit
  • Delete a group created by mistake
Example rule:

When a request comes in to delete an Okta group, repeat the group name back to the requester and ask them to confirm before running @Delete Okta Group.

Activates an account in STAGED or DEPROVISIONED status so the user can sign in. Use @Get Okta User first to check the current status.Tool name: @Activate Okta UserInput fields:
  • userEmail (required) - the user to activate.
Common use cases:
  • Activate a new account that was staged but never activated
  • Reactivate someone returning from leave whose account was deprovisioned
  • Restore access for a rehire
Example rule:

When a manager requests that a returning employee's Okta account be reactivated, use @Get Okta User to check the current status, then use @Activate Okta User and confirm the account is now active.

Deactivates a user account and revokes all active sessions.
Deactivating a user revokes all their sessions and prevents sign-in. Confirm with the requester before running this tool.
Tool name: @Deactivate Okta UserInput fields:
  • userEmail (required) - the user to deactivate.
Common use cases:
  • Suspend access at the end of an employee’s last day
  • Disable an account during a security investigation
  • Lock an account pending offboarding completion
Example rule:

When HR confirms an employee's last day, confirm the name and email with the requester, then use @Deactivate Okta User on their account and confirm the deactivation in the reply.

Creates a new user in Okta from an email, first name, and last name, with an optional secondary email. The user syncs back into Ravenna, and the tool returns the new Ravenna user ID so a follow-up rule can assign groups or applications right after creation.Tool name: @Create Okta UserInput fields:
  • email (required) - the primary email for the new user.
  • firstName (required) - the user’s first name.
  • lastName (required) - the user’s last name.
  • secondaryEmail - optional recovery email address.
Output data:
  • userId - the Ravenna user ID for the created account. Use it in follow-up calls to assign groups or apps.
Common use cases:
  • Create accounts for new hires from an onboarding request
  • Provision a contractor account quickly from a ticket
  • Create a user as the first step of a multi-step onboarding rule
Example rule:

When an onboarding ticket comes in, use @Create Okta User with the new hire's email, first name, and last name. After creation, use @Add User to Okta Group to assign their team groups and @Add User to Okta Application for each app they need. Reply with the new user's email and a summary of access granted.

Deactivates a user in Okta. If they are already deactivated, the tool deletes them instead. Use it during offboarding when you want the account gone rather than just suspended. Pair it with @Get Okta User first so the agent confirms the target exists and checks the current status.
If the account is already deactivated, this tool deletes it permanently. Use @Get Okta User to check the status before running this tool.
Tool name: @Remove Okta UserInput fields:
  • userEmail (required) - the user to remove.
Common use cases:
  • Complete offboarding by removing an account after its data has been transferred
  • Delete a duplicate or test account
  • Remove a deactivated account as part of a periodic access review
Example rule:

When an offboarding ticket is ready for final cleanup, use @Get Okta User to confirm the account status. If it is deactivated, ask the requester to confirm deletion, then use @Remove Okta User. If it is still active, use @Deactivate Okta User first, then offer to delete.

Sets a specific password on an Okta user. Use it when you have to hand a chosen credential to the user directly, for example after a bulk import or a synchronized reset with another system. For the common “user forgot their password” case, prefer @Reset Okta Password (email link) or @Generate Okta Password Reset Link (private Slack DM).Tool name: @Set Okta User PasswordInput fields:
  • userEmail (required) - the user.
  • password (required) - the new password to set.
Common use cases:
  • Set an initial password during a bulk user import
  • Synchronize a credential with another system that requires a specific value
  • Set a temporary password to hand to a user directly before they change it
Example rule:

When a bulk import is complete and users need initial passwords set, use @Set Okta User Password for each account, then notify the users privately. For individual forgotten-password requests, use @Reset Okta Password or @Generate Okta Password Reset Link instead.

A tool with no execution policy set runs without asking. When Copilot drafts a rule, it suggests Requires confirmation for write tools and Requires approval for delete tools, and you can change either per rule. See tool execution policies.

​
Setup

1

Connect Okta

Follow the client secret or private key setup guide.
2

Grant the log scope

Add okta.logs.read to your Okta app’s granted scopes. Without it, every other tool here still works and only log search fails.
3

Check the agent's tools

Open your agent’s settings and confirm the Okta tools appear under Tools. A disconnected integration shows a warning instead.
4

Write a rule

Reference the tools with @ mentions in a , then test it on a real access question.

​
Best practices

  • Search the log before escalating. A rule that reads the log first turns most “I can’t get in” tickets into an answer instead of a handoff.
  • Start without an event type filter. The unfiltered last 24 hours usually contains the cause. Narrow only when the result is noisy.
  • Verify identity before sensitive actions. Use @Verify Identity with Okta Verify Push before a password or MFA reset when the request comes over chat and you cannot confirm who is asking.
  • Check membership before changing it. Pair @Check Okta Group Membership with the add and remove tools so the agent reports what actually changed.
  • Name the person, not “you”. An admin often asks on someone else’s behalf, so rules should refer to the target user by name.
  • Gate the destructive tools. Put @Delete Okta Group, @Deactivate Okta User, and @Remove Okta User behind Requires approval in any rule an agent can reach on its own.
Learn more about configuring agents and Okta workflow actions
Last modified on September 29, 2026