Redacting Account Numbers from CrewAI Tool Outputs Before They Enter Agent Context

Where tool output becomes agent context

An agent loop plans, executes tool calls, then observes the results and uses them to update its plan or choose the next action. The return path from tool to agent is therefore where raw data first reaches model reasoning. Anything a tool returns, including a full account number in a customer record, is available to the model from that point on.

The exposure does not end with the current step. Agents reuse prior outputs, task memory, cached state, and stored outputs to guide later actions. A raw value that enters context can be carried into subsequent task steps, written to memory, echoed in a final answer, or included in a request to a third-party model provider. For that reason, redaction must happen before the data is written to context or memory. Redacting afterward misses the downstream reuse.

In a CrewAI deployment, map every path by which a tool result reaches a model call: direct tool return values, results summarized into task output, outputs passed as context to a later task, and anything persisted to memory. Each of these paths should pass through the same control, and the mapping becomes the scope statement for your redaction policy.

Native mechanisms and their limits

The usual native options are custom tool wrappers, handling of tool results in your own code, callbacks and hooks, and task guardrail functions. Each has a place, but none gives consistent enforcement across every agent, crew, and tool on its own.

A wrapper or base class around your tools can sanitize output before returning it. This works for the tools you wrap, and it only covers tools built to use the wrapper. A new tool, a third-party tool, or a tool added by another team bypasses it silently. Per-tool redaction code also drifts: each implementation uses its own patterns and its own placeholder format, and each needs its own evidence.

Task guardrail functions validate a task's output. By the time they run, the model has already read the tool results, so they cannot keep raw values out of context. They are useful as a final check on what leaves the crew, not as the boundary control.

Callbacks and hooks can help where your CrewAI version lets them modify a tool result instead of only observing it. Check that distinction in the version you run, and check that the hook fires for every tool invocation path you mapped. Whatever you choose, an application-level control is only as consistent as the code that adopts it, and it is hard to evidence across a portfolio of agents.

Implementing detection and redaction at the boundary

Build detection from layers, because no single method covers free text and structured output equally well. Each layer has known failure modes, so combine them and measure the result against your own data.

• 1. Normalize before matching: Handle separators such as spaces, hyphens, and dots, and unwrap JSON strings that themselves contain JSON. Decide how you will treat numbers split across adjacent fields.
• 2. Match on format and validity: Use patterns for the lengths and prefixes your institutions issue. Where a format carries a check digit, validate it to cut false positives. Many internal account formats have none, so expect more noise there.
• 3. Add field-aware matching: For JSON and other structured output, match on key names such as account_number or acct_no and redact the value regardless of its shape. This catches values that fail the pattern but sit in an obvious field.
• 4. Add context for free text: In free text, weigh nearby words such as account, acct, or routing. Bare digit strings with no context are the main source of both false positives, such as order IDs and timestamps, and false negatives.
• 5. Apply a policy outcome: Allow when nothing is found, redact when a match is replaceable, and block when the output cannot be safely transformed or the match confidence is too low to proceed.
• 6. Redact before write: Apply the outcome before the result enters context, memory, or a provider request, and preserve the structure of the result so downstream parsing still works.

Choosing a redaction pattern

The pattern you choose decides how much task utility survives. Full masking is the safest and breaks any step that needs to refer to a specific account. Tokenized placeholders keep references stable at the cost of managing a token mapping. Test each against the tasks your agents actually perform.

If tokens are reversible, control who can reverse them and log each reversal. Truncated and tokenized account numbers are recognized in the data-access rules at 12 CFR Part 1033, as of November 2026. That rule governs data access, not agent workflows, so treat it as context for the patterns rather than as a design endorsement.

• Full mask: Replaces the whole value with a fixed marker. Lowest risk, but the agent cannot distinguish or correlate accounts.
• Partial mask (last four): Keeps a short suffix for confirmation. Check that the suffix plus other fields in context does not re-identify the account.
• Consistent token: Maps each value to a stable placeholder within a defined scope, so the agent can compare and join records. Requires a controlled mapping and decode access.
• Format-preserving placeholder: Keeps length and character class so validators and parsers still pass. Ensure the placeholder cannot be mistaken for a real number.

Runtime enforcement, per-tool code, and after-the-fact review

Per-tool code gives each team control, but coverage depends on every tool author. Log review finds exposures after the model has already read the value and after it may have reached memory or a provider. Enforcing policy in the execution path applies one policy to every tool call and acts before the data reaches the model. This is a design argument rather than a measured result, but it follows from where each control sits relative to the model.

The handling of account numbers as sensitive data is well grounded. As of November 2026, 16 CFR 314.2 treats account numbers as personally identifiable financial information within nonpublic personal information, and FTC guidance lists bank and credit card account numbers among customer information institutions must protect. The GLBA account number prohibition in FTC guidance concerns sharing for marketing purposes with nonaffiliated third parties, so do not read it as a general ban on sending account numbers to a model provider. NIST SP 800-218A supports logging, analyzing, and validating AI inputs and outputs, with problem items sanitized or dropped.

A redaction event should be evidence that you can hand to an auditor: the tool, the policy applied, the action taken (allow, redact, or block), a timestamp, and the agent or crew involved, with the match location and count where useful. It should never contain the raw account number. Trussed enforces policy in the execution path on individual tool calls, applies allow, redact, or block at runtime rather than reviewing after the fact, and produces audit-ready evidence from that enforcement. Where it is deployed, it can serve as the single boundary control that the earlier sections describe.