> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent tools

> Use Okta agent tools in Ravenna rules to search the System Log, diagnose access failures, verify identity, reset passwords and MFA, and manage groups and app assignments.

Okta provides agent tools for identity troubleshooting and access management. Reference them in <Tooltip headline="Agent rules" tip="Natural language instructions defining agent behavior" cta="Learn about agent rules" href="/documentation/automate/agents/configure#rules">agent rules</Tooltip> 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.

<AccordionGroup>
  <Accordion title="Search system logs" defaultOpen>
    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 Logs`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>

    <Note>
      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.
    </Note>
  </Accordion>
</AccordionGroup>

### Common event types

Useful values for the `eventType` filter when you want to narrow a search:

| Event type | What it tells you |
| - | - |
| `user.session.start` | A sign-in attempt, successful or failed |
| `user.account.lock` | The account was locked after repeated failures |
| `user.mfa.factor.activate` | Someone finished enrolling a second factor |
| `user.authentication.auth_via_mfa` | An MFA challenge was passed or failed |
| `policy.evaluate_sign_on` | A sign-on policy allowed or denied the attempt |
| `group.user_membership.add` | Someone was added to a group |
| `group.user_membership.remove` | Someone lost a group membership, and the access attached to it |
| `application.user_membership.add` | An app assignment was granted |
| `app.generic.unauth_app_access_attempt` | Someone tried to open an app they are not assigned to |

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

<AccordionGroup>
  <Accordion title="Get user">
    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 User`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="List user groups">
    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`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Check group membership">
    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 Membership`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Verify identity with Okta Verify push">
    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 Push`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>

    <Note>
      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.
    </Note>
  </Accordion>
</AccordionGroup>

***

## Fix credentials

<AccordionGroup>
  <Accordion title="Reset password">
    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 Password`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Reset MFA">
    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 MFA`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Unlock user">
    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 User`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Generate password reset link">
    Creates a one-time reset link and delivers it to the target user by private Slack DM, so the link never appears in a shared ticket. If the DM cannot be delivered, the agent directs the user to the "Forgot Password" link on their Okta login page instead.

    **Tool name:** `@Generate Okta Password Reset Link`

    **Input fields:**

    * `userEmail` (required) - the user to generate a link for.

    **Common use cases:**

    * Send a reset link directly to a user without putting it in the ticket
    * Reset a password for a user who cannot receive the standard reset email
    * Give an admin a way to hand someone a reset link privately

    **Example rule:**

    <Prompt description="When someone needs an Okta password reset link, use @Generate Okta Password Reset Link for their email. The link is sent by private Slack DM. Refer to the recipient by name or email in your reply, not as 'you', since you may be helping an admin reset someone else's account.">
      When someone needs an Okta password reset link, use
      @Generate Okta Password Reset Link for their email. The link is
      sent by private Slack DM. Refer to the recipient by name or email
      in your reply, not as "you", since you may be helping an admin
      reset someone else's account.
    </Prompt>
  </Accordion>
</AccordionGroup>

<Note>
  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.
</Note>

***

## Manage access

<AccordionGroup>
  <Accordion title="Add user to group">
    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 Group`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Remove user from group">
    Removes a user from a group by name.

    **Tool name:** `@Remove User from Okta Group`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Add user to application">
    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 Application`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Remove user from application">
    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 Application`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Create group">
    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 Group`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Delete group">
    Deletes a group. Every member loses the membership immediately.

    <Warning>
      Deleting an Okta group removes every member's membership immediately and cannot be undone. Confirm with the requester before running this tool.
    </Warning>

    **Tool name:** `@Delete Okta Group`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Activate user">
    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 User`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Deactivate user">
    Deactivates a user account and revokes all active sessions.

    <Warning>
      Deactivating a user revokes all their sessions and prevents sign-in. Confirm with the requester before running this tool.
    </Warning>

    **Tool name:** `@Deactivate Okta User`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Create user">
    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 User`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Remove user">
    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.

    <Warning>
      If the account is already deactivated, this tool deletes it permanently. Use @Get Okta User to check the status before running this tool.
    </Warning>

    **Tool name:** `@Remove Okta User`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>

  <Accordion title="Set user password">
    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 Password`

    **Input 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:**

    <Prompt description="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.">
      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.
    </Prompt>
  </Accordion>
</AccordionGroup>

<Callout icon="shield" color="#6B7280">
  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](/documentation/automate/agents/configure#tool-execution-policies).
</Callout>

***

## Setup

<Steps>
  <Step title="Connect Okta">
    Follow the [client secret](/integrations/okta/setup/client-secret) or [private key](/integrations/okta/setup/private-key) setup guide.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Write a rule">
    Reference the tools with @ mentions in a <Tooltip headline="Agent rules" tip="Natural language instructions defining agent behavior" cta="Learn about agent rules" href="/documentation/automate/agents/configure#rules">rule</Tooltip>, then test it on a real access question.
  </Step>
</Steps>

***

## 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.

<Callout icon="link" color="#6B7280">
  Learn more about [configuring agents](/documentation/automate/agents/configure) and [Okta workflow actions](/integrations/okta/workflows)
</Callout>


## Related topics

- [Agent tools](/integrations/fleet/agent-tools.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.