Audit Log

The audit log is the record of who did what in your tenant. It is the page you go to when a number moved and nobody knows why, and it is the evidence you hand to an auditor asking how access is controlled.

Viewing the whole tenant’s activity needs audit:read. A narrower audit:self permission exists that shows only a person’s own activity, which is how you give someone accountability without giving them visibility into everyone else. Export needs audit:export.

What gets recorded

Around sixty event types across authentication, user management, roles and permissions, data access, security, configuration, agents, scans, compliance, assessments, email, cloud accounts, and notifications.

Every mutating endpoint records an event with the actor, the action, the target type and identifier, a description, and old and new values where they apply.

Secrets are never written to the audit log. Passwords, API keys, enrollment tokens, and credentials are sanitised out. An audit entry tells you a credential was rotated, never what it was.

Two logging paths, and the auto tag

This is the detail most people miss, and it changes how much you should trust an entry’s detail.

An auto badge means middleware caught it, not that a feature logged it

Argus records audit events two ways. Features log explicitly, with rich context: what changed, the old and new values, the target’s name. Separately, middleware logs every mutating request as a safety net, so nothing can go entirely unrecorded even if a code path forgets to log.

Middleware-caught entries are tagged auto in the Action column. They prove something happened and who did it, but they carry less context than an explicit entry.

Practically: if you are investigating and an entry is tagged auto, do not expect a full before and after. The tag is there so you know the difference between “we captured the details” and “we caught the request”, rather than silently presenting thin data as complete.

If an entry does not carry the detail you need to answer an audit question, contact support with the timestamp and the action. We can often reconstruct the surrounding context.

The volume summary

Across the top, event volume for 30 days, 7 days, and 24 hours, each with a trend indicator, plus:

• Active users in the window, and the most active user with their count and trend.
• Success rate and the number of failed events, with the trend colour inverted so a rise in failures reads as bad.
• High and critical severity event count with its trend, and the top security action.

The pair to watch is failed events and success rate. A cluster of failures usually means either a permission problem someone is repeatedly hitting, or someone probing for access they do not have. Both deserve a look, and the failure trend is a better early signal than the raw volume, which mostly tracks how busy your team is.

The most active user figure is worth a periodic glance for the same reason. A sudden change in who is most active, or by how much, is a cheap anomaly signal.

Filtering and searching

Filter	Notes
Event Type	The event taxonomy
User	Populated from the tenant’s actual users
Target	The kind of object acted on
Action	The specific operation
Severity	Low, Medium, High, Critical
Status	Success or failure

Plus a time window of 7, 30, or 90 days, and free-text search.

Filter by Status: failure first when investigating an access problem, and by Target when investigating one object’s history. Filtering by user then sorting by timestamp reconstructs a session, which is what you want when reviewing something after the fact.

The table

Timestamp, Event Type, Action (with the auto tag where it applies), Description, User, Target, Severity, and Status.

Export

Export writes the current filtered view to CSV: timestamp in ISO format, event type, action, user name, and email, along with the rest of the row.

Because it exports what you filtered rather than everything, the reliable pattern for an evidence request is: set the window, apply the filters that match the request, confirm on screen that the rows are right, then export. The file matches what you reviewed.

There is no SIEM integration or log streaming

Argus does not forward audit events to Splunk, a syslog endpoint, or any other SIEM, and there is no streaming API for them. CSV export from this page is the only way out today.

If your SOC needs these events in a central platform, that is currently a manual export or a job you write against the API rather than something Argus pushes.

Retention

Tenant audit records are retained for 400 days by default, then pruned.

That number is a compliance decision rather than a storage one: SOC 2 and ISO evidence periods generally want a year or more, so the default keeps a full year plus a full audit cycle on top, which means an auditor asking about last year’s period always finds the window intact. Pruning can be disabled entirely.

Plan around it if your own obligations are longer. Export before the window closes; once records are pruned they are gone.

What it is not

Two boundaries worth being explicit about, since both are easy to assume:

• It is not a data access log for your cloud. It records actions taken in Argus, not every read of an S3 object in your account. For that you want CloudTrail and S3 access logging.
• It is not the agent’s job history. Scan and discovery runs, with their durations and failure reasons, live on the Jobs tab of Agents. The audit log records that a scan was triggered, not how it went.

Related

• Users & Roles - every action there is audited, and role changes are logged individually per role rather than as one lumped update.
• Tenants & RBAC - audit records are tenant-scoped.
• The Recent Activity widget on the Dashboard is a condensed feed of this same record.