Scoping what an agent can read sets the ceiling on every exfiltration story in this wiki. The trap is that the two mechanisms firms rely on most, a vector index and an on-behalf-of permission model, both quietly fail to inherit the entitlements people assume they inherit.

The mechanism

Agents leak sensitive data because it was reachable and nothing at retrieval time knew to stop it, rather than because anyone targeted them. Agents inherit years of over-broad human permissions at machine speed, and they consume exactly the material existing governance never covered: unstructured content remains largely ungoverned in most organizations, and that is the mechanism by which citizen agents outrun data controls.

The most important correction on this page concerns vector search. Metadata pre-filtering is widely described as ensuring an agent only retrieves documents its user is authorized to see. It does not. Databricks states plainly that row and column level permissions are not supported on its vector index, and that application-level ACLs must be implemented using the filter API. The filter is only as correct as the code that builds it: omit it, or get it wrong, and retrieval silently returns everything. What the technique guarantees is that if the application correctly derives the user’s entitlements and passes them as a filter, retrieval is scoped. The default behaviour is an index that has flattened document ACLs into one searchable blob, precisely the failure people believe they have avoided.

The on-behalf-of model is better and narrower than its reputation. Microsoft 365 Copilot prompts run in the security context of the invoking user, so agents in SharePoint respond according to that user’s permissions and exclude content they cannot reach. That is genuinely good, and it means pre-existing SharePoint oversharing becomes agent oversharing at speed. Microsoft ships restricted access control and oversharing tooling alongside it for that reason. Note the mechanism precisely, because the two are routinely conflated: agents are stored as .agent files and those file permissions govern access to the agent object, while response filtering comes from the Copilot security context.

Purview DLP can exclude labelled content from grounding: a custom policy scoped to the Copilot location, condition on sensitivity label, action to prevent processing. Labelled items still appear in citations; only content is withheld. The coverage boundaries are documented and matter: file items and emails from 1 January 2025 onward, no calendar invites, files uploaded directly into a prompt go unscanned (only typed prompt text is evaluated), Office policies evaluate at file open so a mid-session label change waits for the next open, sensitive-info-type and sensitivity-label conditions cannot share a rule, and changes take up to four hours to propagate. As of mid-2026, sensitive-info-type prompt blocking and external-email exclusion are both preview.

Two more platform specifics are worth knowing before a firm relies on them. Sharing controls in Copilot Studio let admins restrict grants to individuals, cap viewer counts and exclude security groups, but the viewer cap is only available if group sharing is already disabled, rules are enforced at share time and are not retroactive (an overshared agent can be un-shared, not auto-remediated), they apply only to agents requiring authentication, and enforcement can lag an hour. In the data-platform pattern, data access inherits while model access does not: an AI function called inside SQL does inherit table ACLs for the data, but by default all users hold EXECUTE on the AI-function schema, and the direct model-query function is governed by endpoint permissions rather than catalog permissions.

The controls that measurably move risk are boring. A read-only Postgres role dropped a database-integrity scenario from High to Moderate in a published attack-surface study. Replacing a generic SQL tool with reviewed parameterized operations is the same move at the tool layer, and the vendor now makes the argument itself: exposing a general SQL-execution tool alongside an agent lets the client bypass the agent’s semantic views and verified queries, so it should run under a separate least-privileged role. (Snowflake’s managed server now defaults its SQL tool to read-only, and the older open-source server that permitted writes by default is deprecated; date any example here.)

OWASP’s prescription is the generalizable version: classification labels checked deterministically against an agent’s clearance, tiered classes, default read-only. Research goes further with value-level capability tags that travel with a datum and everything derived from it, and with sensitivity labels that accumulate in shared state so an external send can be scored against the maximum sensitivity the run has touched; that is where this is heading, and nothing ships it.

For a firm holding ISO 27001, three Annex A controls already carry this, with no new framework required: 5.12 classification of information, 5.13 labelling, 8.3 information access restriction.

What to do

Design the entitlement model for the RAG index explicitly, assume the index inherits nothing, and test it by attempting a retrieval that should be refused. A team that cannot name the code path deriving the filter has no access control on retrieval.

Deny agent connectors to unclassified stores. Classification has to exist before agent access, not after, and the cheapest version is a short allow-list of named datasets per agent rather than an estate-wide classification project.

Prefer deterministic data constraints to detection. Read-only roles, parameterized operations instead of generic query tools, row limits, column exclusions. These are settings, not judgments, and they were the controls that moved a real risk score.

Fix oversharing before connecting anything. On-behalf-of permissions are a faithful mirror of the firm’s existing mess. Run the oversharing report first; the agent will find what the report finds, faster.

Scope by task rather than by capability, and re-review per deployment. Permissions granted once at configuration time on maximum-possible-need and never revisited are the normal case and the wrong one. (That framing is a consultancy’s operationalization of a vendor privacy principle rather than the vendor’s own words; the underlying principle, compartmentalizing data across contexts, is sound and worth adopting.)

Test reachability, not policy. Enumerate what an agent’s credentials can actually read today, diff it against what its registry entry says it needs, and treat the gap as the finding. See agent inventory and identity and access.

How you’d know it’s working

The team can produce, for a named agent, the list of data it can reach, derived from credentials rather than from documentation. An answer that comes from a design doc tests nothing.

A retrieval test with a deliberately unauthorized user returns nothing. Run it against the index, not against the application’s UI.

The gap between granted and needed access is shrinking quarter over quarter, and someone owns the number.

What this doesn’t solve

Derived artifacts escape row-level controls entirely. A high-privilege agent emits summaries, plans and tool calls that lower-privilege downstream agents consume, and those derived representations can encode sensitive attributes or permit their reconstruction, bypassing the ACLs on the raw data. The mechanism is grounded in decades of information-flow theory, it emerges during nominal operation with no malicious actor, and it resists detection because it arises from semantically meaningful transformation rather than direct access. Nobody has measured leakage rates in deployed pipelines, and this is the strongest limit on everything above.

Classification of unstructured data stays stubbornly imperfect, and every control on this page keys off labels that may not exist or may be wrong. Scoping shrinks the exfiltrable set without emptying it. What remains is handled by egress control and logging and audit.

A sensitivity label cannot yet be applied to a .agent file, so governing the agent object with DLP means matching on the file extension, a real gap documented by the vendor.

Memory is a data store this page barely reaches. Trust boundaries between memory types and scopes, explicit read/write ACLs per component, and shared memory as an aggravator are the right frame, and the proposed mitigations carry no effectiveness measurement anywhere; see memory poisoning.

The value-level capability tracking that would actually solve derived-data leakage is research. It requires whole-ecosystem participation, exists in one reference implementation, and is described in dual-LLM quarantine rather than here, because it is an architecture a platform team builds rather than a control a firm switches on.

See also

• Data exfiltration — the concern whose ceiling this control sets.
• The lethal trifecta — the sensitive-data leg, and why cutting it architecturally beats filtering.
• Identity and access for agents — data scopes attach to an agent identity or they attach to nothing.
• Memory and context poisoning — the write path this control mostly doesn’t cover.
• DSPM and data classification — the tooling category that makes labelling tractable.
• Recordkeeping and compliance gaps — why MNPI reachability is a supervision question, not only a security one.
• Data — the dimension hub for this control.