Enterprise
Audit Logs
An immutable, tamper-evident record of every mutating action in your organization. Audit logs capture who did what, when, from where, and whether it succeeded — giving your security and compliance teams full visibility into all activity.
What Gets Logged
Every mutating API request (POST, PUT, PATCH, DELETE) that hits MemorySync is automatically captured in the audit log. Read-only requests (GET) are excluded to avoid noise, but high-signal security events are always logged regardless of HTTP method.
The following events are always captured:
- Authentication failures (HTTP 401). Every failed login attempt, expired token, or invalid API key is logged with the source IP address.
- Permission denials (HTTP 403). Any request where the user lacks the required role permission is captured.
- Rate limit triggers (HTTP 429). Rate-limited requests are flagged in the
securitycategory for abuse detection. - All data mutations. Creating, updating, or deleting memories, users, API keys, integrations, webhooks, settings, and billing configurations.
- Admin actions. Team management, role changes, SSO/SCIM configuration, retention policy updates, and SIEM forwarder changes.
Zero-config
Audit logging is enabled by default on all plans. There is nothing to configure — it works from the moment you create your organization. Enterprise plans get extended retention and SIEM forwarding.
Event Structure
Each audit log entry contains a rich set of fields that give full context about the action. Here is the complete event structure:
| Field | Type | Description |
|---|---|---|
event_id | string | Globally unique event identifier. Used for deduplication and SIEM correlation. |
timestamp | datetime | Server-side timestamp (UTC) when the event was recorded. |
actor.id | string | Identifier of the user or API key that performed the action. |
actor.email | string | Email address of the actor, if available. |
actor.type | string | How the actor authenticated (session, API key, or anonymous). |
action | string | Human-readable action name (e.g., “Create Memory”, “Revoke API Key”, “auth.failure”). |
category | string | Action category: auth, data, config, admin, api, billing, security. |
severity | string | Event severity: info, warning, or critical. |
resource.type | string | Type of resource acted upon (e.g., “memory”, “api_key”, “user”). |
resource.id | string | ID of the resource that was modified. |
ip_address | string | Client IP address. Respects X-Forwarded-For for proxied requests. |
user_agent | string | Browser or SDK user agent string (max 512 characters). |
success | bool | Whether the action succeeded (true for HTTP < 400). |
trace_id | string | Distributed tracing ID from the inbound request. Links audit records to API request logs and webhook deliveries. |
correlation_id | string | Request ID for correlating related events across a single operation. |
Event Categories
Events are classified into categories for filtering and alerting. Each category corresponds to a distinct area of the platform.
| Category | Actions | Typical Severity |
|---|---|---|
auth | Login, Logout, Sign Up, Token Refresh, Password Reset, Verify Email | info |
data | Create Memory, Update Memory, Delete Memory, Recall Search, Create Summary | info |
config | Add Integration, Update Integration, Remove Integration | info |
admin | Create User, Update User, Delete User, Update Settings, Update Retention, Update SIEM, Create/Revoke API Key, Create/Update/Delete OAuth App, Create/Delete Saved View, Export Audit, Provision/Deprovision User (SCIM) | info |
api | Memory Add, Memory Query, Memory Update, Memory Delete (via API key) | info |
billing | Create Cost Tag, Assign Cost Tag, Create/Update/Delete Billing Alert, Sync Invoices, Update Tax Profile, Update Budget, Setup Payment, Open Billing Portal | info |
security | auth.failure, auth.permission_denied, rate_limit.triggered | warning |
Querying & Filtering
The audit log dashboard provides real-time, filterable access to all events in your organization.
- Filters. Filter by actor (email or ID), action name, category, severity, time range, resource type, source IP, or success/failure status. Combine multiple filters for precise queries.
- Saved views. Save frequently used filter combinations as named views (e.g., “Failed logins this week” or “All admin actions”). Your team can share saved views.
- Real-time streaming. The dashboard supports live tailing — see audit events as they happen without refreshing the page.
- CSV export. Export filtered results as a CSV file on-demand. Useful for compliance reviews, incident investigations, or importing into external tools.
Performance
Common filters — actor, action, category, severity, time range, source IP, resource type — are designed for fast lookup so the dashboard stays responsive even on multi-million-event histories.
Retention Policies
Audit log retention is configurable per organization. You choose how long events are kept in the active store and how they are archived.
| Setting | Default | Description |
|---|---|---|
| Retention period | 90 days | How long events stay in the active (queryable) store. Enterprise plans support up to 7 years (2,555 days) for compliance requirements. |
| Archive threshold | 90 days | Events older than this threshold are moved to cold storage. Archived events can be retrieved on request but are not instantly queryable. |
| Security event retention | 7 years | Security-category events (auth failures, permission denials, rate limits) are retained for 7 years regardless of the general retention setting. |
| Manual purge | — | Admin-initiated purge of events older than the retention period. This action is itself audit-logged. |
Retention changes are audited
Any change to retention settings generates an audit event in the
admin category. This ensures there is always a record of who changed the retention policy and when.Immutability & Integrity
Audit logs are designed to be tamper-evident and immutable:
- Append-only. The audit log table is append-only. Events cannot be modified or deleted through the application layer once written.
- Unique event IDs. Each event has a cryptographically generated, globally unique
event_id, so every event is uniquely identifiable across your entire audit history. - Audit-on-audit. Changes to audit configuration (retention policies, SIEM forwarders, saved views, exports) are themselves recorded as audit events. You can always trace who changed the audit settings.
- Non-repudiation. Events capture the full actor context (user ID, email, IP address, user agent, authentication method) and include the server-side timestamp. This provides forensic-grade attribution for incident response.
- Correlation chain. Related events can be linked via
correlation_idandtrace_id, allowing you to trace a single user action through multiple system components.
SIEM Forwarding
Audit events can be forwarded to your organization’s SIEM (Security Information and Event Management) platform in near-real-time. This is controlled by two settings:
- Master toggle. Enable or disable SIEM forwarding at the organization level. When disabled, no events are forwarded regardless of how many destinations are configured.
- Per-destination config. Each SIEM destination (Splunk, Datadog, Custom Webhook) is configured separately with its own endpoint, credentials, and status.
For full details on setting up SIEM destinations, supported providers, event formats, delivery guarantees, and troubleshooting, see the dedicated SIEM Forwarding page.