Audit trails and tamper-evident logging
Development status: Experimental implementation exists — An experimental implementation exists; this page describes the intended public developer capability. Tamper-evident audit logging is part of the planned design, and an experimental library implementation exists for internal development only; it is not a complete audit system, no records produced with it are published, and no durability property is claimed. Nothing is publicly available for live use.
Before you read: Governance, compliance and assurance.
Would there be audit records that reveal tampering, and what exists today? This page explains what an audit trail is for, what “tamper-evident” means and does not mean, the intended role of audit logging in the design, what the experimental library is, and what it does not yet provide. “Audit” here means records of actions, not security review. Record structure and access features are not described.
What an audit trail is for
An audit trail is a record of significant actions, kept so that what happened, and when, can be reviewed later.
- Accountability. A record of who did what makes it possible to hold actions to account after the event.
- Investigating incidents. When something goes wrong, a record of preceding actions helps establish what happened.
- Oversight. Those entitled to review the record could check that actions followed the expected process.
“Audit” in this sense differs from an independent security audit — a security review by a party independent of the project — whose status is on Security assurance status and reporting problems.
Tamper-evident, not tamper-proof
- Detection, not prevention. Tamper-evident means that alterations to records can be detected when the records are checked. It does not mean that alterations are impossible.
- Someone has to check. Detection happens only when the records are actually checked.
- No absolute wording. This documentation never describes audit records as immutable, tamper-proof or impossible to alter.
- Not described. How records would be protected and checked is not described.
The distinction matters for anyone relying on records: a tamper-evident record can tell a careful reviewer that something has changed, but it cannot by itself stop the change from being made.
Intended role in the design
Planned.
- Tamper-evident audit logging is part of the planned design.
- It is intended to make significant actions — such as the steps of a governance decision — reviewable afterwards; see Governance proposals and decisions.
- Which actions would be recorded, how records would be kept and who could consult them are not described.
What exists today
Experimental implementation exists — internal only.
- An experimental library implementation of tamper-evident logging exists for internal development.
- It is not publicly available, and no records produced with it are published.
- It is not a complete audit system, and there is no public network for it to serve.
- Related experimental privacy components, including a tamper-evident log component, are described on Privacy-protection building blocks in the experimental prototype.
What it does not yet provide
The experimental library does not provide:
- any published durability or crash-safety property, or any claim that records survive failures;
- any arrangement for auditors or other parties to consult records;
- any assurance that every significant action is recorded;
- any legal, regulatory or evidentiary standing for any record.
How audit records relate to other topics
- Visibility. Visibility controls — including time-limited access for auditors to the data itself — are a separate topic, being explored on Visibility controls and selective disclosure. An audit trail records actions; it does not give anyone access to data.
- Compliance. Audit records are not a compliance claim; see Compliance position and data-protection intent.
- Assurance. Published security assurance (none yet) is on Security assurance status and reporting problems.
Assumptions, trust and limitations
- Tamper evidence helps detect some changes when records are checked. It does not prevent changes, and its strength depends on how records are protected and checked.
- Trust in whoever keeps and checks the records is part of the assumptions, which are not described.
- Statements on this page describe the state of development as of the page’s date.
Not yet available, and how this page will grow
Once released, this page would describe which actions are recorded, how records can be checked and who can consult them. Further technical reference is not yet available, and status changes would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- that any record is tamper-proof or immutable;
- that auditors or anyone else can consult records;
- any durability or completeness of records;
- any legal or compliance standing for records;
- that any audit trail is publicly available.
Anything not stated here as available should be treated as unavailable.
Related pages
- Visibility controls and selective disclosure — time-limited access to the data itself, a separate topic.
- Compliance position and data-protection intent — why audit records are not a compliance claim.
- Security assurance status and reporting problems — “audit” in the sense of security review.
- Privacy-protection building blocks in the experimental prototype — related experimental components.
- Governance proposals and decisions — governance steps that audit records are intended to make reviewable.
Glossary
References
No approved public references yet.
