Audit log

The audit log answers a single question about your space: who did what, when, and to what. Every state-changing action (creating an agent, changing a member's role, connecting an integration, deleting knowledge) writes one immutable entry. AnyBot recognizes 559 audited actions across the platform, so the coverage is the surface, not a highlight reel.

Anatomy of an entry

Every row records the same shape, so any action reads the same way:

What it covers

Actions are grouped into domains you can filter by: agents, knowledge, integrations & channels, inbox & conversations, CRM & leads, social, products, meetings, telephony, calendar, landing pages, and governance (members, roles, spaces, billing, security, exports). If an operation changes state (create, update, delete, grant, revoke, connect, publish, log in, change a password), it is designed to leave a trace. That coverage is enforced in code: a new state-changing action that ships without an audit write fails an internal guard.

How the pieces relate

Each action belongs to an entity, and each entity to a domain. Sensitivity and outcome are derived from the action itself, not stored loosely, so the same classifier drives the labels, the colored tiers, and the filters. That is why filtering by "high sensitivity, denied outcome, governance" returns exactly the security-relevant events and nothing else.

Tamper-evidence

The log is more than append-only. Each new entry is sealed into a hash chain: its hash is sha256(entry-contents | previous entry's hash). Because every entry embeds the one before it, editing or deleting any historical row changes its hash and breaks every hash after it, which an integrity check detects and pinpoints. Sealing is fail-open: it can never block or slow the action being recorded, and entries written before the chain feature shipped are honestly reported as pre-chain rather than silently trusted.

Privacy: what's redacted

The audit log is built to be safe to read:

• IP addresses are never exposed through the audit API, by design, even to owners and admins. They are captured for the record, not surfaced.
• User agents are reduced to a coarse browser / OS / device label. No fingerprint.
• Secrets and PII never enter an entry. A password change, a token, an API credential, or a consent record is logged by field name and a safe diff, never the value.

Worked example

A teammate promotes another member from member to admin. One entry is written:

• Action: space.member_updated · label "Changed a member role/permissions"
• Sensitivity: high · Outcome: success
• Actor: the promoting member · Entity: the promoted member
• Change: role: member → admin
• Timestamp + coarse client (owner/admin view)

Later, an operator opens that record from the admin console. Because it is high-sensitivity, the act of viewing it is itself audited (audit_log.viewed). The log audits its own auditors. (This self-audit fires in the operator/admin panel, not the in-space audit view.)

Who can read it

Reading the audit log is gated by the view_audit_log permission. Owners and admins always have it; members and viewers can be granted it individually through the permission matrix, a common pattern for a compliance reviewer who needs the trail but no other admin power.

FAQ

Can an entry be edited or removed? No. The log is append-only, and the hash chain makes any after-the-fact change detectable.

Why can't I see who did something from before we joined? Entries predating the current chain are marked pre-chain; the tamper-evident guarantee begins at the first sealed entry after the feature deployed.

Does the agent show up as an actor? Yes, automated and callback-driven events are attributed to the agent/system rather than a person, so bot-driven changes are never mistaken for human ones.

Next

• Roles & permissions
• Security & data handling
• Spaces