Databricks Vector Search MCP Access Control: Controlling Agent Retrieval of Customer Documents

Why permissions alone do not decide each retrieval

When an agent can call the Vector Search MCP tool, it retrieves chunks of customer documents based on whatever query it constructs. That query may be shaped by a prompt injection or by an overly broad task instruction. Native identity and catalog permissions determine which indexes and rows a caller can reach. They do not decide whether a specific request from a specific agent should be allowed, narrowed, redacted or escalated at the moment of the call.

This follows a distinction long made in access control guidance: authentication establishes identity, and authorization is the separate decision to permit or deny access to an object. NIST SP 800-162 describes attribute-based decisions that evaluate attributes of the subject, the object, the requested operation and sometimes environment conditions against policy. A catalog grant answers part of that question. The rest, including the content of the request and the content of the response, needs its own control point.

The sections below take each layer in turn and state what it decides and what it leaves open.

Layer 1: identity, permissions and index design

Start with the foundation. Grant access to indexes and their source tables on the principle of least privilege, and treat the index as the unit of exposure. An index should contain only material that every caller permitted to query it is entitled to see. Mixing document classes with different sensitivity in one index pushes the entire burden onto filters and runtime checks, which is harder to defend.

Decide explicitly which identity the agent calls under. If it acts under the end user's identity, reachability follows that user's entitlements. If it acts under a shared service identity, every user of that agent inherits the same reach, and the agent's own scope has to compensate. Neither choice is wrong, but each has different consequences for accountability.

Whichever you choose, record the mapping between the agent identity and the user on whose behalf it acts. The NCCoE concept paper on agent identity and authorization treats this linkage as the basis for delegation controls and accountability. Without it, a retrieval record cannot be tied to a person or a purpose.

• Separate indexes by sensitivity and by the audience entitled to the content.
• Apply row and column controls on source data wherever the platform supports them.
• Decide user identity versus shared service identity per agent, and document the reason.
• Record the agent-to-user mapping for every session.

Layer 2: metadata filters and per-agent tool scope

Metadata filters narrow a query to a subset of documents, such as a customer, a document type or a region. Their value as a control depends on who sets them. A filter the agent chooses is agent-controlled input, and an injected instruction can change it. Filters that serve as a boundary should be applied by something outside the model's discretion, derived from the caller's attributes rather than from the prompt.

Tool scope works at a coarser level. Expose to each agent only the indexes it needs for its task, and do not hand every agent a general-purpose retrieval tool over everything the platform can reach. The Federal Register request for information on AI agent security lists data or tool restrictions among agent system-level controls, alongside continuous monitoring and human approvals. It is a request for input rather than a rule, but the control logic is sound: a narrower tool has a smaller failure surface.

Both layers reduce exposure before a call happens. Neither inspects the specific request or what comes back.

What each layer decides and what it leaves open

Use this as a placement guide when deciding where a given control belongs.

• Identity: Decides who or what is calling. Leaves open whether this request is appropriate.
• Catalog and index permissions: Decide which indexes and rows are reachable. Leave open the content of the query and of the returned chunks.
• Index design: Limits what any query can return from an index. Leaves open misuse within that index.
• Metadata filters: Narrow results when applied outside the agent's control. Leave open filters the agent sets itself.
• MCP tool exposure: Limits which tools and indexes an agent can call. Leaves open how it uses them.
• Runtime policy: Evaluates each call and result against policy. Depends on the layers above for reachability.

Layer 3: runtime policy on tool calls and returned content

Runtime policy evaluates an individual MCP tool call before it executes and the returned content before the agent sees it. On the request side, the decision can draw on attributes of the agent, the delegating user, the requested operation and the context. On the response side, it can inspect returned chunks for sensitive content that the index design did not anticipate.

The useful outcomes are more varied than permit or deny. A request can be allowed, a chunk can be redacted, a call can be blocked, repeated calls can be rate limited, and a consequential or sensitive retrieval can be escalated for human approval. Rate limiting matters because broad retrieval often arrives as many narrow calls. The NCCoE concept paper raises the related aggregation question: individually permitted retrievals may add up to a response whose sensitivity, or the user's entitlement to it, needs separate evaluation.

Trussed enforces policy in the execution path for individual tool calls and MCP servers, with these outcomes: allow, redact, block, rate limit and escalate for human approval. Policy is enforced at runtime, not reviewed after the fact. It complements Unity Catalog permissions rather than replacing them, and its scope is the individual call and its result. It does not extend to tracing a whole agentic workflow.

Before adopting any runtime layer, test whether it can evaluate the attributes your policy needs and whether it can act on returned content as well as on requests.