# Audits

- Link: https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/audits/
- Published: 2026-08-24T01:47:12+00:00
- Author: Don Bowman

1. [Home](https://www.agilicus.com/)
 2. [Agilicus AnyX Administrative Web Interface](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/)
 3. [Access](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/)
 4. Audits

![79e64f50-featured-anyx-admin-accessaudits](https://www.agilicus.com/www/79e64f50-
featured-anyx-admin-accessaudits.png)

## Audits

[CONTACT](https://www.agilicus.com/contact-us/)

The **User Audit** page (route `/user-audits`) searches a single user’s audit records
to diagnose problems or assess the damage from a breach.

![Audits search](https://www.agilicus.com/www/0b9b2e94-audits-search-empty.png)

## Purpose

Audit records are used to diagnose problems a user may be having, or the security
damage caused by a breach. The User Audit page centres on one person: you search
for a user by email, and the page assembles everything relevant to them: the applications
and resources they can access, their authentication preferences, their sessions,
and their audit log entries. It is also where you can update a user’s multi-factor
authentication information.

## Why use it

 * Diagnose why a user cannot access a resource: review what they are authorised
   for and what the audit log records.
 * Investigate a breach: see what a user could reach and when they were active.
 * Verify the access a user currently has across applications and resources.
 * Review authentication preferences and reset multi-factor authentication enrollment
   or deadlines.

## When to use it

 * When a user reports a problem and you need the record of what happened (see [Audit and diagnostics](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/audit-and-diagnostics/)).
 * During an incident response, to reconstruct a user’s access and activity.
 * When onboarding a user’s replacement, to see what access needs to be replicated.
 * After a security review, to reset a user’s multi-factor authentication preferences.

## What the Access audit records

The Access audit records actions: who did what, to which resource, when, from where,
and whether it was allowed. Each record carries the target resource name and type,
the resource id, the action, the source address, the token and the session. When
the session passes through a connector, the record identifies the connector as the
source.

This is the audit for desktop and Secure Shell sessions. A desktop launched from
Profile does not have its own OpenID Connect client, so it does not appear in the
Authentication audit. Profile asks the Applications service for a client configuration,
Applications mints a token scoped to that one resource, and the connector records
the session here when the connection closes. The same pattern applies to Secure 
Shell, database and file share resources.

### Authentication audit and Access audit

Use the Authentication audit for identity: who signed in, how they proved the identity,
and whether the sign-in succeeded. Use the Access audit for resource activity: who
reached which resource, and whether it was allowed. The two records share the token
and session identifiers, so you can move from a connection back to the sign-in that
created it.

 * Filter on the target resource type to isolate desktop, Secure Shell, database
   or file share activity.
 * Filter on the connector to get everything behind one connector.
 * Use the token and session identifiers to correlate a connection with the Authentication
   audit.

Both audits are available through the API: /v1/audits for access records and /v1/
auth_audits for authentication records. Audit destinations can stream both to a 
SIEM.

**Prerequisite**: permission to view audits (an owner or administrator role).

## How to use it

 1. Open **Access > Audits** from the left navigation.
 2. Type a user’s **User Email** into the search field.

![Audits search](https://www.agilicus.com/www/0b9b2e94-audits-search-empty.png)

 1. Select **SEARCH**. The page loads the user’s record: their name and email, a **
    VIEW PERMISSION GRAPH** button, and a set of sections.

![User audit results](https://www.agilicus.com/www/9fd06fbb-audits-user-search.png)

### Reading the results

 * **Application Access Overview** lists each application the user can access and
   the role they hold. The table shows one column per application.

![Application access overview](https://www.agilicus.com/www/0b9b2e94-audits-light-
user.png)

 * **Resource Access Overview** lists the resources the user can reach and at what
   level.
 * **Permission Graph** shows a visual map of the user’s permissions.
 * **Authentication Preferences** shows multi-factor authentication state and the
   enrollment deadline, with **RESET MFA PREFERENCES**, **RESET** (deadline), and**
   UPDATE RESULTS** actions.
 * **Sessions Audit** lists the user’s sessions.
 * **Logs** shows the raw audit log entries for the user, with search and pagination.

### Updating multi-factor authentication

In the **Authentication Preferences** section you can reset a user’s enrolled multi-
factor authentication methods, reset their enrollment deadline, or update the shown
results after changes. These are immediate, so confirm the user understands they
will need to re-enrol at next sign-in.

## Fields and controls reference

| Control | Purpose | Required | Default | Valid values | Notes | 
| User Email | The user to search for | Yes | n/a | A user’s email address | Autocomplete as you type | 
| SEARCH | Runs the search | n/a | n/a | n/a |  | 
| VIEW PERMISSION GRAPH | Opens the permission graph view | n/a | n/a | n/a |  | 
| RESET MFA PREFERENCES | Clears the user’s multi-factor authentication enrollment | n/a | n/a | n/a | The user re-enrols at next sign-in | 
| Enrollment deadline | The date by which the user must enrol | No | n/a | A date | Reset or update from this section | 
| UPDATE RESULTS | Refreshes the displayed sections | n/a | n/a | n/a |  |

## Dialogs and popups

 * **Confirmation dialogs**: resetting multi-factor authentication preferences confirms
   before acting.

## Configuration versus diagnostics versus confirmation

 * **Configuration**: updating a user’s multi-factor authentication preferences 
   and enrollment deadline.
 * **Diagnostics**: the access overviews, permission graph, sessions audit, and 
   logs are read-only records of the user’s state and activity.
 * **Confirmation**: resetting multi-factor authentication is immediate and affects
   the user’s next sign-in. Confirm before applying.

## Pagination and async behaviour

 * The application, resource, sessions, and log tables page at **25 rows per page**.
 * Searching a user with a large audit history can take some seconds to assemble.
   After resetting multi-factor authentication or updating the deadline, select **
   UPDATE RESULTS** or reload to confirm.

## Troubleshooting

 * **No results**: confirm the email is spelled correctly and the user exists in
   the organisation (see [Users](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/users/)).
 * **The user cannot sign in**: check the [authentication audit](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/organisation/authentication-audit/)
   for sign-in failures, then review the sessions audit here for stale sessions.
   Revoke sessions from the [Users](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/users/)
   page if needed.
 * **A permission is missing**: review the application and resource access overviews,
   then adjust on [Application permissions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/application-permissions/)
   or [Resource permissions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/resource-permissions/).
 * **Multi-factor authentication is not working**: reset the user’s preferences 
   here and ask them to re-enrol.

## See also

 * [Audit and diagnostics](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/audit-and-diagnostics/)
 * [Authentication audit](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/organisation/authentication-audit/)
 * [Sessions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/organisation/sessions/)
 * [Audit subsystem](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/organisation/audit-subsystem/)
 * [Users](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/users/)
 * [Application permissions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/application-permissions/)
 * [Resource permissions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/resource-permissions/)

## Web guide

 * [Diagnosing user issues with audits](https://www.agilicus.com/diagnosing-user-issues-with-audits)
 * [Authentication audit](https://www.agilicus.com/product-guide/authentication-audit)
 * [A user cannot log in, how can I fix this?](https://www.agilicus.com/a-user-cant-log-in-how-can-i-fix-this)