1a819e2b featured anyx admin conceptsaudit and diagnostics

Audit and diagnostics

CONTACT

Agilicus AnyX records what happens on your platform so you can answer the questions that matter for security and compliance: who accessed what, when, from where, and was it allowed? Audit data and diagnostics are separate concerns with different screens, and this page explains both.

What is recorded

Every significant event is recorded:

  • Authentication events: sign-in attempts, successes, failures, and multi-factor authentication events. See Authentication audit.
  • Authorisation decisions: who was allowed or denied access to which resource, and why (for example a policy rule). See Access audits.
  • Sessions: active and historical user sessions, including token-based sessions. See Sessions.
  • Resource activity: requests made through a resource, including HTTP requests. See Application diagnose and Metrics.
%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
flowchart LR
    AUTH[Authentication events]
    AUTHZ[Authorisation decisions]
    SESS[Sessions]
    RES[Resource activity]
    AUTH --> AUD[Audit subsystem]
    AUTHZ --> AUD
    SESS --> AUD
    RES --> AUD
    AUD --> DEST[Audit destinations]
    AUD --> VIEW[Portal views and searches]
    DEST --> SIEM[SIEM / log service]

The audit subsystem

The audit subsystem is the engine that collects and stores audit events. The portal’s Audit subsystem page shows the health and statistics of this engine.

Audit destinations

Audit events can be forwarded to destinations outside the portal, for example a SIEM service. This keeps a copy of your audit trail in your own logging pipeline and lets you correlate with other sources. See Audit destinations and the web guide’s SIEM event forwarding.

The recommended pattern for sending logs to a SIEM is to consume logs locally, convert them to a secure format (JSON over HTTPS), and forward them through an outbound-only connector. Raw, unencrypted protocols must never be routed directly to the internet. See Sending logs to a SIEM target.

Diagnostics

Diagnostics are the read-only views and counters that help you troubleshoot. They are deliberately separate from configuration:

  • Application diagnose: inspect a live application’s requests, headers, and responses to see exactly what a user or a service is sending and receiving. See Applications.
  • Connector diagnostics: connector health counters (connection state, throughput, errors). See Connectors.
  • Authentication audit: search and review sign-in events for a user, including failures.
  • User audits: review everything a specific user has done.
  • Metrics: aggregated usage such as top users and active users. See Metrics.
%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
flowchart TD
    D[Diagnostics]
    D --> A[Application diagnose]
    D --> C[Connector counters]
    D --> AU[Authentication audit]
    D --> UA[User audits]
    D --> M[Metrics]

Using audit for troubleshooting

A common troubleshooting pattern:

  1. Ask the user what they were doing (which resource, which time).
  2. Open the authentication audit to confirm they signed in.
  3. Open user audits to see whether access was allowed or denied and why.
  4. Open application diagnose or connector diagnostics to inspect the traffic level.
  5. Review sessions to see active sessions.

Each screen explains how to search, filter, and page through the results.

See also

Web guide