Your Agent Inherits Every Permission Mistake Your Org Made in the Last Decade

Wire an agent into your retrieval pipeline and it inherits every unfinished permission decision in the org chart. A decade of accumulated drift, in one query.

RBAC was a model for humans clicking through a UI. Roles map to resources. The user sees the page or hits a 403. That model collapses the moment the caller is an agent firing hundreds of retrievals per session, traversing data across departments, synthesizing across permission domains nobody ever reconciled. The clean role-to-resource diagram was never the enforcement layer. It was the marketing slide.

A March 2026 Cloud Security Alliance study found 68% of organizations cannot distinguish between human and AI agent actions in their access logs^[7]. Non-human identities — service principals, API tokens, autonomous agents — outnumber human users by roughly 100 to 1 in the average enterprise. An identity layer built for a few thousand employees is now the policy enforcement point for millions of machine callers, most of them running with far more privilege than their function requires.

This is the architecture for permission-aware RAG. Pre-retrieval filters. Delegated identity. RLS at the data layer. Audit trails that survive the next ACL change. The patterns, the tradeoffs, the code.

One admission first. Permission enforcement and retrieval quality fight each other. Every filter you add cuts leakage risk and cuts the chance the agent finds the most relevant chunk. No architecture eliminates that tension. The only question is who decides where the line goes — you, or the pipeline by accident.

Every RAG-powered agent runs into the same forced tradeoff. Broader access produces better answers — the agent that cross-references HR data, financial reports, and engineering tickets generates insights no single-domain tool can match. Broader access also surfaces information the requesting user was never supposed to see.

A concrete failure mode. A sales manager asks the internal AI: "What's the competitive landscape for our Q2 deal with Acme Corp?" Answering well needs CRM data, competitive intelligence, deal history, pricing models. All legitimate for a sales manager. The same retrieval pass also pulls board-level strategic memos about the Acme relationship, HR data on the account executive's performance review, and finance margin targets restricted to VP-and-above.

The agent does not know what it should not know. It retrieves on semantic similarity, not on permission boundaries. The gap between semantically relevant and authorized to view is the leakage surface. Nobody owns it by default. That is why it widens.

A RAG pipeline gives you three enforcement surfaces. Treat them as alternatives and one becomes a single point of failure. Treat them as a stack and the failure modes stop overlapping.

Pre-retrieval filtering attaches permission metadata to every chunk at ingestion and adds filter clauses to the vector search query. The vector database returns only chunks the caller is authorized to see. Sensitive data never enters the pipeline at all.

Post-retrieval filtering runs semantic search first, then routes the top-k chunks through an authorization service that strips anything the user shouldn't see before the LLM gets context. Catches the chunks that were mis-tagged at ingestion. Last layer between the index and the model.

Hybrid is the only configuration that holds. Broad pre-retrieval filters — department, classification level — narrow the search space. Fine-grained post-retrieval checks handle the relationship-based permissions metadata cannot express. Each layer absorbs what the layer above it lets through.

The hardest part of permission-aware RAG is not the filter logic. It is making sure the user's identity and permissions actually propagate through every stage of the pipeline without being lost, elevated, or confused.

Most agent architectures have a gap here. The user authenticates at the application layer, but by the time the request reaches the vector database, it is running under a service account with broad access. The permission check happens — if it happens — at the application layer after retrieval, not at the data layer during retrieval.

This is the confused deputy problem applied to AI pipelines. The agent is authorized to access everything. It should only retrieve data on behalf of the specific user who made the request. When the agent's identity is used for retrieval instead of the user's, every query runs at maximum privilege. Pretending otherwise is theater.

Row-level security pushes enforcement down to the database layer. The agent — or the application — physically cannot read rows it should not see. There is no "forgot to add the filter" failure mode, because the filter is not in the application code.

PostgreSQL has supported RLS since 9.5, and it is the cleanest fit for RAG pipelines running on pgvector or Supabase. Define policies that reference the current user's role or session variables and the database appends the filter to every query automatically. The agent never constructs the filter itself. It just queries.

