What an audit log should 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.
Who can actually see it
Audit log access follows the same role structure covered in the team roles post: admins see the full account-level trail, viewers can see it read-only, and it's not exposed through any API endpoint a leaked send-only key could reach. An audit log that's readable by the same credential level as a routine send key would undermine its own purpose, since the log is partly meant to help detect misuse of exactly that kind of credential.
Retention and export
Audit log entries follow the same tier-based retention as the rest of account activity, and are exportable for a customer's own compliance or SOC-2-style evidence needs rather than only viewable in the dashboard UI. For a NIS2- or ISO 27001-relevant audit, being able to hand an assessor an exported log covering a specific period matters more than the log simply existing somewhere in a database.
A concrete example of why the scope matters
If a team member's API key is compromised and used to send unusual volume, the audit log tells you who created that key, when, and whether its permissions were recently changed, useful context for the investigation. It won't tell you who the compromised key actually sent email to, that's in the separate delivery logs, scoped and retained differently, and deliberately not merged into the same administrative-actions trail.
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.