Private by architecture, not magic
Ghostshell does not send your prompts to a third-party model API and does not intentionally retain customer content after teardown. It is not zero-knowledge.
The honest boundary: prompts, responses, tool inputs, and files must exist in plaintext while your task runs. Ghostshell operators and the infrastructure providers can technically access that data at the layer where it is processed.
Where a task travels
| Layer | Reality |
|---|---|
| Browser | Your prompt, response, and conversation UI live in page memory. A runtime restart key may remain in this browser, but it cannot recover destroyed content. |
| Fly | Each session receives an isolated disposable workspace VM with ephemeral root storage and no attached persistent volume. Fly controls the edge and VM. |
| Hetzner | Ghostshell's trusted broker terminates TLS and relays request and response bytes in process memory on a protected VPS. |
| RunPod | Ghostshell operates its model server on RunPod Secure Cloud. Sessions use pinned logical slots inside one shared model process. |
| Stripe | Stripe retains payment, customer, transaction, and fraud records plus opaque Ghostshell purchase identifiers and, for a measured campaign, a fixed content-free acquisition source token. Ghostshell does not send it prompts, search terms, or files. |
| Google Ads attribution | During an explicitly measured Search campaign, Ghostshell accepts one Google-provided gclid, gbraid, or wbraid value without loading a Google tag or third-party analytics script. It is stored first-party with the landing path and opaque Checkout linkage until a ready-and-captured conversion is uploaded, or for seven days at most, then deleted. |
| Campaign funnel counters | Measured landing pages increment hourly aggregate counts for fixed landing, traffic, product, and funnel-event categories. These counters contain no visitor identifier, IP address, user agent, referrer, query string, Google click identifier, session or payment identifier, or customer content, and expire after seven days. |
| External tools | Web, browser, package, API, git, SSH, and upload actions can send task data to the destination service the agent accesses. |
After teardown
Ghostshell revokes the session's broker access, requests destruction of the Fly workspace VM, and overwrites the pinned model-slot KV state before releasing it. Provider-managed VM deletion is not a cryptographically provable disk wipe.
Ghostshell does not intentionally retain prompts, model responses, browser conversation history, workspace files, snapshots, tool arguments, commands, or tool results after successful teardown.
What remains
- hashed runtime restart keys and remaining runtime balance;
- entitlement, session-lifecycle, capacity, and teardown metadata;
- during a measured Search campaign, one Google click identifier, landing path, opaque Checkout linkage, amount/currency, readiness time, and upload/expiry state for no more than seven days and normally only until successful upload;
- hourly aggregate campaign-funnel counters over fixed landing, traffic, product, and event categories for no more than seven days, without visitor, request, click, session, or payment identifiers;
- operational and security logs;
- provider control-plane, billing, and security records; and
- Stripe payment and transaction records, including a fixed content-free campaign source token when applicable.
Fly documents that application stdout is shipped off-Machine and searchable logs are retained for seven days. Ghostshell therefore does not claim “no logs.”
Ghostshell does not use email, phone number, name, address, card data, prompts, files, model outputs, workspace commands, search terms, or in-workspace URLs for ad attribution or enhanced conversions. Successful conversion upload deletes the local click-attribution row rather than retaining a customer journey.
Training and evals
There is no production pipeline saving customer prompts, files, responses, or sessions for training or eval creation. Current agent-harness evals are synthetic or operator-authored. Improvement measurements are content-free signals such as task category, tool type, timing, tokens, error class, pass/fail, and artifact validation.
If customer usage informs future evals, it should remain zero-content by default. Any abstract task recipe should require a separate opt-in and show the exact payload before sharing. Training model weights on customer content would require a distinct explicit opt-in.
Visible agent activity
The workspace can show fixed tool categories, safe relative filenames or hostnames, duration, and success/error state. It withholds commands, code, file contents, search queries, full URLs, typed browser text, tool output, raw exceptions, prompts, and private reasoning.