Preventing Copilot Studio Knowledge Sources from Retrieving Restricted Client Documents

Where restricted documents can be exposed

A Copilot Studio agent grounds its answers on knowledge sources such as SharePoint, Dataverse, uploaded files and connectors. Each source adds a point where an access decision is made, or should be made. A restricted client document is exposed when any one of those decisions is wrong, because the agent will summarize whatever retrieval hands it.

Four failure patterns account for most cases. First, overshared content: a document is technically readable by a broad group, so retrieval treats it as fair game even though the business never intended it. Second, broad service identities: if a source is queried with a shared or elevated identity rather than the end user's, document-level restrictions no longer apply to the person asking. Third, authentication settings: an agent that does not establish who the user is cannot apply user-level restrictions at all. Fourth, inconsistent label handling: a sensitivity label only helps if every stage of retrieval and response honors it.

This maps to a general principle in FTC and NIST guidance: not everyone needs unrestricted access to stored information, and access should be limited to authorized users. An agent is another consumer of that data, and it should be held to the same rule as a person.

Residual gaps to plan for

Even a well-configured agent leaves gaps that configuration alone does not close. Permissions describe who may open a document, not whether a particular answer is appropriate. An authorized user can still ask a question whose response combines content in a way that exposes more than intended, or paste restricted details into a prompt.

Uploaded files deserve separate attention. They sit outside the permission model of the repository they came from, so a file uploaded as a knowledge source is available to the agent on the agent's terms, not the original repository's. The same applies to any copy of a restricted document placed in a less controlled location.

Label and policy coverage is also uneven in practice. Content created before labeling was introduced, content in connectors that do not carry labels, and documents moved between systems can all escape the controls you assume are in place. Finally, change is constant. A permission edit, a new knowledge source or a channel change after publishing can alter exposure without anyone revisiting the original review.

Attribute-based conditions, such as time of day or point of origin, are recognized in NIST guidance as ways to restrict access. Whether a given retrieval path supports them should be tested rather than assumed.

Enforcing policy at runtime and producing evidence

Configuration controls decide what an agent can reach. They do not decide, interaction by interaction, what is allowed to leave in a response or pass through a tool call. That is the gap runtime enforcement addresses.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Its scope is individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, with outcomes such as allow, redact or block. For restricted client content, that means a response or tool call containing material that policy prohibits can be redacted or blocked before it is delivered, even where an upstream permission or label did not stop it.

Each enforcement decision produces audit-ready evidence of what was allowed, redacted or blocked. This answers a question native configuration review often cannot: what actually happened on a given interaction. Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency, and is used by regulated enterprises in insurance, pharma, healthcare and education.

Runtime enforcement complements source permissions, authentication and labels. It is not a substitute for fixing oversharing or for scoping knowledge sources correctly.