Documentation

Audit log

A console that manages a network must be accountable. In VIGIL-MESH, every action performed from the console — creating a rule, revoking a device, inviting a member, publishing a policy — is recorded in an audit log specific to the organization. This log is hash-chained: each entry cryptographically depends on the previous one, which makes any deletion or rewrite detectable. It is attributed (you know who acted), filterable, exportable, and retained for at least one year.

A hash-chained log

The audit log is not a simple list of events that could be edited line by line. Each entry embeds the hash of the entry that precedes it: the records form a chain, in which link N locks everything written up to N. Deleting an entry in the middle, changing its content or reordering two of them breaks the continuity of the hashes, and the anomaly becomes visible by recomputing the chain.

This property does not make the log “immutable” in some magical sense — an operator with full access to the storage could still try to act on it. What it guarantees is detectability: an alteration cannot go unnoticed, because it breaks the chaining. That is the difference between a register that can be tampered with in silence and a register where any manipulation leaves a mathematical trace.

1
An action happensA member acts from the console: the nature of the action, the author and the timestamp are captured.
2
The entry is chainedThe record incorporates the hash of the previous entry, then its own hash is computed. The new link depends on the entire prior history.
3
The chain is verifiedTo check integrity, the hashes are replayed end to end: the slightest break signals a missing, modified or moved entry.

Each organization has its own chain. Logs are not mixed between customers: the audit inherits the multi-tenant isolation described in /en/docs/console-roles, and one organization's chaining says nothing about another's.

Attribution: who did what

A log that records “a rule was deleted” without saying by whom has only limited value. In VIGIL-MESH, every console action is attributed: the entry carries the identity of the member who acted, the timestamp, and the nature of the operation. You can therefore answer the questions that matter after an incident: who revoked this device, when did this rule change, who invited this new member.

The author: the member of the organization who triggered the action, identified by their identity in the workspace, not by an anonymous address.
The action: the nature of the operation (creation, modification, revocation, publication, invitation, deletion…) and the resource concerned.
The timestamp: the moment the action was recorded, which gives the chain its temporal order.
The context: the organization the entry belongs to, since each tenant keeps its own audit chain.

Attribution rests on workspace identities: it is because each member acts under a distinct identity that the log can name the author of an action. The breakdown of roles — infrastructure operator, a customer's network administrator, read-only auditor — is covered in /en/docs/console-roles, and the read-only auditor is precisely the role that reads this log without being able to act on the network.

Filtering and exporting

A useful log is one you can query. The console lets you filter entries to find what matters without scrolling through months of history: by author, by action type, by affected resource, by time range. You move from a raw register to a targeted answer — “all device revocations from last month”, “all of this member's actions on this policy”.

Filtered entries can be exported for use outside the console: independent archival, compliance review, handover to a third party, correlation with other logs in your information system. The export outputs the records with the elements that identify them, so the exported chain remains verifiable outside the interface.

Filter

Target by author, action type, resource or period to isolate what is relevant in the organization's history.

Export

Extract the selected entries to archive them, audit them or correlate them outside the console.

Verify

The chaining elements accompany the export: the integrity of the sequence remains checkable after the fact.

Retention: at least one year

An incident is not always discovered the day it happens. A contested revocation, a misunderstood policy change, an intrusion spotted late: you often have to go far back in time to reconstruct what happened. That is why the audit log is retained for at least one year, so the history remains available well beyond the immediate horizon.

This retention combines with the chaining: across the whole retained window, the order and integrity of the entries remain verifiable. You do not merely keep lines, you keep a chain whose consistency can be re-checked. That is what allows the log to be used as evidence during a security review, whose overall framework is described in /en/docs/securite.

Can I keep the logs longer than a year?

Retention “for at least one year” is a floor, not a ceiling. To go beyond it, the export lets you durably archive the chain's records in your own system, according to your compliance obligations.

What happens if an entry has been altered?

The break in the chaining makes it detectable: by recomputing the hashes, verification pinpoints the place where continuity is broken. The log does not conceal a manipulation, it exposes it.

Does the log distinguish organizations?

Yes. Each organization has its own audit chain, with no mixing and no cross access. The multi-tenant isolation that guarantees this separation is detailed in /en/docs/console-roles.