Audit Log

i1n's audit log records every mutation across an organization — not as a coarse 'translation file updated' line, but as a structured, per-key, per-language event. When a dashboard user changes the Spanish (es_mx) translation of errors.insufficient_funds at 14:32 UTC, the log captures the exact before value, the exact after value, the actor identity, the timestamp, the IP address, and the user agent of the request that produced the change.

Coverage spans the entire surface area of the platform: translation creates, edits, and deletes; namespace creation, renaming, and removal; project settings and brand voice changes; team invites, role changes, and removals; API key creation, rotation, scope changes, and deletion; billing plan changes, subscription events, and BYOK activation.

Bulk operations such as i1n push produce one event per modified key-language pair rather than a single coarse summary, with a shared batch identifier in metadata. A push that updates 200 keys across four languages produces 800 individually addressable audit entries, each with its own diff. Auditors can therefore answer 'what changed on April 17 at 14:32' down to the exact string.

Events are emitted by PostgreSQL triggers attached to every audited table. There is no application-level write path that bypasses the log — every successful mutation generates its audit row inside the same database transaction. A change that is committed without a corresponding audit row is not possible by construction.

Every audit entry is tagged with one of five actor types: user for dashboard mutations, cli for direct command-line operations, mcp for changes made by an AI agent through the i1n MCP server, webhook for events originating from external systems such as the billing provider, and system for platform-internal jobs such as retention pruning.

Dashboard user attribution is cryptographic. The actor identifier is the authenticated user's account ID, surfaced together with their verified email and name from the organization member list. Administrators reviewing the log see real human identities, not opaque UUIDs.

CLI and MCP attribution is cryptographically tied to the API key in use, with the key prefix recorded for forensic correlation. Hints derived from the developer's git configuration — email and full name — are also captured but are explicitly labeled as unverified in the dashboard. This honest separation between cryptographic identity and self-reported metadata is what compliance reviewers expect from a mature audit system.

AI agent observability is, to our knowledge, unique to i1n. Every translation change made by Claude Code, Cursor, or any other client connected to the i1n MCP server is tagged with actor_type = 'mcp'. Organizations can filter the audit log to answer 'which translations were last modified by an AI agent versus a human reviewer' — a question that does not have a clean answer on any other localization platform.

As AI agents take on more of the localization workflow, the ability to audit them as first-class actors is becoming a procurement requirement. The actor type filter is one click in the dashboard and one query parameter in the CSV export.

The audit log is append-only at the database level. Triggers emit rows; no INSERT path is exposed to clients, and there are no UPDATE or DELETE policies on the table. Members of an organization cannot edit their own history. i1n operations staff cannot edit or delete entries either — the table is protected at the schema layer, not at the application layer.

Retention is 365 days, aligned with the SOC 2 control baseline for activity logs. Records older than 365 days are removed by a scheduled job that itself emits an audit entry — every deletion is traceable. Organizations that require longer windows for a specific regulatory review can request an extension at the contract level.

The log surfaces the data points compliance reviewers typically request: who, what, when, where (IP address), how (user agent), and what changed (before and after values, in full). For organizations subject to GDPR Article 30 record-keeping or to fintech regulators that require traceability of user-facing content, the export is sufficient as primary evidence.

i1n does not publish a SOC 2 Type II report at the platform level today. The audit log is the underlying control that supports a customer's own SOC 2, GDPR, or fintech compliance program — it does not replace organizational controls, but it removes the most common blocker in compliance reviews, which is the absence of an auditable trail over content changes.

Read access to the audit log is restricted to organization owners and administrators. Editors and viewers do not see the audit log tab in the dashboard and cannot query it through the API. This separation is enforced by PostgreSQL row-level security, not by client-side hiding — there is no path to read the log from a non-privileged role.

Editors and viewers remain fully subject to the audit log. Every action they take on the platform — translation edits, AI translation requests, member-level operations — is recorded with their identity and visible to the admin team. The people being audited cannot remove themselves from the audit.

Owners and administrators cannot edit historical entries. The 'who can read' question and the 'who can modify' question deliberately have different answers — read is admin-level, modify is no one. This satisfies the separation-of-duties expectations that auditors apply when reviewing internal access controls.

API access mirrors the dashboard model. The audit log is exposed through the same row-level security policies that gate the dashboard, so any service account or integration token used to query the log inherits the same restrictions automatically.

Audit log data can be exported as CSV from the dashboard with a one-click action. The export covers any selected time range and respects the active filters — actor type, event type, project, and search term — so reviewers can be handed a narrow slice rather than the entire history. The CSV preserves full fidelity: timestamp, organization, project, actor identity, actor type, API key prefix, event type, entity, before value, after value, IP address, user agent, and metadata.

Every CSV export itself generates an audit entry of type audit_log.exported, recording who performed the export and which filters were applied. This closes the chain-of-custody loop that compliance reviewers ask about — the act of pulling evidence is itself part of the evidence.

The audit log is automatically active on all Enterprise organizations. There is no configuration step, no opt-in toggle, and no setup required. Existing Enterprise customers — including belo, the launch partner — have a populated log from the moment the feature shipped, capturing activity from every dashboard, CLI, and MCP client connected to the organization.

Organizations on the Pro or Business plan do not have audit log access. Upgrading to Enterprise activates the log immediately and begins capturing events from the upgrade timestamp forward; historical retention prior to the upgrade is not provided. Contact the i1n team to discuss Enterprise pricing for your organization.