Key facts
- The post-meeting skill in Claude for Financial Advisors presents the proposed CRM note, tasks, and opportunities as one table and asks for a single confirmation on the whole batch, rather than approving each item separately.
- The plugin's contributing guide states as a design rule that every write to an external system pauses for advisor approval, and that a skill must stop and ask before anything leaves the session.
- Anthropic's audit logs are available to Enterprise organizations, cover 180 days, and are exported by an Organization Owner or Primary Owner; the documented events are sign-ins, administrative changes, project and conversation lifecycle, and file uploads, and chat content is not exported.
- Claude Cowork can export a
tool_decisionevent carrying accept or reject and the source of the decision, but only when an administrator configures an OpenTelemetry collector, and prompt and response content is excluded unless separately enabled. - Rule 204-2(a)(7) requires an SEC-registered adviser to keep originals of written communications received and copies of those sent relating to advice, and Rule 206(4)-7 requires written policies reasonably designed to prevent violation of the Advisers Act and its rules; neither rule specifies how an internal approval must be evidenced, which is what leaves the question to the firm.
Every AI product sold into wealth management this year has made the same promise, in nearly the same words. The advisor stays in control. Nothing reaches a client without review. The machine proposes and the person disposes.
The promise is usually kept. Watch a demo of Claude for Financial Advisors and you will see it: the post-meeting skill reads a transcript, drafts the CRM note, lists the action items and the opportunities it heard, lays all of it out in a single table, and waits. Nothing is written until the advisor says so. The repository's design rules for anyone forking the plugin say it plainly: every write to an external system pauses for advisor approval, and a skill must stop and ask before anything leaves the session.
So the approval happens. The question this article is about is narrower and less comfortable. Six months later, when the advisor has left the firm and a client is unhappy about what was in that note, what does the firm have that shows a person reviewed it?
The moment is designed. The record is not.
Start with what the approval looks like from inside the workflow. The post-meeting skill asks for one confirmation on the whole batch. The advisor can approve all of it, some of it, or edited versions of any row, and the skill is explicit that batching is deliberate: one decision rather than a dozen. That is good product design. A tool that asks twelve times gets clicked through twelve times.
It is also, as a record, a sentence in a conversation. The advisor typed something like "yes, all of it except the second task." That utterance is the approval. It is the only place the decision exists, unless the firm does something else with it.
Notice a second detail in the same skill, easy to read past and awkward in a records context. The skill warns that in the CRMs it is written against, notes are never edited in place, only replaced by deleting and recreating them, which is why it wants the note right before it writes. That is a statement about those systems, not about Claude, and the skill raises it to argue for getting the draft right the first time. Read from a records angle it says something else as well: the ordinary act of fixing a note may leave no trace of the version that existed before, so the firm's evidence of what was first written and then corrected depends on what the firm kept outside that system.
What the audit log actually holds
Anthropic recommends its Enterprise plan for registered advisers because that plan carries audit logs. It is worth reading what those logs contain, because "audit log" is a phrase that does a great deal of work in vendor conversations and very little work in an examination.
Anthropic's documentation describes the log as available to Enterprise organizations, covering the past 180 days, exported by an Organization Owner or Primary Owner from the admin settings. The documented events are the ones you would expect of an account system: users signing in and out, invitations, administrative and SSO changes, projects created, renamed, and deleted, conversations created, renamed, and deleted, documents added to a project, files uploaded. Each row carries a timestamp and, where available, the actor, the affected entity, an IP address, and device and user-agent detail.
The documentation also states that the title and content of chats and projects are not exported in audit logs, only their unique identifiers.
Read those two facts together. The Enterprise audit log can tell a firm that a user signed in at a certain time, created a conversation, and uploaded a file. It is not designed to tell the firm what was in the conversation, what the model proposed, or that a person approved it. It is an account and access log, which is what it says it is and a genuinely useful thing to have. It is not a supervision record, and a firm that buys the Enterprise tier believing it has bought one has bought something else.
Two adjacent mechanisms are worth knowing before drawing that conclusion too hard. The same documentation notes that chat inputs and outputs are exportable separately, by a Primary Owner, through Anthropic's data export, and that audit events are also reachable through a compliance API. Neither is an approval record either. Both are worth understanding if the firm is assessing what the vendor holds and what it could produce on request.
There is a closer thing. Claude Cowork can export telemetry through OpenTelemetry, and among its events is tool_decision, which carries whether a tool call was accepted or rejected and the source of that decision, including whether a person accepted it once or permanently. That is much nearer to an approval event, and a firm that wants machine-readable evidence of review should know it exists.
Two conditions come with it. It only flows if an administrator configures a collector endpoint, which means standing up somewhere to receive and retain the events. And the content of prompts, responses, and tool arguments is excluded unless the firm separately enables capture. So the firm can have a record that a write was accepted at 2:14 p.m. by a named account, and which tool it was, without a record of what was in it, unless it chooses otherwise and accepts what that choice means for where client information goes.
Monitoring is offered on Team as well as Enterprise, which makes this less a question of which plan the firm bought than of whether anyone has done the engineering.
Three questions that locate the gap
Take one piece of AI-assisted client work the firm produced last month and ask three things about it.
Who approved it, and how would you show that without asking them? If the answer lives in a chat transcript, the firm's supervision evidence is a conversation, retained under someone else's retention schedule, in a system the firm does not control.
What did they approve, exactly? Batch approval makes this sharper. If an advisor approved four rows and edited a fifth, the firm's record should distinguish the version proposed from the version written. The CRM holds the result. The proposal usually survives nowhere.
Would the record still answer both questions after the vendor's retention window closes, or after the advisor is gone? A 180-day export is a fine operational tool and a poor books-and-records strategy for work whose relevant life is measured in years.
Firms that can answer all three have made approval into an artifact. Firms that cannot have made it into an event that happened.
Make approval a thing the firm owns
None of this requires waiting for a vendor. The practical fix is unglamorous and mostly clerical.
Decide which AI-assisted outputs are consequential enough that approval must be recorded, rather than trying to record every interaction. A recap email that goes to a client is on that list. A draft the advisor discarded is not.
For those outputs, file the approval where the work lives. The client record should hold what the system was given, the version proposed, the version that went out, who approved it, and when. That is four fields and a habit, and it is the same artifact the reconstruction test on this site scores.
Then check what the vendor's record actually holds. If the firm relies on the audit log, read the published event list and confirm it contains the event the firm believes it contains, and find out what the separate data export and compliance API would add. If the firm wants the tool decision telemetry, someone has to configure a collector and retain what it sends, which is an engineering decision with a records consequence, not a checkbox.
The vendor built the pause. What the pause leaves behind is the firm's to design, and it is the part that has to survive everything else.
Questions
Does Claude for Financial Advisors require advisor approval before writing to a CRM?
Yes. The post-meeting skill presents the proposed note, tasks, and opportunities as one table and writes only the rows the advisor approves, and the repository's design rules require a pause before anything leaves the session. The approval is a confirmation given in the conversation, so what the firm retains as evidence of it is a separate decision.
What does Anthropic's Enterprise audit log record?
Per Anthropic's documentation, sign-ins, invitations, administrative and SSO changes, project and conversation lifecycle events, and file uploads, covering 180 days and exported by an Organization Owner or Primary Owner. The title and content of chats and projects are not exported, only their identifiers, so the log shows access and activity rather than what was proposed or approved. Chat inputs and outputs are exportable separately, and audit events are also reachable through a compliance API.
Is there any machine-readable record of an approval?
Claude Cowork can export a tool_decision event with accept or reject and the decision source through OpenTelemetry, on Team and Enterprise plans. It requires an administrator to configure a collector, and prompt, response, and tool-argument content is excluded unless separately enabled, so the firm can capture that a decision occurred without capturing what it was about.
What should a firm keep for a consequential AI-assisted output?
What the system was given, the version it proposed, the version that reached the client, the name of the person who approved it, and the time. Filed in the firm's own client record rather than the vendor's history, so it survives the retention window, the subscription, and the advisor's departure.
Advisor Insights provides general professional information, not individualized investment, legal, cybersecurity, or compliance advice. Product descriptions are drawn from Anthropic's public repository and documentation as of September 2026 and may change; verify current behavior and plan terms before relying on them. Which records a firm must keep under Rule 204-2, and what constitutes reasonably designed supervision under Rule 206(4)-7, is specific to each firm, its registrations, and its approved systems. U.S. context, current as of September 2026.
Primary sources
General information from ValaisOS LLC, not legal, compliance, tax, or investment advice. Confirm requirements for your firm with counsel. See Terms of Use.