# Audit Log Retention: AI Actions at 90 Days vs Seven Years

> Elaichi keeps 90 days of audit log retention, AI actions included. A seven-year mandate needs a customer-owned destination, and only Datadog delivers today.

**TL;DR** Elaichi keeps an organization's audit log for 90 days, so audit log retention for AI actions beyond that has to live somewhere you own. Forwarding to your own log service comes with the Black plan, which is launching soon, and Datadog is the destination that delivers; Splunk HEC and Microsoft Sentinel are accepted as destination types but the forwarders answer 501 and do not deliver. Plan the seven-year copy as a customer-owned store, and treat the in-product log as the working view.

## What a seven-year mandate actually asks for

Your records policy says tool calls are business records and business records are kept for seven years. Somebody then asks whether the AI platform covers that. Audit log retention, AI actions and all, is then two stores with two lifetimes. The in-product log is a working view with its own period, and your long-term copy is a separate decision.

Elaichi keeps an organization's audit log for 90 days. That is the number, and it is the number in the privacy policy and the data processing agreement. An organization that needs a longer history forwards events to its own log service. So the seven-year obligation is met in a store you own, under your own retention settings, not by asking Elaichi to hold records longer.

This matters before procurement, not after. If the retention plan assumes the vendor holds the record, the control has a hole in it on day 91.

## Audit log retention: AI actions in the product and in your SIEM

Audit log retention, AI actions included, splits into two stores with two different lifetimes. The in-product log is 90 days and is where people search, filter and export during an investigation. The forwarded copy lives in your log service and lasts as long as you configure it to.

The in-product side is the easier half. Any organization with an active Gold or Black plan has the audit log, trial included; it is not a plan-gated feature. Everyone can read their own activity, and anybody holding the audit permission reads the whole organization's. A response says which scope it used, so you know whether you are looking at one person's events or everything.

The forwarded side is where the plan matters. Logging destinations come with the Black plan, which is launching soon. A Gold organization cannot forward its audit log today. If your retention plan depends on forwarding, that is a conversation to have before you sign, not a toggle to find in settings.

