What Aile can see

"Blind" means the party relaying a request cannot read it. The picture differs across all three kinds of capacity, and between the node and the relay.

The table

The response headers are honest about this. A nodeless serve reports (nodeless-oauth in place of nodeless when the account is not an API key):

1x-aile-capacity: nodeless
2x-aile-blind: false

and omits x-aile-node entirely, so no machine is claimed that was not in the path.

For callers

Assume the relay can read your prompts and completions on every path, because it is in the request path and can. On the subscription, API-key and nodeless paths a model provider reads them too. If that is unacceptable for a particular workload, the self-hosted path is the one where no model provider is involved. You can require it by naming the model under local/:

1{ "model": "local/llama3" }

That pins the request to sharers running the model themselves. It does not make anything blind: the sharer's machine reads it, and the relay still reads the request to price and route it. What it removes is the provider.

Some publishers also train on what they are sent (Meta's -contributor models). Such a model says so in GET /v1/models (data_policy), in the catalogue, and on its served chat replies (x-aile-data-notice: trains-on-prompts; over MCP, in the use_model result's _meta). A reply held past 25 s from a route entry that is not the last does not carry it. See Models.

Others keep your prompt out of training, and the market marks them "No training" (filter: Privacy → No training). Two kinds of listing carry the mark:

• Groq, whose own published terms say it does not train on API traffic. That is Groq's claim; Aile does not enforce it.
• Vercel AI Gateway models where at least one of the upstream providers does not train. On these, Aile tells Vercel to route your request only to those providers. To route without that restriction, send x-aile-data-collection: allow; the header has no effect when your key, or the request itself, denies data collection.

GET /v1/models reports it as privacy.trains_on_prompts: "no". To be refused anything that cannot say "no", send x-aile-data-collection: deny.

Gemini thought signatures are kept for the next turn. Gemini 3 refuses a tool call that does not carry the signature the model returned on the turn before, and your client never sees that signature, so Aile keeps it. On listings served by the gemini, vertex, vertex-partner, antigravity and agy providers, each answer's signatures are stored in Aile's database for 24 hours by default, keyed by the serving account, the model, the tool call id and your API key, so a tool loop survives a restart or deploy of the relay. A signature is a continuation of the model's reasoning, encrypted by Google and readable only by the serving account's project; it holds no prompt or answer text. An operator can shorten the period or turn storage off, and the signatures are then held in memory only and lost on a restart. While storage is on, those listings say so in their listing facts (GET /market/facts) as privacy.keepsReasoningSignatures: true.

Secrets in your prompts

Coding agents read files into their prompts: a .env, an SSH key, a wallet file. On the chat endpoints Aile replaces each secret it recognises with a placeholder such as [aile-secret:anthropic-key:3f9a1c2b7d4e] before the request leaves Aile, so the sharer's machine and the model provider never receive it. When the model writes a placeholder back, in text or in a tool call, Aile puts the real value in its place before your client sees the answer. An agent that re-saves the .env it read still writes the real key. It is on by default, and the response says how many secrets it hid (x-aile-redacted: 2).

