Using OpenAI Agents SDK Handoff Input Filters to Minimize Customer Information Passed Between Agents

What a receiving agent gets by default

In a multi-agent system built with the OpenAI Agents SDK, a handoff transfers control from one agent to another. By default, the receiving agent can be given the full prior conversation history. That history may include customer messages, account identifiers, tool calls, and tool outputs that returned records from internal systems.

For a triage agent that routes a request, this is convenient. For a downstream agent that only drafts a generic explanation of a process, it is more customer information than the task needs. The exposure is also cumulative: each hop can inherit everything the previous agents saw.

The handoff input filter is the SDK-level mechanism for changing this. It is a function you attach to a handoff. It receives the handoff data, which includes conversation items such as prior messages, tool calls, and tool outputs, and returns the version the receiving agent will see. Because it is ordinary application code, its behavior depends entirely on how you write, configure, and maintain it.

Filter design patterns

Start from the downstream task, not from the data. For each receiving agent, write down which customer fields it needs, then build the filter to pass only those. A default-deny posture, where content is dropped unless the task requires it, is easier to reason about than a list of things to remove.

Scope rules should not assume only first-party customer data. Regulation S-P covers nonpublic personal information a covered institution receives from other financial institutions as well as information it collects about its own customers, so identifiers from partner-supplied records belong in the same rules.

• History trimming: Pass only the most recent turns or only the user's final request, instead of the full transcript.
• Tool-call and tool-output removal: Strip tool invocations and returned records, which often carry the densest customer data.
• Field-level redaction: Replace account numbers, names, and other identifiers with typed placeholders such as a customer reference token.
• Identifier substitution: Swap real identifiers for opaque references that only the owning system can resolve.
• Summarization with caution: A model-written summary can reintroduce identifiers or paraphrase sensitive details. If you use one, filter its output too.

Mapping this practice to Regulation S-P

Regulation S-P, through 17 CFR 248.30, requires every covered institution to develop, implement, and maintain written policies and procedures addressing administrative, technical, and physical safeguards for customer information. Those policies must be reasonably designed to meet the rule's stated objectives. As of November 2026, the amended safeguards and disposal rules apply to nonpublic personal information collected about a firm's own customers and to information received from other financial institutions about their customers.

A handoff filter is a technical safeguard that limits which agents see which customer information. That is a reasonable engineering interpretation of the safeguards expectation, but it is an interpretation. The rule is a safeguards and disposal framework. No SDK feature makes an organization compliant, and a filter does not replace the written policies, ownership, and review that the rule expects.

NIST SP 800-53r5 offers a useful frame. It describes information flow enforcement as comparing the attributes of information, including content and structure, with source and destination, and responding to flows the policy does not explicitly allow. It also notes that organization-defined policy filters can address data structure and content. Treating a handoff as an information flow between agents fits this model, and it makes clear that someone must define the flow policy the filter implements.

Limits and failure modes

The central limit is that a filter is application code, not an independent policy layer. The same team that builds the agent writes the filter, and nothing outside that code guarantees it ran.

Several failure modes follow. A filter can be skipped when a developer adds a new agent or handoff and forgets to attach one. It can be misconfigured so it handles messages but not tool outputs. It can miss new input patterns, since pattern-based and classifier-based filtering needs ongoing maintenance; NIST's work on input filtering in another context notes accuracy limits, the difficulty of balancing false positives against false negatives, and the need to update block lists over time. That context differs, so treat it as an analogy.

State outside the message list is a further risk. NIST material on multi-agent systems identifies memory and cognitive state, written by one agent and read by others, as a security topic. If agents share session or memory state, a message-level filter may not touch it. Confirm for your SDK version what the filter reaches, and add controls for shared state separately. Multi-hop chains need the same scrutiny: each handoff needs its own filter, and a permissive hop can undo a strict one.

• Handoff added without a filter
• Filter covers messages but not tool outputs
• Shared memory or session state bypasses the filter
• Pattern rules miss new identifier formats
• Permissive later hop undoes an earlier restriction

Adding runtime enforcement and evidence

Because a filter cannot show its own correctness to an outside reviewer, regulated enterprises benefit from a second control outside application code. Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, with allow, redact, and block outcomes applied to individual interactions and tool calls. Enforced at runtime, not reviewed after the fact, a policy can redact customer identifiers or block a tool call even when an application-level filter was skipped or misconfigured.

The enforcement itself generates continuous, audit-ready evidence of what was allowed, redacted, or blocked, so a regulated enterprise can show how a restriction was applied rather than only describing intent. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency.

The two controls are complementary. The filter shapes the handoff payload by design. Runtime enforcement applies policy independently of that code and records the result.