Scoping Copilot Studio Connector Permissions to Least Privilege for Broker-Dealer Agents

Why connector least privilege is a layered problem

Broker-dealer agents are connected to systems that hold customer account data, trading and order information, and supervisory records. The risk is rarely the model alone. It is the identity the connector uses and the actions it exposes. A commonly cited example of excessive permissions is an extension meant only to read data that connects to a database with an identity holding SELECT plus UPDATE, INSERT and DELETE. The agent needs one of those four rights, and the other three are exposure.

Two layers are worth separating. The first is provisioning-time scoping: which connector, which credential, which resources, which environment. The second is per-request authorization at execution: whether this specific tool call, with these parameters, for this user, should proceed. Platform configuration, including Power Platform data loss prevention policies, environment boundaries, connection authentication settings and Entra ID permissions, belongs mostly to the first layer. The second layer has to sit in the path of the call itself.

The guidance is consistent on the standard to apply. Data access by agents should follow the same least-privilege and per-request authorization principles used for human users and application code. NIST SP 800-53 Rev. 5 frames least privilege as allowing only the accesses necessary for assigned tasks, for users and for processes acting on their behalf. An agent is such a process.

Step-by-step: narrowing a Copilot Studio agent's connector scope

Work through the steps below per agent, not per tenant. An agent that serves a supervisory review workflow needs a different scope from one that answers operations questions, even when both use the same connector.

• 1. Inventory connectors and actions: List every connector the agent uses, each action it can invoke, the credential behind it, the named owner and the update schedule. Treat connectors as part of the supply chain.
• 2. Compare granted and required permissions: For each connector, set the permissions held by the identity against the minimum the task needs. Read-only use cases should not hold write or delete rights.
• 3. Choose the identity pattern: Decide whether each action runs as the end user or under a shared or maker-provided credential. Document the reason for every exception.
• 4. Narrow scope in the platform: Apply DLP connector classification, environment separation and Entra ID permission and access settings. Grant access to named resources, such as specific folders rather than an entire drive.
• 5. Define sensitive actions and thresholds: Decide which actions require human approval, which risk thresholds trigger escalation, and who receives the escalated decision.
• 6. Test the boundary: Attempt actions outside the intended scope and confirm they fail at the configuration layer or are stopped at runtime. Record the results.

Choosing authentication and identity patterns

The central question is whose permissions an agent's connector action inherits. When actions run in the end user's context, downstream systems see the user's own entitlements, so the agent cannot reach more than the person using it. When actions run under a maker-provided or shared credential, every user of the agent effectively acts with that credential's rights. If the credential spans multiple users or sensitivity tiers, the agent becomes a path around entitlements that were designed for individuals.

For agents touching customer or trading-related data, prefer end-user context and treat shared credentials as an exception that needs a documented rationale, a narrow scope and an owner. Keep the maker identity, used to build and publish the agent, separate from the runtime identity, used when the agent acts. Makers often need broad rights to test. Those rights should not carry into production behavior.

Two further principles from NIST's agent identity tenets apply. Zero standing privilege means an agent holds no persistent rights while idle. Separation of duties means an agent cannot assume conflicting privileges. In practice, avoid a single agent identity that can both initiate and approve an action. One caveat is worth planning for: an agent's required actions may not be fully predictable at deployment, which makes a one-time permission grant hard to size correctly and argues for a second control at runtime.

Where configuration controls end and runtime enforcement begins

Configuration controls answer a static question: is this connector, in this environment, with this credential, allowed to exist? For each control you rely on, confirm what it can express. Determine whether it distinguishes a read action from a delete action on the same connector, and whether it can limit the fields or records returned. Where a control works at the connector or environment level only, treat the remaining gap as one that action-level and data-level policy has to close.

Runtime enforcement answers a dynamic question about a single tool call: should this action, with these parameters, for this user, in this context, proceed now? Four outcomes cover most needs. Allow the call when it falls inside policy. Redact fields from the response, for example account identifiers a task does not require. Block calls that exceed scope, such as a write on a read-only task. Escalate for human approval when the action crosses a defined risk threshold.

Per-tool least privilege matters as much as per-connector scoping. Guidance for tool servers advises enforcing least privilege for each server and each tool, with human approval for sensitive actions. Escalation also needs technology that can route the decision to the correct authority, and thresholds should be documented and owned because they reflect organizational risk tolerance.

Evidence examiners and model risk reviewers are likely to ask for

Examiner, model risk and supervisory reviewers will generally want to see two things: what the agent was permitted to do, and what it actually did. Permitted scope is a design artifact. Actual behavior is operational evidence. Retaining only one leaves the other unproven.

For permitted scope, retain the connector inventory with credentials, owners and update schedule, the identity pattern chosen for each action with its rationale, the granted permissions compared with the task minimum, and the policy that defines sensitive actions, thresholds and escalation authorities. Version these records so a reviewer can see the configuration in force on a given date.

For actual behavior, retain a record of each tool call: the agent, the acting identity, the action and target, the policy decision (allowed, redacted, blocked or escalated), the approver where one applied, and the outcome. Platform audit sources can show that configuration changed and that activity occurred. Confirm for your tenant whether they also record per-call policy decisions and data-level outcomes. If they do not, that evidence has to come from the enforcement point itself. Set retention periods with your compliance function, and keep the records in a form a reviewer can read without engineering help.

Runtime policy on tool calls as a complement to native controls

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and each decision to allow, redact, block, rate limit or escalate for human approval produces audit-ready evidence. It is designed to sit alongside native Microsoft configuration controls, not replace them.

The platform has run continuously in a regulated enterprise for more than 18 months, with 100+ models under one policy plane. Its customers are in insurance, pharma, healthcare and education, and insurance is where it is deepest. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. Teams evaluating the approach in this guide can use the questions above to test any enforcement option: does it act on the individual call, and does it leave evidence a reviewer can use?