What it recognises: private keys (PEM blocks, a Solana keypair file, a BIP-39 recovery phrase with a valid checksum), API keys with a known prefix (sk-ant-, sk-proj-, ghp_, AKIA, AIza, xox…-, sk_live_, Aile's own sk-aile- and others), JWTs, the password in a connection string, and the value beside a secret's name in a config line (DB_PASSWORD=…, "client_secret": "…"). A string with none of these marks is sent as written, so a secret in a shape it does not know still reaches the provider.

Know what it does not do:

• Aile still reads the original. The swap happens inside Aile, so it protects you from the sharer and the provider, not from Aile.
• Reasoning keeps the placeholder. A model's thinking is signed by its provider, so a placeholder there is left as it is.
• It applies to the chat endpoints only. Images, audio, embeddings and the other non-chat endpoints are sent as written.

Turn it off for one request with x-aile-redact: off, or for a key by unticking Hide secrets from sharers and providers in its settings (redactSecrets: false).

Upstreams that add a hidden prompt

Some resellers let an account owner attach a system prompt of their own to every request made with that account's key. Aile cannot see what an upstream sends the model, so it never knows what the extra prompt says. It can see the prompt size the upstream reports. A model on an API-key account reads high when either:

• its model test, whose prompt is a few words, comes back reported as 100 or more tokens;
• across at least 20 small requests, it reports prompts at least eight times Aile's own estimate and at least 400 tokens over it.

One high reading is not yet a flag, because some models carry a large prompt of their own on every host. Aile compares before it says anything:

• Every model measured on the account reads high (at least two): the account adds a prompt to everything it sends. Its rows say "Upstream adds a hidden prompt (~N tokens) to every request".
• One model reads high, and another account reads that same model clean: this host adds a prompt for that model. Only that model's row says "Upstream adds a hidden prompt (~N tokens) to this model's requests".
• Another provider's account reads that model high too: the model carries the prompt itself, wherever you call it. No flag.
• Nothing to compare it with: no flag.

The listing facts carry the verdict as privacy.hiddenPrompt (GET /market/facts), with scope account or model. Send x-aile-hidden-prompt: deny, or tick Skip upstreams that add a hidden prompt on a key, to keep your requests off those accounts.

This is evidence, not proof. An upstream that under-reports its usage hides its prompt from both checks, and accounts never measured are still used. Secret redaction covers the worst case: a hidden prompt telling the model to repeat any keys it sees finds placeholders.

The non-chat endpoints

Images, image edits, audio, video, music, embeddings, rerank, moderation, OCR, decisions, web search and scrape are served nodeless only: every reply says x-aile-blind: false, and Aile reads both directions in the clear.

• Nothing you send is inspected. Chat requests bound for a sharer's Claude, Codex or Muse Code subscription get a check before dispatch: the text, and inline images for explicit content where the deployment runs the image check. It stores no prompt text and no image. These endpoints get none. Input images for an edit, OCR documents and audio for transcription are relayed to the provider uninspected. The provider's own policies still apply.
• Generated images are stored only if you ask. Where the deployment has image storage configured, an image is uploaded to a public CDN only when you send x-aile-image-store: url (chat and image generation) or response_format: "url" (image generation), and x-aile-image-store: none always wins. A streamed image is inline only (asking to store one is a 400), and the OpenRouter-dialect /v1/images never stores. Only the model's output is stored, never your input. The URL is the only credential: anyone holding it can fetch the image until the deployment's retention period removes it, and it cannot be revoked. Otherwise the image comes back inline as base64 and nothing is kept.
• A video job keeps no content. Its record holds ids, the price, the requested seconds and a status: no prompt, no input image, no output. The video is fetched from the provider when you ask for it.

Agent calls: who reads your task

Calling another agent's time (use_agent_tool, or the playground's agent panel) is a different shape from the paths above, and it needs its own table, because here the thing doing the work is a person-shaped process on a person's machine:

What this means in practice:

• Do not send secrets, credentials, or confidential documents to an attended agent. Your identity stays hidden and your context never crosses (Aile's envelope guarantees that), but the text itself is read by a stranger's human.
• The hidden identity stays protected. No name, no wallet, no IP, no session linkage: the sharer cannot tell that two of your calls came from one caller, and cannot reach back to you.
• Node and direct sharers differ. A sandboxed node sharer runs your task in a throwaway container with no human in the loop; a direct sharer runs whatever server they operate. The agent row above is the only one with a person reading along. The playground says so next to the send box before you pay.

For sharers

Your machine

On subscription and API-key paths your machine forwards encrypted bytes. It cannot read what it is carrying, and the credential is injected at the relay rather than held locally. aile start prints "relaying encrypted bytes only" to describe exactly that.

Turn on a self-hosted model and the client adds a distinct line, because those particular requests are read on your machine. The distinction is repeated at aile local, aile capacity, aile status and aile start so it is never a surprise.

Your credential

This tradeoff is deliberate, and it is the thing to weigh before linking anything. Shrinking it remains an unsolved problem and an intended direction of travel.

Caller tasks you answer

Serving an attended (agent) listing means a stranger's task text lands in front of you, and that text belongs to someone else. You must read it to answer; you must not log it, store it, or carry it into another job's context. Retaining caller task content is grounds for delisting.

What stays with you:

• Models. Weights stay on your machine on every path.

Wallet private keys live in the wallet provider's secure enclave, outside Aile's servers and the CLI. Aile holds signing authority over your wallet and moves your own funds on your behalf, which is how settlement, withdrawal and conversions work. Key export is off unless the deployment enables it, so on the default configuration Aile is custodial and the key is not yours to take. The way out is a withdrawal to any Solana address, of everything not already owed for usage. Earnings on Base or Tempo leave by a withdrawal on that network; that wallet has no export at all.

What is on your machine

One directory: %APPDATA%\aile\ or ~/.aile/. It holds config.json (mode 0600), the machine id, and the node secret. No provider access token is there. Nothing in that directory grants access to a provider account.

Egress

Two allowlists bound where requests can go:

• A node-side list, so a sharer's machine cannot be turned into an open proxy.
• A server-side list of 200+ provider hosts, which is what makes the nodeless path safe: without it, "Aile dials directly" would mean "Aile is an open proxy".

A self-hosted endpoint is constrained to loopback or LAN addresses for the same reason. No configuration key can widen either list.

What this page does not claim

Aile cannot prove what a sharer's node serves. Nothing here is an assurance about model identity or quality. See Verification, which is explicit about where the line falls.