How to Control Access to Resolved Customer Data in a RAG Pipeline: 6 Rules for 2026

TL;DR: Resolving a customer’s fragmented records into one identity answers what an AI agent’s retrieval step can find. It does not answer who that agent is allowed to show it to. Six rules keep those two questions separate in 2026: bind every retrieval to the requester’s actual permissions, treat a vector database’s namespace as isolation rather than authorization, scope the resolution query itself rather than filtering after the fact, keep the enforcement boundary inside infrastructure you control, minimise what lands in the prompt rather than only what sits in storage, and log what was retrieved and why so an access review is a lookup, not a reconstruction.

Decide who may see a resolved record before the model does. Review the access model with our team, or test privilege-scoped queries against your own data. Book a Demo or Try Tilores Studio (Free).

On this page

Why does resolving a customer’s identity not automatically control who can see it?
Rule 1: What permission context should every retrieval carry?
Rule 2: Is a vector database’s namespace or tenant boundary enough?
Rule 3: Should access control filter the query or the results?
Rule 4: Where should the enforcement boundary actually live?
Rule 5: Does data minimisation apply to the prompt as well as the database?
Rule 6: What does an access review need that most RAG logs do not have?
Where can access control actually live: a 6-point comparison

Why does resolving a customer’s identity not automatically control who can see it?

Entity resolution answers one question: which fragmented records, across a CRM, a support system, a billing platform and a marketing tool, describe the same person. Feeding that resolved identity into an AI agent’s retrieval step answers a second, unrelated question just as urgently: which of those combined facts is the person asking allowed to see. A support agent chatbot that can now see a customer’s full purchase history, their billing disputes and their churn-risk flag in one resolved profile has more to leak than five separate systems ever did on their own, precisely because resolution did its job well.

This is not a hypothetical concern buried in a security appendix. OWASP’s Top 10 for LLM Applications names it directly under sensitive information disclosure, warning that an LLM application can produce “unauthorized data access, privacy violations, and intellectual property breaches” when the data reaching the model is not itself access-controlled. Its own mitigation guidance is specific: “Enforce Strict Access Controls: Limit access to sensitive data based on the principle of least privilege,” and “Restrict Data Sources: Limit model access to external data sources, and ensure runtime data orchestration is securely managed to avoid unintended data leakage.” Six rules turn that guidance into something a team building an identity-aware RAG pipeline can actually implement.

Rule 1: What permission context should every retrieval carry?

A retrieval call needs to know two things before it runs, not after: who is asking, and what that specific requester is authorized to see. In most agent architectures today, neither is attached to the query. The agent asks a resolution or retrieval layer for “everything about customer 4471,” the layer returns everything it has, and any narrowing happens later, if at all.

The fix is to carry the requester’s permission context, the equivalent of a user ID, a role and a purpose, as a parameter on the retrieval call itself, the same way a well-designed application never lets a database query run without a session’s row-level permissions attached. If the retrieval layer cannot express that context as an input, it cannot enforce it as an output, no matter how good the entity resolution behind it is.

Rule 2: Is a vector database’s namespace or tenant boundary enough?

Vector databases are commonly credited with solving this because they support multi-tenant isolation. Pinecone’s own documentation describes namespaces this way: “Within an index, records are partitioned into namespaces, and all upserts, queries, and other data read and write operations always target one namespace,” recommending “one namespace per customer” specifically to “isolate data between customers.” Weaviate takes a similar approach at the storage layer: “To separate data within a cluster, use multi-tenancy. Weaviate partitions the cluster into shards. Each shard holds data for a single tenant.”

Both are genuinely useful and both solve a different problem than the one this article is about. A namespace or a tenant shard keeps Customer A’s data out of Customer B’s queries, which matters enormously in a multi-tenant SaaS product. It says nothing about whether the specific support agent, sales rep or AI assistant querying inside Customer A’s own tenant is allowed to see this particular customer’s billing dispute or churn flag. That is a permissions question inside the tenant, not a boundary between tenants, and no vector database ships an answer to it by default.

Trust comes from carrying permission and purpose through the query, limiting what is assembled, and recording why access was allowed.

Rule 3: Should access control filter the query or the results?

