What is redaction in AI workers?

Redaction strips or masks sensitive values out of what an AI worker sends to a model or writes into an app, so the information never leaves at all.

Redaction is the last of the three safety layers, and the only one that acts on content rather than on access.

Why access control cannot cover this

A worker can be correctly scoped and still handle text you would rather not send anywhere.

Invoice Follow-up Assistant reaches email and Drive to chase overdue invoices from your AR sheet and inbox. Its access is exactly right: it needs those two apps to do the job. And the material it handles is bank details, account numbers, and occasionally a card number somebody pasted into a thread years ago.

No access rule helps here. The worker is supposed to read that thread; that is the job. What has to change is what survives the trip.

Why it beats asking the model nicely

The obvious alternative is an instruction: "never include account numbers in your reply". This fails, and the reason is worth internalising rather than memorising.

An instruction holds most of the time. Most of the time is not a control. A policy that fails one run in two hundred, unattended, across a fleet, is a policy that will fail this month and you will hear about it from somebody else.

Redaction is applied outside the model's reach. It is not something the worker can be argued, confused or injected past, because the worker is not the one enforcing it.

That distinction, policy the model cannot negotiate with, is what separates a safety layer from a prompt convention. It is the same argument that puts contact filtering before the model rather than inside its instructions.

Where it applies

Both directions matter, and people usually think of only one:

• Outbound to the model. What a run sends to Claude, ChatGPT, Gemini or Grok for reasoning. This is the direction most people mean, and it is the one that determines what leaves your infrastructure.
• Outbound to apps. What the worker writes back into a draft, a ticket or a CRM note. A summary that helpfully quotes a card number has moved it somewhere new, even though the model was never the leak.

The failure mode it is designed around

The realistic leak is not exfiltration. It is a summary.

A worker reads a support thread containing a customer's card number, and writes a ticket that faithfully summarises the conversation, including the number. Nobody attacked anything. The model did exactly what it was asked. The number is now in a ticketing system with a different access model, a different retention policy and a different set of people who can read it.

That is the everyday version, and it is why redaction acts on content in both directions rather than only on the request to the model.

The reasonable objection

"If you strip values before the model sees them, the model loses context and the output gets worse."

Sometimes, and the honest answer is that this is a real trade rather than a free win. A worker that cannot see an amount cannot reason about whether it is large.

Two things make it manageable. Redaction is about identifiers, not meaning: masking a card number rarely changes what a support reply should say, where masking the invoice total might. And it is configured per rule rather than as a blanket setting, so you strip what should never leave and keep what the job needs to work.

If a job genuinely requires reasoning over the sensitive value itself, redaction is the wrong tool and the right conversation is whether that job should be unattended at all.

When it is not the answer

• The worry is which app. Set the app to Off. Redaction is for content that legitimately passes through.
• The worry is who receives it. That is contact rules, and it applies regardless of what the message contains.
• The data should not be in the source system either. Redaction stops it spreading; it does not clean up where it already lives.

On every plan

Redaction ships on every plan, Free included, alongside the app firewall, contact rules, and one key with its own scope list per worker. The complete safety layer is never tier-gated.

The reasoning is the same one that keeps the receipt on every plan: the controls that make autonomy safe cannot be the paid tier, or the free product is the dangerous one by design. What plans change is capacity and retention, not safety. See /pricing.

FAQ

What is redaction in the context of AI agents?

It is a platform layer that strips or masks sensitive values out of what a worker sends to a model and what it writes back into your apps, so the value never leaves rather than being trusted not to be repeated.

Why not just instruct the model not to reveal sensitive data?

Because an instruction is evaluated by the model against every other pressure in its context, including a strong pull toward being helpful and complete. It holds most of the time, and most of the time is not a control. Redaction is enforced outside the model, so there is nothing to negotiate with.

Does redaction protect against prompt injection?

For the values it covers, yes, in the sense that matters: text engineered to make a worker reveal a redacted value cannot succeed, because the value was never in the model's context to reveal. It is not a complete answer to injection, but it removes the class of attack that targets specific sensitive fields.

Does redacting data make the worker less useful?

It can, which is why it is configured per rule rather than as a blanket switch. Masking identifiers such as account or card numbers rarely changes what a reply should say. If a job genuinely needs to reason over the sensitive value, that is a sign the job may not be a good unattended candidate.

Is redaction included on the free plan?

Yes. It ships on every plan including Free as part of the complete safety layer, alongside the app firewall and contact rules, and is never tier-gated.