Every vendor console sets its own window, which is part of why the archive has to be yours. Anthropic's Compliance API keeps recorded Activity Feed events for six years and does not backfill earlier activity ([Anthropic](https://platform.claude.com/docs/en/manage-claude/compliance-activity-feed), checked October 2026). OpenAI's Compliance Logs Platform retains data for 30 days ([OpenAI](https://help.openai.com/en/articles/9261474-openai-compliance-platform-for-enterprise-and-edu-customers), checked October 2026). Cursor's audit logs are an Enterprise-plan feature and record MCP server configuration and authentication events ([Cursor](https://cursor.com/docs/enterprise/compliance-and-monitoring), checked October 2026). Each is built for a different reader. None of them is your records store.

## Which destinations actually deliver today?

Elaichi accepts three destination types: Datadog, Splunk HEC and Microsoft Sentinel. Only Datadog delivers. The Splunk HEC and Microsoft Sentinel forwarders answer 501, meaning forwarding is not implemented yet, and they do not retry. The console labels both "(coming soon)".

Say this plainly in a review, because the destination list reads like three working options and it is one. A team that standardized on Splunk and plans to route AI tool calls there is planning against a forwarder that returns an error and drops the event.

A Datadog destination takes a Datadog site (US1, US3, US5, EU or AP1) and an API key. Events go to Datadog's HTTP log intake with source `elaichi`, tags for the log type and the organization id plus any custom tags you add, and the event's full metadata. The destination's secret is stored encrypted and never returned by the API. You can test a destination: Elaichi sends one synthetic admin event through the real forwarder, reports whether delivery succeeded and records the test in the audit log.

## What the forwarded record carries, and what it does not

A forwarded event carries the event id, the acting user's id, the action, the resource type and id, the event's full metadata, its time and its log type. It does not carry the actor kind, the field that distinguishes a person from a system process or a staff action. If your downstream queries need that distinction, work it out from the metadata rather than expecting a top-level field.

Two other behaviors change what your seven-year archive looks like.

First, the log type filter. Each destination can filter by log type: `tool_call`, `auth` or `admin`. With no filter it forwards everything. The trap is that live connected-tool rows are forwarded as the `admin` log type, not `tool_call`, because of how the export mapper assigns types. A destination narrowed to the console's "Tool calls" type therefore receives file events but not the tool calls themselves. For a retention archive, forward everything and filter in your log service.

Second, delivery is best effort with a ceiling. Forwarding is retried up to five times; a message that still fails goes to a dead-letter queue that nothing consumes, so that event is not delivered. Never promise an auditor that every audit event reaches your Datadog. Promise that forwarding is configured, tested and retried, and keep the in-product log as the 90-day cross-check.

One more reporting quirk: in Datadog, a forwarded event's status is `error` only when its metadata carries `status: error`. Connected-tool rows record a failure as outcome `failed` with no status field, so a failed connected-tool call arrives with status `info`. A failed synthetic tool run arrives as `error`. Build your monitors on the outcome field, not on Datadog's status.

## Does deleting the organization clear the history?

No, and this cuts both ways for a retention policy. Deleting an organization has a 30-day grace period, then a purge on day 30 that removes connections and their credentials, custom connectors, assistant conversations, API tokens, grants, the organization's data store, its stored files and its database rows.

The audit history is not in that list. Organization deletion has no step that deletes the organization's log tenant, so the audit history stays until the log server's retention removes it, which is 90 days. Elaichi also keeps its own staff record of the deletion, naming who asked and the organization's slug, name, region, plan and stated reason.

If your policy requires that deleting a workspace erases everything, say what is true: deletion removes most of it and the audit history ages out on its own 90-day clock. If your policy instead requires that deletion never destroys the record of what happened, the forwarded copy in your own store is what satisfies it.

## Where the records physically sit

Region and retention get mixed up in reviews, so separate them. An organization's region is chosen at creation and cannot be changed. For EU and US organizations, the organization's data store is pinned to that jurisdiction. APAC uses best-effort placement, which is not a residency guarantee.

The audit trail is a different story. Every organization's audit trail, whatever its region, is stored in one EU log instance. Elaichi's [privacy policy](/privacy/), its data processing agreement and its GDPR page all say so in the same words, so a reviewer should hear it from there. For the leg-by-leg version of where each piece of data runs, [the data residency walkthrough](/blog/eu-data-residency-ai-agents/) covers it properly.

Your forwarded copy sits wherever your Datadog site sits, which is your choice among the five sites Elaichi accepts. That is often the cleanest answer to a residency question about long-term records: the long-term store is yours, in your region, under your retention.

## The case where you do not need forwarding

Plenty of teams do not. If your obligation is to investigate incidents and answer access review questions, 90 days of searchable history with free text search, category, actor, action kind and start-time filters covers it, plus a CSV export of the current view with its filters applied. An export longer than 10,000 entries stops rather than saving a partial file, so narrow the range.

Forwarding earns its keep in three situations. A records policy that names a retention period longer than 90 days. A SIEM correlation requirement, where AI tool calls have to sit beside sign-in and endpoint events in one query. And a separation-of-duties argument, where the auditor wants the record in a store the application vendor cannot write to.

If none of those is true, buy Gold, use the in-product log, and revisit when one of them becomes true. For what the record should contain in the first place, [the field-by-field breakdown of an AI agent audit log](/blog/what-an-ai-audit-log-must-capture/) is the companion to this post, and [the SOC 2 evidence walkthrough](/blog/soc2-evidence-ai-agents-cc-controls/) maps these rows onto CC6 and CC7 controls. Certification questions themselves belong with Elaichi's [Trust Center](https://trust.elaichi.ai), which is where the SOC 2 and ISO 27001 reports are published.

## A checklist before you commit a retention number

Write the plan down in this order, because each line changes the next.

1. Name the obligation and its period. Seven years is a records policy decision, not a product setting.
2. Confirm the in-product window. Elaichi keeps 90 days.
3. Pick the owned store. Datadog is the destination that delivers; Splunk HEC and Microsoft Sentinel are accepted but not yet delivering.
4. Confirm the plan. Logging destinations come with Black, which is launching soon.
5. Forward everything, filter downstream, because connected-tool rows arrive under the admin log type.
6. Set the retention in your own store, and monitor for gaps, because a forward that fails five times is dropped.

That sequence survives contact with an auditor, and the [standing answers to a vendor security questionnaire](/blog/vendor-security-questionnaire-ai-agent-access/) cover the rest of what gets asked alongside it. A sentence saying "the platform retains audit logs" does not.

See the [connector catalog](/connectors/) for what gets audited in the first place, or the [governance use case](/use-cases/governance/) for how restrictions and the audit trail fit together.

## FAQ

### How long does Elaichi keep audit logs?

Elaichi keeps an organization's audit log for 90 days, as stated in its privacy policy and data processing agreement. An organization that needs a longer history forwards events to its own log service with a logging destination, which comes with the Black plan, launching soon. Datadog is the destination that delivers today.

### Can Elaichi forward audit logs to Splunk or Microsoft Sentinel?

No. Elaichi accepts three logging destination types, Datadog, Splunk HEC and Microsoft Sentinel, but only Datadog delivers. The Splunk HEC and Microsoft Sentinel forwarders answer 501, meaning forwarding is not implemented yet, and they do not retry. The console labels both "(coming soon)".

### Does every audit event reach a forwarded Datadog destination?

Not guaranteed. Forwarding to a logging destination is retried up to five times, and a message that still fails goes to a dead-letter queue that nothing consumes, so that event is not delivered. Treat the forwarded copy as best effort with retries, and keep the 90-day in-product log as the cross-check during an investigation.

### Do I need a paid plan to read the audit log in Elaichi?

No separate feature purchase is needed. The in-product audit log is not plan-gated: any organization with an active Gold or Black plan, trial included, has it. Every member can read their own activity, and anyone holding the audit:view permission reads every event in the organization. Forwarding the log to an outside destination is the part that needs the Black plan.

### Does deleting an Elaichi organization delete its audit history?

No. Organization deletion has a 30-day grace period and then a purge that removes connections, credentials, conversations, tokens and the organization's data store, but it has no step that deletes the audit history. That history stays until the log server's 90-day retention removes it, and Elaichi also keeps its own staff record of the deletion.

## Read next

- [Vendor Security Questionnaire AI Access: 20 Answers](/blog/vendor-security-questionnaire-ai-agent-access/) — Twenty vendor security questionnaire ai access questions, answered with the mechanism: which key, which role, which log row.
- [GDPR Article 30 AI agent entry, field by field](/blog/gdpr-article-30-ai-agent-processing/) — A GDPR Article 30 AI agent entry needs recipients, transfers and retention. Elaichi's audit row fills part of it; your role design fills the rest.
- [MCP governance: who may do what, in which app](/blog/mcp-governance/) — MCP governance decides who connects which app, which tools each role calls, whose account a call uses, what is logged and how access ends.