Building FINRA-Examinable Audit Trails for OpenAI Agents SDK Handoffs and Tool Calls

Which FINRA obligations bear on agent handoffs and tool calls

FINRA states that its rules are intended to be technologically neutral and continue to apply when firms use generative AI or similar technologies, as they do for any other tool. There is no separate rulebook for agents. The existing supervision and recordkeeping framework is the standard an examiner will use.

Rule 3110 requires a member firm to have a reasonably designed supervisory system tailored to its business, including written procedures reasonably designed to achieve compliance. Rules 3110 and 3120 together require firms to establish, maintain and enforce supervisory systems and written supervisory procedures reasonably designed to comply with their recordkeeping obligations. Those recordkeeping procedures must be reviewed and updated periodically, and supervisory control procedures must test and verify that they are reasonably designed.

FINRA's Books and Records guidance adds the shape of an acceptable electronic record. It describes a complete, time-stamped audit trail, with the information needed to preserve security, signatures and data so the record is authentic and reliable and the original can be re-created if the record is modified or deleted. The system must also be able to download and transfer a record and its audit trail in a human readable format and a reasonably usable electronic format, along with the information needed to locate the record.

FINRA's 2026 oversight report defines AI agents as systems capable of autonomously performing and completing tasks on behalf of a user, and it names two risks that matter here: agents acting without human validation and approval, and agents acting beyond the user's actual or intended scope and authority. Handoffs and tool calls are where both risks become actions. As of November 2026, the report advises firms to consider compliance when evaluating tools before testing and deployment, which makes the audit design an architecture decision, not a later add-on.

Mapping SDK primitives to the record an examiner expects

The OpenAI Agents SDK organizes agent applications around agents, handoffs, tools, guardrail checks and tracing. Each primitive touches a consequential action, but each maps to a different part of the record. The table pairs them with the elements an examiner would look for. The NIST audit record content categories (event description, time stamp, identities, resources involved, information objects accessed, event type, success or failure) serve as a reference checklist here. They are guidance, not FINRA requirements.

• Agent: Actor identity. The record should name the agent, its configuration version and the user or entity that initiated the task.
• Handoff: Delegation. The record should show the sending and receiving agents, the context passed, and the scope of authority carried to the receiver.
• Tool call: Action. The record should hold the tool, the arguments, the result or error, and the system or data resource touched.
• Guardrail check: Decision. The record should show which policy evaluated the action, its version, and whether the outcome was allow, redact, block or escalate.
• Tracing: Sequence and timing. Useful for reconstructing a run, but it needs policy linkage and durable retention to become a record.
• Human approval: Supervision. The record should show who approved, what they saw and when, tied to the specific action.

Where built-in tracing stops short of the examination standard

Native SDK tracing and application logs are not designed as durable, policy-linked records. That is a statement about design intent, not a defect. Tracing exists so developers can see what a run did. An examiner asks a different question: what was this agent permitted to do, and what did it do?

Three gaps follow from that difference. The first is policy linkage. A trace can show that a tool was called, but unless the application adds it, nothing ties that call to a specific policy, policy version and decision. The second is the decision itself. If a check runs inside application code, the outcome is only as reliable as the code that records it, and a blocked or redacted action may leave no trace of why. The third is the retention standard. The Books and Records guidance expects authenticity, re-creation of the original if a record is modified or deleted, and export on request. Whatever the SDK captures by default, a firm has to test it against those properties before relying on it. Tamper resistance in particular is an open question in current NIST work on agent identity, which asks how agents can log actions and intent in a tamper-proof and verifiable manner. Treat any claimed mechanism as something to be demonstrated, not assumed.

For supervisory procedures, the practical consequence is that reconstruction after the fact is a weak position. If the policy applied has to be inferred from code and logs during an examination, the firm is arguing about what probably happened.

Evaluating an enforcement layer for agent audit evidence

Five questions separate an enforcement layer that produces evidence from one that adds another log. Does enforcement happen in the execution path for each tool call and handoff, and does the enforcement point write the decision record itself? Which fields does each record contain, and how do they compare with the schema above? How are records protected against alteration, and can the vendor show authenticity and re-creation of the original? Can a record and its audit trail be exported in human-readable and reusable electronic formats, and located on request? What are the retention, data residency and deployment options, and who controls the evidence store?

Self-managed deployment and configurable retention matter because the firm, not the vendor, answers to the examiner for the records. Backup and recovery of retained evidence belong in the design as well. If the enforcement layer or the model is third-party, review FINRA's guidance on supervisory obligations for outsourcing to third-party vendors.

Trussed is one example of this category. It enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate-for-approval outcomes at the level of individual interactions and tool calls. Audit-ready evidence is generated by that enforcement and mapped to NIST, among other frameworks. It can be deployed self-managed in the customer's cloud, with configurable retention and data residency. Insurance, a regulated financial sector, is where Trussed is deepest. The evidence is produced for any regulated enterprise that must show an examiner what its AI was allowed to do and what it did, and the evaluation criteria above apply to any vendor, including Trussed.