Copilot Studio Agents and Dataverse Customer Records: Reg S-P Access Controls

Start with the identity at each hop

A Copilot Studio request to Dataverse crosses several hops: the requesting user, the agent, a connector or tool, and Dataverse itself. Dataverse evaluates the identity it receives at the last hop. It does not evaluate who the original requester was or what task the agent is performing. If the connector presents a different identity from the requester, the requester's permissions are no longer the ones being applied.

The practical decision is which identity each tool call uses: the maker's credentials, the authenticated end user, or a service principal. The choice determines which security roles and row-level permissions apply. Any shared identity, whether a maker account or a service principal, presents the same permissions to Dataverse regardless of who is asking, unless the design carries requester context through. For customer records, that is the first thing to document per agent and per tool.

The regulatory frame is technology-neutral. As of November 2026, 17 CFR 248.30 requires covered institutions to maintain written policies and procedures addressing administrative, technical and physical safeguards. Those policies must be reasonably designed to protect against unauthorized access to or use of customer information that could result in substantial harm or inconvenience to a customer. The rule does not name agents, Dataverse or Copilot Studio, so the mapping below is an architect's interpretation, not a regulatory requirement.

Reg S-P control-to-configuration mapping

The left column states a safeguards expectation from 17 CFR 248.30, or an FTC analogue where labeled. The right column is a configuration decision that supports it. Whether a configuration satisfies the rule is a determination for counsel.

• Written safeguards policies (248.30): A per-agent access record naming identity mode, roles, scoped columns and rows, environment and an accountable owner.
• Protect against unauthorized access or use (248.30): Requester-scoped identity where feasible, with roles and column and row scoping applied to the task.
• Access limited to need (FTC analogue): Task-scoped roles, with separate agents for separate tasks instead of one broadly privileged agent.
• Assess scope of an incident (248.30): Retained auditing and telemetry that identify which systems and types of customer information an agent touched.
• Service provider oversight (definition in SEC release): An inventory of components in the agent path operated by third parties, reviewed with counsel for applicability.
• Periodic review (FTC analogue): A scheduled review of roles, connector identities and DLP policies for each agent.

Where native controls stop

Dataverse security roles, business units, column-level security and row scoping are the right foundation, and they should be configured first. They govern what an identity can read or write. They answer the question of reach.

They do not by themselves enforce policy on each agent interaction and tool call. A role that permits reading a customer table permits it for every request that identity makes, whether the prompt was routine or manipulated. Roles also do not distinguish between a tool call that returns an account balance and one that returns a full record, if both fall within the same permissions.

The evidence gap follows the same line. Native auditing can show that a record was accessed. The incident response program required by 17 CFR 248.30 must assess the nature and scope of an incident and identify the systems and types of customer information accessed without authorization. That is easier when you hold a per-interaction record of what the agent was permitted to do, set beside what it did. Reconstructing that after the fact from separate logs is slower and less certain than capturing it when the call is made.

Enforcing policy in the execution path

Trussed addresses the gap above. It enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. For a call that reads or writes customer records, policy can allow it, redact fields, block it, rate limit it, or escalate it for human approval. The decision is enforced at runtime, not reviewed after the fact.

Enforcement also generates audit-ready evidence of what the agent was allowed to do and what it did. That evidence is a record for the regulated enterprise, and it complements Dataverse roles and auditing instead of replacing them. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. Trussed has run in continuous production in a regulated enterprise for more than 18 months.

Neither native controls nor runtime enforcement amounts to a conclusion that an institution complies with Regulation S-P. That determination rests on the institution's written policies, its program as a whole and its counsel.