Copilot Studio connector governance for broker-dealers: deciding what to block, allow, or gate with human approval

Treat connectors as action surfaces

A connector is usually described as an integration. For a security engineer at a broker-dealer it is better understood as a set of actions an autonomous agent can take: read a customer record, query order data, post a message, write to a file store, call an arbitrary endpoint. Each action carries a different risk, even within one connector.

Five criteria make the sorting defensible and repeatable. Data sensitivity asks whether the action can touch customer records, trading and order data, communications archives, or firm files. Action type separates reads from writes and sends. External egress asks whether data can leave the firm's boundary. Authentication scope asks whose identity the call runs under and how broad that identity's permissions are. Reversibility asks whether a mistake can be undone, which a sent message or a changed record generally cannot.

An action that fails on egress and cannot be reviewed belongs in the block tier. An action that is read-only, narrowly scoped, and reversible can be allowed. Anything that sends, or writes to a system of record, and cannot be reversed belongs in the approval tier. Write the reasoning down for each assignment. FINRA Regulatory Notice 24-09 expects firms using Gen AI tools to have policies and procedures covering technology governance, including model risk management, data privacy and integrity, and reliability and accuracy. Documented tier rationale is the practical form that expectation takes for connectors.

Default tiers by connector category

These are starting positions to adjust against your own data classification and supervisory procedures. They are design defaults, not regulatory requirements.

• Email and messaging: Gate sends and external posts. Allow drafting and scoped reads. Outbound messages are communications, so they raise supervision and retention questions, and a sent message cannot be recalled.
• File storage and SharePoint: Allow reads on scoped libraries. Gate writes, deletions, and external sharing. Block broad tenant-wide access, which makes a single agent a bulk-exfiltration path.
• CRM: Allow scoped reads. Gate updates to customer records and any export. Customer data is the main sensitivity concern, and a write changes a record other people rely on.
• Databases: Allow read-only access to approved views. Gate writes. Block direct access to order and trading stores unless a specific, reviewed use case exists.
• HTTP, custom connectors, and MCP servers: Block by default. Move an endpoint or server to a higher tier only after review of its owner, authentication, data handling, and the actions it exposes. Their behavior is defined by whoever built them.
• Consumer and social services: Block. They offer no firm-controlled retention or review, and the egress is external by design.

Where native data policy ends

Power Platform data policies classify connectors into business, non-business, and blocked groups. That is a useful first layer. It stops an agent from combining a business connector with a non-business one, and it removes blocked connectors from use entirely. Treat it as a mandatory baseline.

The limit is granularity. The policy decision applies to the connector, not to the individual action or tool call at runtime. If a connector exposes both a harmless read and a consequential send, a connector-level decision must treat them the same. Allow the connector and you allow the send. Block it and you lose the read.

The second limit is content. A connector-level allow says nothing about what a particular call carries. FINRA's insider-threat guidance describes DLP controls that identify sensitive customer and firm data using rules, then block or quarantine its transmission by email, upload or download, file transfer, or other methods. That is a precedent for inspecting content at the point of egress rather than only permitting or denying a channel. For agents, the equivalent point is the tool call.

The third limit is evidence. A classification table shows what was configured. An examiner will also ask what each agent actually did, and a policy setting does not answer that.

Approval criteria and the evidence for each tier

Route an action to human approval when it meets any of these conditions: it sends to a recipient outside the firm, it changes a record of customer or order data, it cannot be reversed, or it moves a volume or type of data above a threshold you define. Approval gates also suit actions where the agent's output is a candidate communication under FINRA Rules 2210 and 3110. Notice 24-09 lists both rules, though it does not say approval is required, so this is a design choice you justify rather than a mandate.

Each tier needs its own evidence. For blocked connectors, keep the rationale, the review date, and a record of denied attempts. For allowed actions, keep a per-agent inventory of the connectors and individual actions permitted, the authentication scope used, and a log of the actions executed. For gated actions, keep the approver, the timing, the decision, and the exact payload that was approved or rejected.

Where an action sends or stores a communication or record, check the output against recordkeeping obligations. As of November 2026, FINRA's 2026 oversight report describes SEA Rules 17a-3 and 17a-4 as specifying the minimum records broker-dealers must make, how long they must be kept, and the formats allowed, with Rule 17a-4(f) setting format requirements for electronic recordkeeping systems. Decide early which agent outputs qualify as required records, and retain them accordingly.

Treat third-party and custom connectors as dependency risk. A joint statement from federal banking agencies, written for banks, notes that integration with third parties can amplify fraud, cybersecurity, and data privacy incidents. It is an analogy here, but the point carries over to external connectors.

Action-level enforcement in the execution path

Closing the gap between connector-level classification and action-level risk requires a decision point on each tool call. Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, at the level of individual interactions and tool calls. A call can be allowed, redacted, blocked, rate limited, or escalated for human approval. The decision is enforced at runtime, not reviewed after the fact.

In the tier model, this means a connector can be allowed for reads while its send action is escalated, and a call that carries sensitive content can be redacted or blocked before it leaves. The enforcement itself generates audit-ready evidence: what policy applied, what the agent attempted, and what was decided. That gives the three questions an examiner is likely to ask, namely what was permitted, what happened, and who approved it, a common record.

Trussed can be deployed self-managed in the customer's cloud, with configurable retention and data residency. Whether retained evidence and agent outputs meet the electronic recordkeeping format requirements of Rule 17a-4(f) remains a decision for the firm's own recordkeeping design. Trussed has run continuously in production at a regulated enterprise for more than 18 months.