> ## Documentation Index > Fetch the complete documentation index at: https://docs.komodor.com/llms.txt > Use this file to discover all available pages before exploring further. # Data handling & redaction > What an agent can see, what is masked automatically, what is not — and the levers that decide how much of your estate ever leaves it. 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](/security-and-governance/identity-and-access/roles-permissions) 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](/security-and-governance/controls/standards-guardrails) 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](/developer-tools/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](/security-and-governance/architecture-considerations/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 Configurable redaction, and the gates it stands at. How a secret reaches a run in the first place. How much of this leaves your environment at all. What a run record actually holds. ## Related topics - [Secrets & credential handling](/security-and-governance/architecture-considerations/secrets-credential-handling.md) - [Agent isolation & tenancy](/security-and-governance/architecture-considerations/agent-isolation-tenancy.md) - [Network & egress control](/security-and-governance/architecture-considerations/network-egress-control.md) - [Standards & Guardrails](/security-and-governance/controls/standards-guardrails.md) - [Deployment methods](/get-started/deployment-methods.md)