Skip to content

TRUST AND DATA

What leaves your machine

Your prompts, your files, your database rows and your credentials never reach EKKA. EKKA authorizes and signs what your agents do without receiving what they read or what they wrote.

This page is for whoever has to answer a vendor security questionnaire, and for the engineer they will ask to check the answer.

Where your data lives is your choice. Not being read is not a choice: the ekka binary talks to your organization's control plane and to the gates you connect, and it carries no third-party analytics code at all.

Field by field: exactly what the CLI sends, exactly what it does not, and the command that proves each one on the binary you installed rather than on the one we describe.

Every endpoint your Enclave contacts, and where each value came from:

ekka enclave config

Every analytics vendor in the binary, counted on the copy 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.

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


What does EKKA 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 does EKKA 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

Does EKKA train on my data?

EKKA receives no prompts and no model output, so there is nothing on our side to train on. That is a consequence of where the work happens rather than a setting you have to find and switch off.

When a plan calls a model, the prompt travels from your Enclave to the model provider you connected, under a Grant that names the model and caps the tokens. EKKA authorizes that call and signs the fact of it. The text goes to the provider, not to us, and what that provider does with it is governed by your agreement with them.

The two commands that show you the whole picture: every endpoint your Enclave contacts, and every model permission that currently exists.

ekka enclave config
ekka gate grant list

What happens when the CLI crashes?

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.

How do I turn crash reports 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 unrecognized entry there stops your Enclave starting.

Which document is legally binding?

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.