Skip to main content
Two questions decide whether you can point an agent at production data: what it is able to see, and what of that reaches a record afterwards. This page answers both honestly, including the case that is not handled automatically, because knowing where the automatic guarantee stops is what lets you design around it.

​
Masked automatically

Any run-scoped secret or credential value is replaced with a redaction marker before it leaves the worker — recursively, across event names, content, payloads, and metadata. A token echoed into a log line, or returned inside a tool result, is masked before that evidence is shipped. This is a platform behavior. There is nothing to enable and no rule to write.

​
Not masked automatically

General personal data — names, email addresses, IP addresses, free text — is not detected or redacted automatically. There is no built-in classifier for it. Whatever an agent writes into a prompt, an input, tool arguments or results, logs, messages, or output is stored as written.
That is a design boundary rather than an oversight: a classifier that silently rewrote an agent’s evidence would make the evidence unreliable, and one that missed a category would be worse than none. So the platform is explicit about what it guarantees, and gives you three levers for the rest.

​
Lever 1 — scope what the agent can reach

The narrowest control is the one furthest upstream. An agent that has no tool for reading customer records cannot put customer records anywhere. Bind credentials per agent, keep tool surfaces small, and use labels to keep an agent inside its own team’s resources.

​
Lever 2 — emit findings, not dumps

Keep raw estate data read and reasoned about locally in the worker, and have the agent emit its conclusions rather than its inputs. A run record that says “three pods in this namespace are crash-looping on the same image” is far more useful than one carrying the raw log stream that produced it — and it is the version you can retain safely.

​
Lever 3 — redact at the boundary with a guardrail

Where a specific class of value must not cross a specific boundary, a guardrail can redact it — including by named value class rather than a pattern you had to write, for cases like a payment card number or a cloud access key. Guardrails stand at the tool call, the tool response, the model request, and the model response, so you can choose the boundary rather than the field.
One documented exception, in the Go SDK. There, a worker’s session snapshot is sent as-is and is not secret-masked — masking it would corrupt the state it exists to preserve. Keep credentials out of it. See Go SDK, where the snapshot API is described. A Python SDK worker’s snapshot is masked, like the rest of its evidence.

​
What never leaves

Regardless of configuration:
  • Readable credential values. Secrets are delivered to a run and masked out of everything that leaves the worker.
  • Another workspace’s data. Isolation is per workspace; see Agent isolation & tenancy.
  • Raw bulk telemetry the agent read locally, unless the agent itself puts it in its output — which is what lever 2 is about.

​
Retention

Runs, evidence, chats, and audit records are retained as durable history, which is what makes it possible to trace any conclusion back to what the agent actually saw. Archiving an agent retires it without deleting that history, and credentials, keys, and tokens can be disabled or revoked at any time with immediate effect.

​
Next steps

Standards & Guardrails

Configurable redaction, and the gates it stands at.

Secrets & credential handling

How a secret reaches a run in the first place.

Network & egress control

How much of this leaves your environment at all.

Runs & evidence

What a run record actually holds.