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 Okta 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 LogsFilters:
  • User email (required) - returns events where this person was the actor or the target
  • Since and Until - the time range to search. Defaults to the last 24 hours
  • Event type - a single Okta event type, for example user.session.start or policy.evaluate_sign_on
  • Keyword - free-text search across event fields
  • Limit - how many events to return, up to 100
What the agent learns: each event’s timestamp, type, severity, actor, target, and outcome, including the failure reason when Okta gives one. That reason is usually the whole answer, so the agent can name the cause rather than describing the symptom.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
  • Reconstruct the sequence of events around an incident
Example rule:

Okta sign-in troubleshooting rule

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 Event type 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, including name and account status. Use it to confirm you have the right person, or to check whether an account is active, suspended, or deprovisioned.Tool name: @Get Okta User
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 Groups
Checks whether a user is in a specific group. Have the agent call this before adding or removing someone, so it does not report a change it did not make.Tool name: @Check Okta Group Membership

​
Fix credentials

Sends a forgot-password email to the user. This does not touch MFA.Tool name: @Reset Okta Password
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 their password.Tool name: @Reset Okta MFA
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.Tool name: @Add User to Okta Group
Removes a user from a group by name.Tool name: @Remove User from Okta Group
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 you meant.Tool name: @Add User to Okta Application
Removes a user’s application assignment.Tool name: @Remove User from Okta Application
Creates a group, with an optional description.Tool name: @Create Okta Group
Deletes a group. Every member loses the membership, so the agent confirms before running it.Tool name: @Delete Okta Group
Activates a deactivated account, for example when someone returns from leave.Tool name: @Activate Okta User
Deactivates an account, removing the person’s access.Tool name: @Deactivate Okta User
Write and delete tools default to Requires confirmation, and you can raise any of them to Requires approval 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.
  • 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 and @Deactivate 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 August 26, 2026