What Happens to a Ban, a Skill, and an SSO Change: the Admin Audit Log
Chat's audit log deliberately excludes conversation traffic and is gated behind manage permission — a specific, defensible design rather than a generic compliance checkbox.
Audit logs are a standard enterprise-trust checklist item, and most vendors answer the checkbox without saying much about what actually gets logged or who can see it. Chat's audit log is worth describing specifically, because both of those decisions were made deliberately rather than defaulted into.
What it deliberately leaves out
The audit log tracks admin-level configuration events — a defined set of ADMIN_EVENT_TYPES — not conversation content. That's a specific exclusion, not an oversight: an audit log that also carries every chat message is one nobody actually reads, because the signal you care about (who changed what configuration, when) gets buried under a volume of routine conversation traffic that dwarfs it. Keeping the audit log scoped to admin actions keeps it something a person could plausibly review.
What it actually captures
Within that scope, the log is specific: a visitor ban going into effect, a Skill's capabilities being changed, an SSO connection being added or modified — each of these is a describeEvent entry in the log, human-readable rather than a raw diff of database rows. These are exactly the events covered elsewhere in this series — bans (see the guide on blocking abusive visitors), Skills (see the guide on what your AI agent can do), and SSO (see the piece on what enterprise SSO actually locks down) — and the audit log is the connective layer that answers "who did this and when" across all of them.
Who can actually read it
Reading the audit log requires manage capability, not just any authenticated access. That's a pointed design choice: an audit log that records sensitive administrative changes but is readable by everyone it records defeats a good part of its own purpose. Restricting it to the same capability level that can make those changes in the first place means the record of "who changed the SSO connection" isn't itself readable by whoever happens to be logged in — it's reserved for the people actually accountable for the workspace's configuration.
Why this is worth more than a checkbox
A vendor's audit-log claim is easy to make and hard to verify from the outside. What's checkable here is the actual scope: what's tracked, what's deliberately excluded, and who can see it. Chat's answer on all three is specific enough to evaluate on its own terms — a log that stays readable because it's scoped narrowly, and stays meaningful as a control because reading it is itself gated.