The audit trail
Every authentication and every signed action is logged immutably. This is the artefact your auditors actually read.
Evidence as a by-product
Compliance evidence that is produced separately from the work always drifts from it. Someone screenshots a config in March; by June the config has changed and the screenshot is fiction.
Automentic's audit trail is generated by the workflow itself. There is no second process to keep in step, because there is no second process. If the work happened, the evidence exists; if the evidence is missing, the work did not happen.
What an entry contains
| Field | Example |
|---|---|
| Agent | spiffe://automentic.example/ns/finance/agent/invoice-processor |
| Action | invoice.approve |
| Target | INV-2026-04812 |
| Authorised by | oidc|finance-controller |
| Policy | ap-approvals-v4 |
| Outcome | signed / denied / failed |
| Signature | verified against the issuing CA |
Denied and failed actions are recorded too. An audit trail that only contains successes is not an audit trail — the refusals are often the interesting part, because they show the controls working.
Immutability
Entries are append-only. Nothing edits or deletes a record after the fact, including Automentic. Combined with action signing, that means a tampered record fails verification rather than passing quietly.
Export
The trail streams to the tooling your security team already watches — SIEM, GRC platform, or data warehouse — in the format they expect. Evidence nobody reads is not much use, and asking a security team to adopt yet another console is how that happens.
Retention periods vary by plan, and the exact export formats and connectors depend on the product API. Both will be documented in Reference once fixed.
Billing reconciliation
Usage is metered from this same trail, so an invoice can be reconciled against the record rather than taken on trust. If the two ever disagree, the signed trail is authoritative.