Supabase pushes this further with their RAG-specific pattern: each chunk carries an owner_id column, and the RLS policy checks the authenticated user's JWT claims against the row^[5]. Combined with Edge Functions for the agent runtime, you get end-to-end propagation from the user's browser to the vector search to the LLM context. Identity does not get dropped on the floor, because the database refuses to do work without it.

The most consequential architectural decision in permission-aware AI is whether the agent authenticates as itself or as the user it acts for. Everything else downstream — filter design, audit fidelity, what a compromised credential exposes — falls out of that choice.

Service account model. The agent has its own identity with broad access. Application code filters results based on the requesting user's permissions. Easier to wire up. The agent's credentials become a high-value target. Compromise it and the attacker gets everything the agent can see, which is usually everything.

Delegated identity model. The agent receives a short-lived, scoped token that carries the requesting user's identity and permissions. Every downstream call — vector search, database query, API request — runs under that token. The agent can only access what the user can access^[10].

Delegated identity is strictly better from a security standpoint, and the price is real infrastructure. You need a token exchange mechanism — OAuth2 token exchange, or a custom delegation service — and every system in the pipeline has to honor the delegated token. Most vector databases do not natively support this yet, so you end up implementing it at the application layer with pass-through filters. The blast radius shrinks from "everything the agent can touch" to "everything the user could already touch." That tradeoff is the entire point.

Teams that bolt traditional RBAC onto RAG hit the same failure modes repeatedly. None of these are theoretical. They show up in production within weeks of deployment, and the patterns are stable enough to name.

Pre-retrieval filtering is only as good as the metadata you attach to each chunk at ingestion. Get the taxonomy wrong and you either over-restrict — the agent cannot find anything relevant — or under-restrict, and surface what users should never see.

The leverage point is layered classification rather than flat role tags. Three metadata dimensions cover most enterprise permission patterns. Complex organizations with unusual access hierarchies need more dimensions; do not pretend otherwise.

Here is the scenario that breaks most permission-aware RAG implementations. A confidential engineering document is chunked, embedded, and tagged with classification: confidential, departments: ['engineering']. Three weeks later, the project launches publicly and the document is reclassified to internal. The source system's ACL gets updated. The 47 chunks in your vector database still carry the old confidential tag.

Now every non-engineering employee who asks about this feature gets nothing, even though the information is public. Worse — if someone re-uploads the document and creates new chunks, the same content sits in the index at two different permission levels.

This happened to us in a production deployment. A product launch announcement was confidential during pre-launch, reclassified to internal at announcement time. The 12-hour delay in ACL sync meant the agent refused to discuss publicly-announced features for half a day. The fix was webhook-triggered sync instead of a batch job. ACL changes now propagate in under two minutes.

ACL synchronization is a pipeline problem, not a one-time task. You need a mechanism that detects permission changes in source systems and propagates them to every chunk derived from the affected document. Drift is the default state of any system without an explicit owner.

The permission model gets significantly more complex the moment you move from a single agent to a multi-agent orchestration. An orchestrator decomposes a user's question and dispatches it to three specialized sub-agents: one queries the knowledge base, one queries the CRM, one queries the financial system.

Each sub-agent talks to a different data source with a different permission model. The knowledge base uses document-level ACLs. The CRM uses account-level visibility rules. The finance system uses row-level security tied to cost-center hierarchies. The requesting user might have access in two of three systems.

When the orchestrator synthesizes results, the question is whether it knows some data is missing because of permission boundaries — and whether the final response reflects that gap honestly. Two patterns handle this. Only one of them is defensible.

Configured permissions and enforced permissions are not the same thing. You need observability that tells you, in real time, whether the access controls you designed are actually holding in production. Logging that records "agent succeeded" is not observability. It is an alibi.

Three metrics carry the weight.

Pulled together, a production-grade permission-aware RAG system has five layers running in sequence. The user's identity flows through every layer. No layer trusts the one above it to have done the permission check. That is the design rule. Trust between layers is the failure mode that ate the last system.