Copilot Studio Custom Connectors vs Prebuilt Connectors: Permission Risks for Banks and Broker-Dealers

Why the connector type changes the permission question

A Copilot Studio agent acts on enterprise systems through connectors. Each connector is a path to data and to actions, and the agent inherits whatever that path allows. For a bank or broker-dealer, that can include customer records, trading data and books-and-records systems. The relevant question is not only whether a connector is approved, but what the agent can do through it and under whose identity.

Prebuilt connectors are published by Microsoft. Custom connectors are built by the institution or a vendor to wrap an internal or third-party API. The two differ in how permissions are scoped, how authentication and consent are handled, who owns and maintains the API definition, and how far Power Platform data loss prevention policies can control them. Those differences determine which risks an architect has to design for.

Responsibility does not move with the connector. OCC guidance for community banks states that engaging a third party does not diminish a bank's responsibility to operate safely and soundly and to comply with applicable legal and regulatory requirements, as if the bank performed the activity itself. Using a Microsoft-published connector or a vendor API leaves accountability with the institution.

Side-by-side: permission and control surfaces

The comparison below is organized around the surfaces an approval review has to cover. It describes the control posture each type typically creates, not a feature ranking.

• Authentication and connection sharing: Prebuilt: the publisher defines the sign-in model, so the review focuses on whether connections are delegated to a user or shared across users. Custom: the institution chooses and implements the model against its own or a vendor's API, so the review also covers credential storage, consent and the identity of record.
• Permission scope: Prebuilt: scope is set by the publisher and the connection grant, and the institution can only choose whether to accept it. Custom: scope is a design decision, and an API credential broader than the agent's purpose becomes the agent's effective reach.
• Action-level exposure: Prebuilt: the available actions are fixed by the publisher and may exceed the agent's use case. Custom: the institution decides which operations to expose, which allows tighter exposure but also allows read, write and delete operations to be included by default.
• DLP classification: Both types are subject to connector-level classification and grouping. Policy decisions are made per connector, so one approved connector can carry actions with very different sensitivity.
• Change control: Prebuilt: definition changes originate with the publisher, outside the institution's change process. Custom: changes to the API or its definition originate inside or near the institution, and an unreviewed change can alter what an agent can reach.
• Ownership and evidence: Prebuilt: ownership of the definition sits with the publisher and ownership of the use sits with the institution. Custom: the institution owns both, including the approval record. Neither type, on its own, records an enforcement decision for each tool call.

Permission risks specific to each type

With prebuilt connectors, the typical failure is a mismatch between the connection and the purpose. A shared connection can let many agent users act under one identity, which weakens attribution. A delegated connection can let an agent reach everything the signed-in user can reach, which is usually broader than the agent's documented use case. The institution cannot narrow the publisher's action set, so it has to narrow use through agent design and surrounding controls.

With custom connectors, the risk moves toward authorship. An over-broad action, a credential with excess scope, or an OpenAPI definition that exposes administrative operations can let an agent reach customer, trading or books-and-records data beyond its intended purpose. Because the API sits behind the institution's own or a vendor's boundary, the connector should be treated as a third-party access path. Interagency third-party guidance points to the extent to which a third party applies controls that limit access to the banking organization's data and transactions, such as multifactor authentication, end-to-end encryption and secure source code management. Those are sensible review criteria for any API a custom connector wraps.

The OCC's 2026 framework for bank use of advanced AI lists authorized users and use cases as a component, and ties the consequence of error to factors such as single transaction versus portfolio-level decisions and low-dollar versus high-dollar thresholds. That supports scoping each connector action to a defined purpose and setting review depth by impact. Model risk management guidance is supervisory guidance without the force and effect of law, and banks may apply some or all of its principles based on risk, so these are expectations to design toward rather than prescribed connector controls (as of November 2026).

Where platform-native controls stop

Power Platform data loss prevention policies work at the level of connector selection and classification. They answer which connectors an agent may use and how they are grouped. That is a necessary control, and it is the right place to block connectors that should never touch regulated data.

It does not answer a different question: given an approved connector, should this specific call, with these parameters and this data, proceed right now? Platform-native controls do not enforce policy on individual tool calls at runtime, and they do not produce evidence of each enforcement decision. Examiners expect firms to show what an agent was permitted to do and what it did. Reconstructing that from activity logs after the fact is weaker than a record created when the decision was made.

This is a separate layer, not a replacement. Connector approval, least-privilege scopes and change control reduce what is possible. Runtime enforcement governs what actually happens on each call. A sound design uses both.

Runtime enforcement of tool calls with Trussed

Trussed enforces policy in the execution path for individual interactions and tool calls across models, agents, tools and MCP servers. For a connector-based agent, that means a call can be allowed, redacted, blocked, rate limited or escalated for human approval, enforced at runtime, not reviewed after the fact. A request that falls outside the approved use case can be stopped, and a response containing data the agent should not see can be redacted before it is returned.

Each enforcement decision generates audit-ready evidence, so the record of what the agent was permitted to do and what it did comes from enforcement itself. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency. It has run in continuous production in a regulated enterprise for more than 18 months, and operates 100+ models under one policy plane.

Trussed's deepest experience is in insurance, a regulated financial sector. It does not claim bank or broker-dealer deployments, and the approval criteria above stand on their own whether or not a runtime layer is added.