Which Elaichi plan can send audit logs to Datadog?

In Elaichi, export to your own Datadog comes with the Black plan. Logging destinations are a Black feature. Every new workspace starts on a 14-day Black trial with no card, so a team can set one up during the trial. Personal and Gold keep the in-product audit log but cannot add a logging destination.

Why does a failed AI tool call show as info in Datadog?

Elaichi gives a forwarded event status error only when its metadata carries status error. A connected-tool row records a failure as outcome failed, with no status field, so it arrives as info. A failed synthetic tool run does arrive as error. Monitors on tool calls should filter on outcome.

Does every Elaichi audit event reach Datadog?

Not with certainty. Elaichi retries forwarding up to five times. A message that still fails goes to a dead-letter queue that nothing reads, so that event never reaches Datadog. The in-product audit log keeps 90 days of history and stays the record of what happened.

Send Audit Logs to Datadog for AI Tool Calls

Q: Can Elaichi forward its audit log to Splunk or Microsoft Sentinel?

No. Elaichi accepts Splunk HEC and Microsoft Sentinel as destination types, but neither delivers. Their forwarders answer HTTP 501 and do not retry. Datadog is the only logging destination that delivers events.

Q: Does a forwarded Elaichi event say whether the AI acted?

Not through actor_kind. The forwarded event carries the event id, the acting user's id, the action, the resource, the full metadata, the time and the log type. It does not carry actor_kind. Elaichi's own audit log shows the actor kind and the surface for each connected-tool call.

On the Black plan, Elaichi can send audit logs to Datadog. The AI tool calls it records then sit beside the rest of your security data. A spike of refused calls can then page someone.

Jake Morgan runs security at a company whose support, finance and sales teams use AI clients every day. Each tool those clients call goes through Elaichi. Every call that reaches execution lands in Elaichi's audit log, the record of who did what, through which app, to which account. Jake's alerts, dashboards and on-call rotation all live in Datadog, a cloud service for logs, metrics and alerts. He wants the AI calls there too.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The protocol's own site calls it an open-source standard. Claude, ChatGPT, Cursor or any MCP client signs in to Elaichi at https://api.elaichi.ai/mcp. The Elaichi Agent works inside the console. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). This post covers the Datadog side of that record: the setup, the quirks and one working monitor.

How do you send audit logs to Datadog from Elaichi?

Add a logging destination in Settings > Organization > Logging. Choose "Add destination", pick Datadog, and enter a site and an API key. In Elaichi, export to your own Datadog comes with the Black plan. The page sits under Organization, not under Governance.

After each audit event, Elaichi queues one forward message for each active destination whose log-type filter admits that event. The events go to Datadog's HTTP log intake with source elaichi. Each event carries:

a tag for its log type
a tag for the organization id
any custom tags you add
the event's full metadata

On a plan without logging destinations, the Logging page shows locked. The forwarder also checks the plan again for each batch. If the organization drops off Black, queued events are dropped, not sent.

Which Datadog site and API key does the destination need?

Pick the site your Datadog organization runs on. Elaichi offers five Datadog sites: US1, US3, US5, EU and AP1.

Datadog's own site documentation says each site is completely independent, and data is not shared across sites (checked November 2026). The same page lists more sites than Elaichi offers, including AP2, UK1 and two US government sites. Elaichi's list does not include them.

The API key is the secret. Elaichi stores it encrypted with AES-256-GCM, a standard strong cipher, and never returns it through the API. Nobody can read it back from the console.

Datadog's API and application keys page says a revoked key can be restored for 7 days. It also recommends several keys so you can rotate them (checked November 2026). Create one key just for Elaichi, so you can revoke it alone.

What does a forwarded Elaichi event carry?

A forwarded event carries the event id, the acting user's id and the action. It also carries the resource type and id, the full metadata, the time and the log type. It does not carry actor_kind, the field that says what sort of actor acted.

