How to Encrypt Customer Data Between OpenAI Agents SDK Agents and Tools Under NYDFS Part 500

What Part 500 says about agent-to-tool data

Section 500.1 defines nonpublic information broadly. It covers electronic information that is not publicly available, including information that can identify an individual in combination with specified data elements. Customer data in a tool argument or a tool response can meet that definition even when the agent treats it as ordinary text.

Section 500.15(a), as amended, requires a written policy requiring encryption that meets industry standards to protect NPI held or transmitted by the covered entity, both in transit over external networks and at rest. DFS has stated that 500.15 does not require encryption of data in use. The text is keyed to external networks, so an agent-to-tool hop on an internal network is not expressly mandated by 500.15(a). Encrypting it is a risk-based design choice that you should document, and DFS has recommended network segregation where practicable.

Third parties matter as well. Section 500.11 requires policies for NPI and information systems accessible to or held by third-party service providers, including their access controls and their use of encryption under 500.15. A third-party tool or MCP server is therefore a provider relationship with due diligence expectations, not only a network endpoint.

Transport encryption and key management per boundary

For each tool connection, set a minimum of TLS 1.2 with NIST-approved cipher suites and enable TLS 1.3 where the tool supports it. NIST SP 800-52 Rev. 2 is federal-system guidance and Part 500 does not define industry standards by reference to it, but it is a reasonable baseline to cite in your written policy. Do not carry over its allowance for TLS 1.0 and 1.1 for non-government interoperability.

TLS lets client and server authenticate each other, establish a shared key, and protect the payload with integrity and source-authentication mechanisms. Use mutual TLS where a tool must verify which agent runtime is calling it, for example on an internal service that returns customer records. Server-only authentication is usually sufficient for a public provider endpoint, provided the agent runtime validates certificates.

Key management needs its own owner. NIST guidance says a key should be used for only one purpose and that secret and private keys should be wrapped or otherwise protected when distributed. In practice, use separate certificates and keys per tool boundary, keep private keys out of agent prompts and tool definitions, and record rotation schedules in the same policy that names the TLS configuration. Verify the configuration against the standard you cite rather than assuming defaults comply.

Field-level protection and where it stops

TLS protects data between two endpoints. The receiving tool terminates the connection and handles plaintext, and the agent's model context holds whatever the agent was given. Transport encryption therefore says nothing about whether a tool should have received a full account number or a tax identifier in the first place.

Field-level techniques address part of this gap. Envelope encryption of selected fields lets an agent pass a value through a tool chain without any intermediate component reading it. Tokenization replaces a sensitive value with a surrogate that is meaningful only to a system that can resolve it. Both work when the tool only needs to route, store, or match the value.

They do not work when the tool must compute on the plaintext, such as a function that validates an identifier or a hosted tool that summarizes a document. In that case, the choice is between sending the minimum necessary plaintext over an encrypted channel, with a documented reason, and not calling the tool. Record that decision per tool. If encryption is infeasible for a particular third-party tool, document the exception with a review and approval record from the CISO, and confirm the wording against the current consolidated Part 500 text as of November 2026.

Where runtime policy enforcement complements encryption

Encryption protects data on the wire. Runtime policy enforcement decides what is allowed onto the wire. Applied to tool calls, it evaluates the arguments before they leave the agent runtime and the response before it returns to the model, then allows, redacts, or blocks the content, or escalates it for human approval.

Trussed enforces policy in the execution path on tool calls, including calls to MCP servers, and generates audit-ready evidence from that enforcement, mapped to NYDFS among other frameworks. Policy is enforced at runtime, not reviewed after the fact. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. This complements the encryption layers above and does not replace TLS, key management, or field-level protection.

The value for an examiner is a record of decisions rather than a record of traffic. A statement that a tool connection used TLS 1.2 shows the channel was protected. A record that a call containing an identifier was redacted before reaching a tool shows what the control permitted.