Where your data goes

Every call the Golem agent sees has two parts: the facts about it (which agent, which tool, when, what was decided) and the raw content (the prompt, the arguments, the output). The facts go to Golem's service, signed. The raw content goes to a bucket through a storage relay: Golem's, by default, encrypted under a key for your workspace alone, or your own, if you run the relay yourself. This page says exactly what goes where.

flowchart TD
    A["Golem agent<br/>on each machine"] --> R["Storage relay<br/>Golem's or yours"]
    R -- "raw payload" --> B[("Bucket<br/>Golem's or yours")]
    R -- "signed entry, no payload" --> G["Golem's service"]
    G --> C["Console"]
    B -. "fetched by the browser<br/>for people allowed to" .-> C

What Golem's service holds#

The relay takes the raw payload out of each entry before passing it on. What reaches Golem's service is:

Two profile settings under Data handling control the arguments: Tool arguments (whether they are sent at all) and Scrub secrets from tool arguments. Both are on by default. Turning scrubbing off sends credentials that appear in arguments to Golem as they are, and the console warns you.

When redaction is on for a profile, the preview, the arguments, the metadata text and the payload are all redacted on the machine before anything is hashed, signed or sent. Redaction is off by default.

Search fingerprints#

To let you search by meaning, each call is turned into numeric fingerprints: a short summary of the call (up to 480 characters of it) becomes one list of 384 numbers, and longer text is cut into pieces of 400 characters, each with its own list. Only the numbers are sent; the text they came from is discarded. Treat them as derived from your content all the same: similar text produces similar numbers, which is what makes search by meaning work.

Choose where they are computed in each profile's Embeddings setting:

Fingerprints are made from the text after redaction when redaction is on, and from the original text when it is off.

Where raw payloads go#

Each payload is compressed and stored under a name made from its SHA-256 hash, so a copy fetched later checks against the hash its entry signed.

Golem's storage, under your workspace's key#

Unless you set a different relay, machines send to Golem's. It encrypts every payload before storing it:

• each payload gets a fresh 256-bit key and is encrypted with AES-256-GCM;
• that key is wrapped by a master key belonging to your workspace alone;
• your workspace's master key is in turn wrapped by a key held in a cloud key management service.

One workspace's key cannot unwrap another workspace's data. Golem's storage deletes payloads 90 days after they are written.

Your own bucket#

To keep payloads in storage you control, run your own storage relay. Under Settings → Deploy → Relays, Get the deploy command gives you a ready command for Google Cloud Run with a Google Cloud Storage bucket. The relay also writes to Amazon S3, Azure Blob Storage or a local disk, using each cloud's standard credentials: the AWS credential chain, Google's application default credentials, or an Azure connection string.

Then point machines at it: set the Relay in a profile under Hosts, Groups & Profiles, or set GOLEM_RELAY_URL when you run the installer. From then on Golem's service receives the signed entries and never the payloads.

Payloads in your bucket are never deleted by Golem. Their retention is yours to set.

Bring your own key#

For the strictest separation, a storage relay can wrap every payload's key twice: once with Golem's key and once with a key in your own Google Cloud KMS. Both are needed to read anything. If you revoke Golem's access to your key, the relay cannot load it the next time it starts, stops serving, and the payloads it stored can no longer be decrypted by anyone, Golem included.

Know the limits before you rely on it:

• It runs on a dedicated storage relay, never on Golem's shared one, because one customer's key must not gate every other customer's data. There is no console setting for it yet; email info@golem.team.
• It works with Google Cloud KMS and Google Cloud Storage only.
• A relay that is already running keeps the key in memory until it restarts.
• It protects payloads only. Everything Golem's service holds (the signed entries, previews, arguments and fingerprints) stays readable, and the record still verifies.
• While your key is revoked, new entries wait in each machine's local queue rather than being stored.

Who can read payloads#

Nothing else on Golem's side opens stored payloads. Reading payload bodies is off by default in the sense that the investigator itself is off until you turn it on. Once it is on, the Payload analyst switch starts on, and you can turn it off.

What stays on the machine#

• An entry that cannot be delivered waits on the machine's own disk, payload included, for up to 24 hours or 1 GiB.
• The search-fingerprint model is part of the Golem agent. Nothing is downloaded to compute fingerprints.
• The prompt-injection check sends the text it scores to the relay's model and keeps only the verdict. The text is never stored with it.

How long Golem keeps things#

A legal hold keeps a held case, its flags and its conversations past these limits, and on Google Cloud Storage it stops held payloads expiring.