Tilores’s own API is a useful, concrete example of what building this in actually looks like. Its GraphQL schema supports a @hasPrivilege directive on individual fields, so a field can be declared as myCustomField: String! @hasPrivilege(privilege: "tilores/record.myCustomField"), and an OAuth client requesting a token can narrow its own privileges down to exactly the fields a specific caller should reach, for example a scope of tilores/query.search tilores/record.myCustomField rather than every privilege the client is generally allowed. A client requesting a token can narrow its own privileges further at that moment, exactly as built: “When the client then makes a token request, it can narrow the requested privileges down even further.”

That mechanism is a building block, not a default. Privileges must be attached to the right fields and tokens requested with the right narrowed scope by whoever builds the calling application; installing a resolution API does not, on its own, give one scope per human user asking through an AI agent. Whether an agent’s retrieval calls actually carry a token scoped to the requester, rather than one broad service credential shared across every user, is still the application’s decision to make.

The practical implication is that access control has to run before the query returns data, not as a filter applied to a full result afterward. Filtering after the fact means the full resolved record, every field from every source system, was already assembled and briefly available inside a process boundary the permission check has to trust. Scoping the query itself with a narrowed token, so a search for a support agent’s permitted fields never assembles the billing dispute in the first place, removes an entire class of leak that a downstream filter can only try to catch.

Enforcement point	Vector database layer	Resolution or API layer	Application or agent layer
Tenant isolation	Strong by design (Pinecone namespaces, Weaviate multi-tenancy)	Depends on how the API is deployed and scoped per customer	Inherited from whichever layer it calls
Field-level scoping inside one tenant	Not addressed; a namespace does not know about roles	Possible via field-level privilege directives and narrowed OAuth scopes on platforms that support them, such as Tilores; requires the deploying team to attach privileges per field and request narrowed tokens per requester	Where this most often ends up by default, and where it is easiest to forget
Query-time authorization context	No native concept of a requesting user’s role	Can be attached as a parameter if the caller passes it in	Usually where the user’s session and role actually live
Audit trail of what was retrieved	Query logs, rarely tied to a business justification	Depends on the platform; Tilores’s score fields help explain why a match was returned, not who was allowed to see it	Best place to log purpose alongside identity, since only this layer knows why the agent asked
Where the data physically sits	Wherever the vector database is hosted	Customer’s own AWS account for Tilores, third-party SaaS for many alternatives	Wherever the application runs
Who can act on a permission change	Vector database operator’s admin tooling	Whoever controls the resolution layer’s deployment	Whoever owns the application code and its session logic

Rule 4: Where should the enforcement boundary actually live?

An access control decision is only as trustworthy as the infrastructure enforcing it. A third-party SaaS resolution or retrieval service asks a customer to trust that service’s own staff, incident history and subpoena posture, on top of whatever access rules the customer configures. Tilores’s deployment page states its own position on this plainly for the AWS account option: “The same deployment, inside your own AWS account. It runs on DynamoDB, SQS, and S3 in your VPC,” adding that “Your data never leaves your environment and no Tilores staff can access your records.”

That does not replace the access control rules described in this article. It changes where they run. When the resolution layer sits inside a customer’s own VPC, the permission checks in Rules 1 through 3 execute inside infrastructure that customer’s own security team already audits, rather than inside a vendor’s environment the customer has to take on faith. The deployment page is explicit that this is not a cut-down mode: “There is no cut-down self-hosted edition and no cloud-only feature set,” so choosing to keep the boundary in-house is not a tradeoff against capability.

Rule 5: Does data minimisation apply to the prompt as well as the database?

Most data minimisation programmes stop at storage: encrypt the database, restrict who can query it, retain records for only as long as policy allows. GDPR’s own wording in Article 5 does not stop at storage either. Personal data must be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed,” and processed only for “specified, explicit and legitimate purposes.”

A prompt assembled from a resolved customer profile is processing, in exactly this sense, the moment it is built. Stuffing an agent’s context window with every field a resolution API returned, because it was easier than deciding what the current task actually needs, is the RAG-era version of over-collecting data and hoping it never becomes a problem. The purpose of the specific customer interaction, not the full breadth of what resolution can return, should decide which resolved fields ever reach the prompt.

Rule 6: What does an access review need that most RAG logs do not have?

