What an audit log should actually capture (and what it shouldn't)

Every administrative action against an Envello account is logged and attributable to the person who took it. What's more interesting than the fact that it exists is what it deliberately does and doesn't capture, since an audit log with the wrong scope is either useless or a liability.

A closed vocabulary, not free text

Envello's audit log writes from a fixed, documented set of actions: team members invited, invites accepted, roles changed, members removed, API keys created, revoked, or rotated, and domains added or removed. That's a deliberate choice, a closed vocabulary is greppable and reportable in a way free-text log lines aren't, and it grows only as real features land rather than being instrumented speculatively ahead of need.

What it never logs

Two hard rules: never a raw API key, and never a recipient's email address. When an audit entry references an API key, it stores only the key's public prefix (the same 8 characters shown in the dashboard), never the full secret. When an entry references a team member, it's their own account email, not anyone they sent mail to. This is the same PII discipline that governs the rest of the product, applied specifically to the audit trail so the audit log itself can't become a data-exposure risk.

Why this scope is the right one

An audit log exists to answer "who changed what, and when", for account and team-level actions. It's not a general activity log of every API call, and it's not a substitute for the actual email delivery logs (which have their own retention and search, covered elsewhere on this blog). Keeping it scoped to administrative actions, with a closed action vocabulary and strict rules about what identifiers it can contain, is what keeps it useful instead of becoming another sensitive-data surface to protect.