// platform.audit

Audit log

A comprehensive, immutable record of every significant action in your tenant — filterable, exportable, with context for every entry.

What gets recorded

The audit log is broader than "security events". BoardHerald records every action that could matter in a post-mortem, a compliance review, or a due-diligence pack. Roughly:

Authentication — sign-in, sign-out, magic link consumption, fallback-password attempts, NDA acceptance / re-acceptance.
User lifecycle — invites sent, invites accepted, role changes, demotions, removals.
Content lifecycle — updates / resolutions / meetings drafted, published, edited (with diff), restated, deleted. Minutes published.
Read actions — update opened, acknowledged, NDA scrolled. Vault downloads (once applicable) would go here too.
Votes — each vote cast (or changed) on a resolution.
Financials — KPI created, updated, restated.
Branding — logo / theme / custom CSS changes; email template changes.
API keys — issued, revoked, scope changed.
Agent tool calls — every MCP tool call, with the key that was used and its persona.

What each entry captures

A single audit entry looks like this (schematically):

action — e.g. update.published, resolution.voted, nda.accepted.
actor — user ID + display name + role at time of action. If an agent, also the key ID + persona.
target — the object touched (update ID, resolution ID, member ID, etc.).
timestamp — UTC, second-precision.
ip — the client IP at time of action.
user_agent — full UA string, plus a parsed "device" summary (e.g. macOS Safari 17.3).
city — geoIP-derived city + country, for at-a-glance review ("why is Sidney signing in from Montevideo?").
payload — action-specific context. For a resolution vote, the vote value. For an update publication, the update version. Never secrets.

Immutable by design

Audit entries can't be edited or deleted by any tenant admin. If an actor tries to cover their tracks by changing a resolution after the fact, the edit itself is a new audit entry — and the original is still there. This is why the log is trusted for compliance.

Who can see the log

By default, only ADMIN can access the full audit log. MEMBERs see a subset — their own actions in their own view (so they can sanity-check what BoardHerald recorded), but not other members' activity.

For agents, the audit:read scope is its own explicit opt-in — it isn't bundled into any of the built-in personas (read-only, meeting secretary, board secretary) because it exposes a lot about the tenant. Only the full admin persona includes audit:read, and we recommend issuing admin keys only for very specific workloads (e.g. automated security monitoring).

Filtering + querying

Open Admin → Audit. You can filter by:

Action type — every recorded action category.
Actor — specific user or agent key.
Timestamp range — from / to, with preset windows (last 24h, 7d, 30d).
Target — filter by what was touched (e.g. all actions on a specific resolution).

The filtered view exports as CSV with one click — useful for handing to a lawyer, an auditor, or just dumping into a spreadsheet for your own analysis.

Retention

Current policy: audit entries are retained for the lifetime of your tenant. We don't auto-prune. If you need entries removed for a specific regulatory reason (GDPR right-to-be-forgotten on a departed member, for example), contact us — removal is a manual, logged operation that leaves a tombstone entry explaining the action.

Audit log is not a guarantee against malice

An ADMIN with full access can still do things you'd consider bad (unpublishing an update, demoting a member before the board meeting). The audit log makes those actions visible; it doesn't prevent them. For tenants that need stronger separation-of-duties, ask us about multi-admin approval workflows — it's on the roadmap.