Agent email audit logs need to answer four questions: what email came in, what the agent understood, who or what approved the action, and what email was sent. Without that chain, support, security, and engineering cannot debug the system.
last updated 2026-05-074 sections
section 01
Audit log model
Store audit records around events, decisions, actions, and provider results. The log should connect inbound message IDs to extraction results, policy decisions, reviewer actions, outbound provider IDs, and final delivery events.
Logs should be useful without keeping sensitive message content forever. Store raw payloads with retention limits, redact secrets, and separate operational metadata from message bodies where possible.
okDefine retention for raw payloads, extracted objects, and outbound copies separately.
okRedact tokens, passwords, and payment details before long-term storage.
okKeep message IDs and metadata longer than raw content when possible.
okRecord access to sensitive audit records.
okMake deletion behavior explicit for tenant data exports and removals.
section 03
Support visibility
Support teams need a safe read-only view: inbound message, extracted intent, policy outcome, outbound message, and delivery status. They should not need production database access to answer a customer question.
support question
audit field needed
owner
Why did the agent reply?
inbound event and extracted intent
support
Who approved it?
review decision and reviewer
support lead
Was it delivered?
provider message ID and delivery event
support
Was this a duplicate?
idempotency key and send ledger
engineering
section 04
Incident review
A complete audit trail makes incident review practical. The timeline should show inbound receipt, extraction, policy evaluation, review, send attempt, provider result, webhook events, and any retry or manual correction.