Your RAG Scope Is a Permissions Decision You Never Made

The most consequential access-control decision in your AI stack was made by whoever needed the demo to work on a Thursday.

That person wasn't careless. They had a prototype, a knowledge base, and a stakeholder meeting. The first MCP connector got the scope the prototype needed, which was usually some version of "read everything," because a demo that says "I can't find that document" is a demo that gets cancelled. It worked. Nobody filed a ticket to narrow it, because nobody files tickets for things that work.

That scope is now your policy. Not written down anywhere, not reviewed by anyone in security, but enforced every time an agent queries that index. And next year's roadmap is about to plug more agents into it.

How MCP connector permissions become RAG policy by accident

Here is the drift, as we've seen it play out (and, early on, wired it ourselves).

Agent one: internal support

The support assistant gets the connector. Broad read scope on the knowledge base: runbooks, product docs, a few HR policies someone dropped in the shared drive, the pricing exceptions spreadsheet, last quarter's board deck because it lived in the same folder. Callers are employees. Risk feels low. It ships.

Agent two: sales assistant

Sales wants answers about product capabilities and contract terms. The fastest path is reusing the existing connector, so the team does. Now a sales rep can ask about pricing and get the exceptions spreadsheet, including what another customer negotiated. Nobody decided that. It was inherited.

Agent three: customer-facing

The customer portal assistant plugs into the same index because "the knowledge base is already indexed and tested." The caller is now outside your company.

Ask your team one question: which proprietary documents can this agent surface to which caller? If the honest answer is "whatever the retriever ranks highest," you have a problem with a name. The OWASP LLM Top 10 calls it sensitive information disclosure, and the broad connector scope behind it is a textbook case of excessive agency. Prompt injection is the delivery mechanism: a caller doesn't need to hack anything, just phrase a question so the retriever goes looking where it can already look.

The architecture that was fine for agent one becomes the liability for agent three, which is the same pattern we covered in why your second AI product can't reuse your first one's architecture.

How to scope retrieval permissions for multiple agents

This is the method we run. Steal it.

1. Inventory every connector and the scope it actually holds

Not the scope in the design doc. The scope in the credential. For each MCP connector, list the service account or token, the sources it can read, and every agent that calls it. You will find at least one connector nobody remembers creating. That's normal. It's also the point.

2. Map document sensitivity to caller identity

Tag sources (or chunks, where it matters) by sensitivity: public, internal, restricted, confidential. Then define caller classes: anonymous customer, authenticated customer, employee, employee in a specific role. The output is a grid. Every cell is a yes or no. Question marks are findings.

If your agents' boundaries were never written down in the first place, start with defining your agent's data boundaries before go-live.

3. Enforce permissions at retrieval time, not in the prompt

A system prompt saying "don't reveal internal pricing" is a polite request to a text predictor. It is a suggestion, not a control. The control lives where documents are fetched: filter the retrieval query by the caller's identity and entitlements before anything reaches the model's context. If the model never sees the restricted doc, no clever phrasing can make it repeat it.

Practically, that means passing caller identity through the agent to the connector, applying metadata filters or per-tenant indexes at query time, and giving each agent its own scoped credential instead of a shared one.

4. Add eval cases that try to pull restricted docs

Your eval harness should include adversarial retrieval tests: a customer-class caller asking for the exceptions spreadsheet, an injection attempt dressed as a support question, a sales-role query reaching for HR content. Each test asserts the restricted source never appears in retrieved context. Run them as a quality gate on every connector or index change, so a scope regression fails a build instead of a customer conversation.

Is RAG access control a compliance requirement?

Frameworks won't name your connector, but they expect you to know what it does. NIST AI RMF asks you to map and manage risks in context, and ISO 42001 expects documented controls over AI system data use. A connector-to-caller sensitivity map and retrieval-time enforcement are clean, auditable evidence for both. They're also exactly where compliance quietly breaks once a second workflow shows up, as we wrote in why NIST AI RMF and ISO 42001 compliance breaks on workflow two.

Why this belongs on next year's roadmap

Budget season rewards line items that are cheap, bounded, and defensible. Retrieval-scope cleanup is all three. With three agents, it's an inventory and some filters. With five agents sharing one index, each with its own callers and integrations, it's a retrofit with downstream regressions.

For a CISO, this is the rare AI security story with a concrete artifact attached: here is every connector, here is who can retrieve what, here are the tests that prove it. For a CTO, it's the thing that lets you say yes to agent four without a security review stalling it for a quarter.

We split the work the same way we'd scope it for a client. The AI Opportunity & Readiness Sprint (2 weeks, fixed fee) produces the connector inventory and the sensitivity-to-caller map. The Pilot-to-Production Build (6 to 10 weeks) covers enforcement: identity passthrough, scoped credentials, and the eval gates that keep it honest.

The one sentence every agent launch doc needs

Before the next agent ships, require one sentence in its launch doc: "This agent can retrieve [sources] for [caller classes], enforced at [layer]."

If the team can write it in a minute, good. If they can't, that's the finding, and you just got it before a customer did.

To get started, download the H2L retrieval-scope checklist at https://horizontwolabs.com: connector inventory template, sensitivity-to-caller map, and starter eval cases for restricted-doc retrieval. If your map ends up with more question marks than answers, that's when to book the Readiness Sprint.