Standard application logs capture who queried what and when. An access review after an incident, a customer complaint or a regulator’s question needs a third element most teams never log: why the retrieval was allowed, meaning which permission rule matched and which purpose justified it. Without that third element, reconstructing whether a specific retrieval was appropriate months later means re-deriving the permission state as it existed at that moment, which is often impossible once roles and rules have since changed.

Logging the resolved entity’s score and the permission decision together, at the moment of retrieval rather than reconstructed afterward, turns that reconstruction into a lookup. It also creates the feedback loop that improves Rules 1 through 3 over time: a pattern of near-miss retrievals, cases where a requester almost saw a field they should not have, is the clearest signal that a permission rule needs tightening before it is exploited rather than after.

Building access control into a RAG pipeline that already resolves identity well

None of these six rules ask a team to choose a different resolution platform or rebuild a working RAG pipeline from scratch. They ask for a permission context on every retrieval call, a clear-eyed view of what a vector database’s tenant isolation does and does not cover, query-time scoping instead of after-the-fact filtering, an enforcement boundary inside infrastructure the customer’s own team can audit, minimisation applied to the prompt rather than only the store, and a log that captures why access was granted, not only that it happened.

The complete guide to identity-aware retrieval-augmented generation covers how resolved identity improves what an agent can find in the first place, and entity-resolution-based RAG for regulated industries covers the accuracy case for resolving identity before retrieval. Both assume the starting point this piece makes explicit: resolving identity well is necessary for a trustworthy RAG pipeline, and it is a separate job from deciding who is allowed to see what gets resolved.

FAQ

What is access control in a RAG pipeline?

Access control in a RAG pipeline is the set of rules that decide which resolved data a specific requester, whether a human user or an AI agent acting on their behalf, is allowed to see before it is retrieved and placed into the model’s context. It is distinct from entity resolution, which decides what data exists about a customer, not who is permitted to view it.

Do vector databases like Pinecone or Weaviate handle access control automatically?

Pinecone and Weaviate handle tenant isolation, not per-user access control. Pinecone’s namespaces and Weaviate’s multi-tenant shards keep one customer’s data out of another customer’s queries, which is valuable, but neither product has a native concept of which specific role or requester inside one tenant should see a given field. That layer has to be built separately.

Does Tilores restrict which fields an API caller can see?

Tilores’s GraphQL API supports field-level access control through a @hasPrivilege directive on individual schema fields, and OAuth clients can request tokens narrowed to a specific set of privileges rather than everything the client is generally allowed. That mechanism has to be configured: privileges attached to the right fields, tokens requested with the right scope, so the primitive existing is not the same as an agent’s retrieval calls automatically carrying a token scoped to the human asking.

GDPR Article 5 requires personal data to be adequate, relevant and limited to what is necessary for the purpose it is processed for, and processed only for specified, explicit and legitimate purposes. Applied to a RAG pipeline, that means the fields placed into an agent’s prompt should be limited to what the current task needs, not everything a resolved customer profile contains, since assembling the prompt is itself a form of processing.

Should access control live in the vector store, the resolution layer, or the application?

All three have a role, but they are not interchangeable. The vector store or resolution layer is well suited to tenant isolation and to scoping which fields a query assembles. The application layer is usually where a user’s session, role and purpose actually live, which makes it the natural place to attach the permission context that Rules 1 and 6 depend on and to log why each retrieval was allowed.

Sources

LLM02:2025 Sensitive Information Disclosure, OWASP Gen AI Security Project, checked 2026-08-26.
Indexing overview: namespaces and metadata filtering, Pinecone Documentation, checked 2026-08-26.
Data structure and multi-tenancy, Weaviate Documentation, checked 2026-08-26.
Art. 5 GDPR: Principles relating to processing of personal data, General Data Protection Regulation, checked 2026-08-26.
API Reference, Tilores Documentation, checked 2026-08-26.
Authorization, Tilores Documentation, checked 2026-08-26.
Deployment Options: Run Tilores Where Your Data Is, Tilores, checked 2026-08-26.
IdentityRAG: The Complete Guide to Identity-Aware Retrieval-Augmented Generation (2026), Tilores, checked 2026-08-26.
Improving LLM Accuracy in Regulated Industries with Entity-Resolution-Based RAG (EntityRAG), Tilores, checked 2026-08-26.