What leaves your machine

EKKA's claim is that your data stays where it already is. This page is the detail behind that sentence: exactly what the ekka binary sends, exactly what it does not, and how to check for yourself rather than take our word for it.

It is one pillar of the security model, which covers the other half: what an agent is allowed to do in the first place.

The short version

The CLI talks to your organization's EKKA control plane and to the gates you connect. It contains no third-party analytics code and sends no usage or activation telemetry.

Verify it yourself, on the binary you installed:

strings $(which ekka) | grep -icE 'posthog|sentry\.io|segment\.io|amplitude\.com|mixpanel|datadoghq'

That prints 0. It is the exact list our release pipeline checks on every build, so the command you run is the one that gates the release.

ekka enclave config

prints every endpoint your Enclave will contact, and where each value came from.

What we receive

When you sign in and use the control plane. Your account, your organization, the Enclaves you register, and the plans you create. When you dispatch a plan, the inputs you typed travel with it. They have to, because EKKA authorizes the call against them. When a run finishes we receive references and cryptographic digests of what happened, not the content.

When your Enclave claims a machine. The machine's hostname, once, as a label so ekka enclave list can tell your laptops apart.

When the CLI crashes. See below.

What we never receive

• The contents of files your agent reads, or their paths
• Prompts you write, or model output
• Rows returned from a database gate
• Credentials of any kind. Secrets live in your Enclave's encrypted vault; values never appear on the command line and never leave the machine
• The body of a gate's error response. That is written to a local diagnostics.log on your machine, and ekka receipts show reads it there

Crash reports

If the CLI panics, it writes a full record on your machine and sends us a much smaller one.

Sent to EKKA	Kept on your machine only
The CLI version and build	The error text
Your OS and processor type	Your command's arguments and flag values
The name of the command you ran (plan, gate)	Your working directory and hostname
The file and line in our source	File paths, resource names, prompts

The error text is the useful part and the risky part: a crash message includes whatever the program was holding at the time, which can be a path or a credential. So it stays with you. ekka doctor names the file if you want to send it to us deliberately.

Crash reports reach our error monitoring through the EKKA control plane. The CLI does not contact a third party.

Turning it off:

export EKKA_CRASH_REPORTS=0     # or the cross-tool standard:
export DO_NOT_TRACK=1

Either one stops the send. Neither stops the local file, because declining to share a crash log should not mean losing your own copy.

These are environment variables, not Enclave settings

Set them in your shell. Do not put them in your Enclave's config file: it rejects unknown keys at boot, by design, so an unrecognised entry there stops your Enclave starting.

Where this is written down

Our privacy policy is the binding statement, including the full list of sub-processors and the region each one operates in. This page is the engineering detail behind it. The privacy policy is what governs.