Implementation Guide | Financial Services

    How to Capture LangChain Agent Outputs for SEC Rule 17a-4 WORM Retention

    Treat capture as an execution-path problem. Inventory agent artifacts, have counsel and records management decide which are records, capture them at points that give a complete, ordered, time-stamped view, structure each record with integrity and retention metadata, and deliver it to storage that meets either the WORM or the audit-trail alternative under Rule 17a-4. LangChain does not produce retention-grade records by default, so the pipeline, its verification and its retrieval path must be built.

    What the rule requires and what you must build

    Rule 17a-4 governs what a broker-dealer preserves and how it stores it. It does not tell you how to instrument an agent framework. As of November 2026, a firm using an electronic recordkeeping system must meet either the audit-trail requirement or the WORM requirement. The audit-trail alternative, added by the 2022 amendments, requires preserving the record for its retention period with a complete time-stamped audit trail that includes all modifications to and deletions of the record or any part of it. The WORM alternative requires preserving records exclusively in a non-rewriteable, non-erasable format. Firms may use one option for all records or mix them by record class.

    Several other provisions shape the engineering work. The system must verify automatically the completeness and accuracy of the processes for storing and retaining records. The amendments require a backup set of records or redundant equivalency. Records, and the audit trail where applicable, must be furnished in a reasonably usable electronic format when a Commission representative asks. Retention under 17a-4(a) is at least 6 years for the records it covers, with the first two years in an easily accessible place.

    The rule text does not classify agent artifacts. Business communications are a record category, including copies of communications sent and originals of those received that relate to the firm's business. Whether an agent's final output, an intermediate step or a tool call falls within a required category is a determination for your counsel and records-management function. Build the pipeline so that the answer can change without re-architecting it.

    Inventory candidate records before choosing capture points

    Start with an artifact inventory for each agent. Typical candidates are the user or system input, the final output delivered to a person or downstream system, intermediate reasoning and planning steps, tool inputs and tool outputs, retrieved context, and run metadata such as agent version, prompt template version, model identifier and the identity of the caller.

    For each artifact, record a classification decision, who made it and when, the applicable retention period, and whether it is held under the WORM or the audit-trail option. Keep this register under change control. It is the document an examiner will ask for first, and it keeps engineering from capturing everything indefinitely or, worse, discovering a gap after a reclassification.

    Capturing more than counsel classifies as records is a legitimate design choice, but it carries storage, access and privacy consequences. Because WORM storage cannot be edited, sensitive content written to it cannot be removed later. Decide redaction before the write, not after, and store the redaction state with the record.

    Capture points in the execution path and their trade-offs

    No single hook gives a complete record. Most designs combine two layers and reconcile them. The trade-offs below are general design considerations. Validate each against the framework version you run, including how it behaves under streaming, retries and concurrent branches.

    • Callback handlers: Run inside the framework and see chain, model and tool events as they fire, which makes them the natural source for intermediate steps. Risks: events from concurrent or nested runs can interleave, so each needs a run identifier and sequence number. Coverage is limited to code that emits events, and a handler failure must not be silent.
    • Middleware at the service boundary: Sees every request and final response regardless of agent internals, which suits input and output capture and caller identity. It does not see intermediate steps or tool calls made inside the run, so it cannot be the only layer.
    • Tool wrappers: Capture the exact arguments sent to a tool and the exact response returned, at the boundary where side effects occur. Coverage is only as complete as the set of wrapped tools, so an unwrapped tool is a gap. Wrappers are also a natural place to apply policy before a call executes.
    • Application logs and traces: Useful for reconciliation and debugging. They are typically mutable, sampled or truncated, and not designed for retention, so treat them as a cross-check rather than the system of record.

    Design a record schema with integrity and retention metadata

    Write one immutable record per event, not one blob per run. Per-event records make completeness testable: if a run declares twelve steps, twelve records must exist. Serialize to a stable, documented format so records can be produced and read years later without the original code.

    For tamper evidence, hash each record's canonical content and chain it to the previous record in the same run by including the prior hash. Anchor the run's final hash in a separate manifest record. Hashing does not replace WORM or audit-trail storage, but it lets you show that content you produce today matches what was captured. Use a trusted, synchronized time source and store both event time and write time.

    If you choose the audit-trail option, the store must itself record every modification and deletion with a timestamp. An append-only log of events is not enough. You need a lifecycle model in which corrections, legal-hold changes and deletions after the retention period are recorded as events.

    • Identifiers: record ID, run ID, step sequence number, parent step ID, agent and version
    • Timestamps: event time and storage write time from a synchronized source
    • Content: input, output or tool arguments and response, plus a redaction state flag
    • Integrity: content hash, previous-record hash, run manifest hash
    • Retention: record class, retention period, retention start date, storage option used
    • Context: caller identity, model identifier, policy decision and policy version

    Deliver to WORM or audit-trail storage and prove it works

    Write records through a queue or outbox so a downstream failure does not drop events or block the agent without notice. Deliver to storage configured for non-rewriteable, non-erasable retention, or to an audit-trail system that meets the alternative. Confirm the configuration against the rule text and your firm's own compliance basis. A storage vendor's description of its product is not regulatory certification.

    Build the verification the rule calls for. A scheduled job should reconcile expected records, derived from run manifests and tool-call counts, against stored records, then recompute hashes on a sample or in full and alert on any mismatch. Keep the output of each check as evidence. Plan the backup set or redundant equivalent and test restoration, not just replication.

    Test retrieval as an examiner would use it. Index by run ID, date, agent, caller and record class so a request can be scoped quickly, and export records with any audit trail in a reasonably usable electronic format. Keep the first two years of records in an easily accessible tier. Enforcement history shows why this matters: a FINRA matter described a firm that failed to maintain roughly 8.7 million electronic brokerage records in WORM format over about a dozen years, and another involved failure to capture deleted electronic communications. Completeness and format are both examination topics.

    Where runtime policy enforcement fits

    A capture pipeline shows what an agent did. Examiners and model risk management reviewers also ask what the agent was allowed to do. Recording the policy decision beside each tool call, including the policy version and whether the call was allowed, redacted or blocked, answers both questions in one record.

    Trussed enforces policy in the execution path for agents, models and tool calls, and its enforcement produces audit-ready evidence of each interaction and tool call. Enforcement happens at runtime, not by review after the fact, and the decisions can be written into the record schema above. Trussed is deployed self-managed in the customer cloud with configurable retention and data residency. It is not a WORM storage product and does not provide regulatory certification, so storage selection, the WORM or audit-trail decision and the classification of records remain with your firm.

    Keep three questions on your readiness list: which artifacts counsel has classified as records and why, which option each class uses and where that is documented, and how you demonstrate that every execution step was stored, with modifications and deletions logged.

    From agent execution to retained record

    Capture

    Callbacks, middleware and tool wrappers emit events from the execution path.

    Structure

    Each event becomes a record with identifiers, timestamps, hash and retention tags.

    Retain

    Records go to WORM storage or an audit-trail system, with a backup set.

    Produce

    Records and any audit trail export in a reasonably usable electronic format.

    Review your agent capture design with an expert

    Walk through capture points, record schema and policy evidence for your LangChain agents.

    Talk to an Expert
    Next step

    How does your AI governance program compare?

    See where your program has gaps in less than 2 minutes.