- What happened — someone read a credential, someone logged in over SSH, a grant was created.
- What is possible — who could reach this credential or host right now, and by which path.
What happened
The per-resource trails page with
limit and cursor, and filter with from, to, user_id,
action and q. SSH audit also takes success to see only denials.
Two details worth knowing:
- The set audit includes machine reads. A
machine_readordeliverrow is a host consuming the set, not a person. If you only ever see human actions, the set is not actually being used where you think it is. - Deletes survive their subject. Deleting a credential writes an audit row with a null credential id and the name denormalized onto it, so history stays readable afterwards. Same reason removing a user keeps their row and keys.
What is possible
Each entry names its path: a direct grant, a resource group, or admin role. One person can appear
more than once — a direct grant plus membership in two groups is three entries, and that is the
honest answer.
Admins are listed explicitly in these results. They bypass grants, so omitting them would make the
audit lie about who has access — the most dangerous kind of wrong answer an access audit can give.
Checking what a host is enforcing
The audit tells you what the control plane believes. To confirm a host agrees:key_count is how many keys the recomputed snapshot contained. On the host,
custosd status reports the cached count. A mismatch means delivery, not permission — see
Troubleshooting.
Retention and tamper-resistance
Audit tables reject truncation at the database level, so a strayTRUNCATE cannot quietly erase a
trail.
Notifications are purged after 30 days. Audit rows are not on that schedule — they are the record.