Compliance Guide
AI Agent Governance for Wealth Management RIAs
RIAs deploying AI agents for research, portfolio analysis, or client communications must govern those agents under existing Rule 206(4)-7 supervisory procedures, Rule 204-2 recordkeeping obligations, and Regulation S-P safeguarding requirements. This requires runtime controls, not just pre-deployment testing: distinct agent identity, least-privilege permission scoping, and tamper-resistant tool-call logging capable of supporting examination requests.
Runtime controls needed for defensible agent deployment
Five capabilities form the baseline for governing AI agents that touch client data, research, or communications workflows.
Agent identity
A distinct, auditable identity for each AI agent, separate from the human user or shared system account, so specific actions can be attributed to a specific agent instance or task.
Least-privilege permission scoping
Defined limits on which systems (CRM, portfolio management, trading platforms) and data categories an agent may access for a given task, rather than broad standing access.
Tool-call and data-access logging
A record of every tool call and data access event made by an agent, retained in a format consistent with recordkeeping retention requirements.
Separation of reasoning from execution
Higher-risk actions, such as anything resembling a trade suggestion or outbound client communication, gated by a policy enforcement point before execution.
Tamper-resistant, retrievable records
Logs structured so they can be produced in a form suitable for regulatory examination requests without gaps or reconstruction gaps.
Evaluation criteria for governance controls
Use these questions to assess whether a governance approach, in-house or vendor-provided, meets the bar for defensible AI agent deployment.
- Confirm agent actions can be tied to a specific identity, session, and task rather than a shared credential.
- Verify permission scopes are enforced at runtime, not only checked during pre-deployment testing.
- Require complete logging of tool calls and data access, not just final agent outputs.
- Confirm human-in-the-loop checkpoints exist for outputs that touch recommendations or client communications.
- Ensure controls integrate with existing Rule 206(4)-7 procedures rather than operating as a standalone system.
AI agents are a supervisory extension, not a new regulatory category
RIAs already operate under a well-established compliance architecture: Rule 206(4)-7 requires written policies and procedures reasonably designed to prevent violations of the Advisers Act, reviewed at least annually. Rule 204-2 requires firms to make and preserve records supporting the investment advice given to clients. Regulation S-P requires safeguards for customer records and information. None of these rules were written with AI agents in mind, but none of them exempt AI agents either. When an agent conducts research that informs a recommendation, drafts client communications, or accesses account data to support portfolio analysis, that activity falls within the same supervisory and recordkeeping perimeter that already governs human-performed work. The practical question for compliance leaders is not whether a new AI-specific rule applies, but whether existing procedures were designed with enough specificity to cover autonomous, tool-using systems. In most firms, they were not.
Why model-risk and vendor-risk frameworks fall short
Traditional model-risk management was built for deterministic or predictive models with fixed inputs and outputs, validated at a point in time before deployment. Vendor-risk frameworks assess a third-party product during procurement or periodic review. Neither approach accounts for an agent that makes a sequence of tool calls, retrieves data from multiple systems, and takes actions during a live session. A model validated as accurate six months ago tells a compliance team nothing about what an agent actually accessed or did on a given client's account yesterday. This is the structural gap: AI agents require governance that operates continuously, at runtime, rather than governance that operates once, at deployment or renewal.
What an audit trail means for an agent, not a person
A human-generated record typically documents a conclusion: a note, an email, a recommendation memo. An AI agent's audit trail needs to capture more than the final output. It needs to reconstruct the sequence of tool calls the agent made, the data sources it queried, and the inputs that shaped its output. If an examiner asks how a client received a particular piece of portfolio commentary, the firm needs to show not just the commentary but the chain of actions that produced it, including what CRM records or market data the agent accessed and under what permission scope. Without this level of detail, a firm cannot demonstrate the kind of supervisory control that Rule 206(4)-7 procedures are designed to evidence.
Operational and governance decisions firms need to make
Deploying agents defensibly requires firms to work through a set of concrete decisions rather than adopting generic AI policy language. Compliance and risk leaders should map which existing supervisory procedures already extend to AI-agent-assisted workflows and identify where agent-specific gaps exist. They should determine whether outputs used in client communications or recommendations fall within Rule 204-2's preservation scope, and whether agents that touch client PII trigger Regulation S-P obligations that current information security programs were not built to address. Firms should also define where human review is required before an agent-influenced recommendation reaches a client, since fiduciary duty and best-interest obligations apply to that output regardless of whether a person or an agent produced the underlying analysis. Finally, AI agent controls should be reviewed through the same annual compliance testing cycle required for other supervisory procedures, not as a separate, parallel process that risks falling out of sync with the firm's broader compliance program.
Where Trussed AI fits
Trussed AI provides runtime governance and security for enterprise AI agents, covering agent identity, least-privilege permissioning, tool approval workflows, and audit logging. For RIAs, this class of control addresses the specific gap described above: the need to enforce and record agent behavior during live operation, not only at model validation or vendor onboarding. Runtime policy enforcement and MCP security controls are relevant where agents call external tools or data sources as part of research, portfolio analysis, or client communication workflows. These are architectural capabilities, and firms should evaluate any governance platform, including Trussed AI, against the specific supervisory and recordkeeping obligations described in this guide rather than generic AI risk language.
Governance gaps introduced by AI agents
Four areas where existing controls, designed around human activity, typically do not extend cleanly to autonomous agents.
Attribution
Agent actions must be traceable to a specific agent instance and task, not just a shared system account.
Recordkeeping
Agent-generated outputs feeding advice or client communications may fall within Rule 204-2 scope.
Runtime enforcement
Static model validation does not catch policy violations that occur during live, sequential tool calls.
Data access
Agent access to client PII implicates Regulation S-P safeguarding obligations the same as human access.
Evaluate runtime governance for AI agents in your firm
Compliance leaders can use the criteria in this guide to assess whether current AI agent deployments meet supervisory and recordkeeping obligations.
Talk to an Expert