For a connected-tool call, Elaichi's audit row records the details below. Datadog gets the event's metadata, which holds the outcome, but not actor_kind.

Who and where. The acting user, and the surface the call came from. The surface is app for the Elaichi Agent or mcp for a remote MCP client. It is api for an organization API token, or console for a person in the console. A call from an MCP client also names its OAuth client's id. OAuth is the standard sign-in that lets an app act for a person.
The actor kind (Elaichi's log only). Values include user, system, staff, ai_assistant and automation. Only the Elaichi Agent's own operations are marked ai_assistant. Its connected-tool calls carry user, with surface app.
The approval. Whether the call's gate asked (approval_required), and how approval was given (approval_source: person, remembered, connected_app, org_setting or direct_run).
What it touched. The toolbox, the connector, and the connection the call actually reached. The trail records the one path argument that names the object, as the target id, and nothing else about the arguments.
How it ended. The outcome, succeeded or failed. On failure, an error code cut to 100 characters.

The error code is a fixed code plus the upstream HTTP status, when there is one. It is never the message the caller saw, because that message can contain text from the third party's response.

One Datadog destination for every surface

Every surface writes to the same audit log, so one destination covers them all. That means Claude, ChatGPT, Cursor or any MCP client, the Elaichi Agent, workflows, the console and the API. A connected-tool row names its surface. A call a workflow makes is recorded as a workflow call.

Every action belongs to a named person. A connected-tool call acts as one member, through a connection that member can use. It passes one restriction check for that member, whichever client sent it. A restricted tool is left out of the tools Elaichi offers a client and cannot be called. Search still names it, flagged restricted, with no schema. The person can file an access request, and only a person in the console can decide it. Removing or suspending a member stops their MCP clients on the next call.

Workflows follow the same rules. A team's own AI can draft one through the elaichi__automation__ operations or the Elaichi Agent. Then it is validated, tried in a test run, published as a numbered version and turned on. In a test run, reads are real, made as the person testing, while writes are held back.

A live run acts as its owner, under the owner's restrictions. If the owner can no longer act, the run fails and the workflow is paused. Only a person approves a step, in the console or in Slack. The workflows guide covers that loop.

Which log types should a Datadog destination take?

Keep Admin ticked, or tick all three. Connected-tool calls are forwarded as the admin log type, not as tool_call.

Each destination filters by three log types: tool_call, auth and admin. With no filter, it forwards everything. With an empty list, it forwards nothing. When all three boxes are ticked, the console saves no filter at all.

Elaichi's export mapper sends only file events to the tool_call type. So the "Tool calls" box on its own forwards file events and none of the tool calls. For a smaller stream, filter in Datadog on the action instead of unticking Admin.

How do you test a Datadog destination?

Choose the test on the destination. Elaichi sends one sample admin event through the real forwarder and reports whether delivery worked.

The test runs on paused destinations too, so you can check a key first. Elaichi records the test in its own audit log.

Then open Datadog's Log Explorer and search for source:elaichi. In Datadog's search syntax, source is a reserved attribute, so it takes no @; other attributes do (checked November 2026). Note the attribute paths your monitors will use.

What happens when Datadog does not accept an event?

Elaichi retries forwarding up to five times. A message that still fails goes to a dead-letter queue, a holding area for messages that could not be sent. Nothing reads that queue, so the event is not delivered.

Do not tell an auditor that every audit event reaches your Datadog. Tell them forwarding is configured, tested and retried, and that Elaichi keeps its own audit log for 90 days. The in-app log is the record. The Datadog copy is the long-term, searchable one, under your own retention.

Why does a failed tool call show as info in Datadog?

A forwarded Elaichi event gets status error only when its metadata carries status: error. A connected-tool row records a failure as outcome failed and has no status field. So a failed tool call arrives with status info. In Datadog, status is a reserved attribute for a log's level or severity (checked November 2026).

A failed synthetic tool run is different: it arrives as error. A synthetic tool is a set of steps that Elaichi offers to an AI client as one tool. So a Datadog view filtered to status error shows failed synthetic tool runs and none of the failed tool calls. Any monitor or dashboard about tool calls has to filter on the outcome attribute instead.

How does a security lead build a Datadog monitor on refused tool calls?

Jake builds one Datadog monitor that pages the security channel when refused AI tool calls climb. It takes four steps, and it has one honest limit.

First, the destination. Jake holds Org Admin, which carries logging:manage. He adds a Datadog destination on US1 with a key named for Elaichi. He adds the custom tag team:security and leaves all three log types ticked. He sends the test and finds it in Log Explorer.

Second, the query. Jake opens a forwarded tool-call event and copies the path of its outcome attribute. His query is source:elaichi, the team:security tag, and the outcome attribute equal to failed. He adds a second clause for the row Elaichi writes when a person chooses Deny on an approval card in the Elaichi Agent. That row names the operation, its classification and the conversation.

Third, the monitor. Datadog's log monitor guide starts from Monitors, then New Monitor, then Logs. It builds the query the same way as a Log Explorer search (checked November 2026). Jake groups by the acting user's id. He sets a multi alert, so each person alerts on their own. He picks a threshold from a week of normal traffic. Datadog's notifications can go to Slack, PagerDuty or email.

Fourth, the triage. A failed outcome is not always a refusal. Jake also groups by the error code, a fixed code plus the upstream HTTP status when there is one. A run of 429s (the HTTP code for too many requests) from one vendor then shows apart from calls Elaichi refused.

The limit matters. A call refused before execution writes no row at all. That covers a tool a restriction withholds, a missing MCP scope, an unknown tool name and a rate limit. Those never reach Datadog. A call waiting for approval writes no row until it runs. Jake's monitor counts refusals at execution and rejected approvals, and he says so in the monitor's description.

Who can see and change logging destinations?

Viewing destinations needs logging:view. Changing, deleting or testing one needs logging:manage. Org Owner, Org Admin and Auditor hold logging:view. Only Org Owner and Org Admin hold logging:manage.

The Auditor role is a free seat that also holds audit:view. So a compliance reviewer such as Emily Carter can check the destination and read every event without a billable seat. The Auditor seat guide has the detail.

When you may not need a Datadog destination

Skip it if 90 days of history is enough and nobody watches Datadog. Elaichi's audit log has no plan gate: Personal, Gold and Black all keep it.

For periodic evidence, the console exports the current audit view as a CSV file. Your filters and date range apply, up to 10,000 entries per file.

Skip it too if your security team lives in Splunk or Microsoft Sentinel. Elaichi accepts both destination types, but neither delivers. Their forwarders answer HTTP 501 (not implemented) and do not retry. Datadog is the one that delivers. Read the retention guide before you plan a multi-year archive around Elaichi.

What does sending audit logs to Datadog cost?

Logging destinations come with Black. Black lists at $24 per user per month in US dollars, or $18 per user per month billed yearly ($216 a year). These are US-dollar list prices; the pricing page shows the price for your own country and currency.

Black also bills usage beyond a free monthly allowance of 1,000 run minutes and 1 GB-month of storage, pooled across the organization. Past that, a run minute costs $0.02 and a GB-month costs $5. Guests, Billing Admins and Auditors take no billable seat, and AI apps do not count as users.

For key custody, customer-managed keys in AWS KMS come with the Black plan. They are set up with Elaichi, not switched on in the app.

The 14-day free trial is the Black plan itself, with no card to start. Every Black feature is on during it, including logging destinations, workflows, collections, dashboards, knowledge bases and the Elaichi Agent. Its one limit is the free monthly usage of 1,000 run minutes and 1 GB, a hard stop until you buy Black. An ended trial moves to the free Personal plan, and nothing is deleted.

Start the trial and add the destination on day one. The Black plan overview covers the rest of the plan. The connector catalog lists the apps whose calls you will be watching.