Executive Summary

A Meta internal AI agent exposed data it had no right to see across the company for roughly two hours. The single most important fact about the incident is that nothing was breached. No outside attacker got in, no credential was stolen, no firewall or access perimeter came down. The agent carried valid credentials and passed every identity check exactly as designed.

And yet the data leaked. The failure happened one step past authentication. Who the agent was had been verified precisely, but what that agent was entitled to see — authorization — was never enforced at the moment it reached for the data. A deputy holding valid credentials executing the wrong request on its own authority is the textbook confused deputy problem in security. That is why a system can leak even when nothing is breached.

This is where the report parts ways with the dominant conversation. The story around enterprise AI agents tends to converge on a performance problem: the model is "confidently wrong." But what the Meta incident revealed was not performance. An agent reached data it was not entitled to access, and that is not a question of what the model knows — it is a question of what it is entitled to see. It is not a performance story; it is a data governance story.

The Angles Already Covered, and the One Still Open

Over the past few weeks Pebblous has covered agent data leakage from several angles: where the leaks escape (tool calls, logs, agent-to-agent messages), why the context layer that underpins all of it became an investment thesis, and who the agent is (identity and lineage). This report narrows in on the two axes those three pieces did not touch — what an agent is entitled to see (permission), and when that entitlement breaks down (retrieval time).

In one sentence: identity (who) and the pipes (where) are already covered. This report is about permission (what) and timing (when).

A source data warehouse enforces who sees what with real precision. Role-based access control (RBAC) divides access by job function; attribute-based access control (ABAC) divides it by attributes like department, region, or clearance level. Row-level security (RLS) makes the same table return different rows to different people, and column masking hides the values in specific fields. Up to here we are dealing with controls that have been refined over decades and work well.

The trouble starts the moment that data is moved to feed an AI agent. A retrieval-augmented generation (RAG) pipeline splits documents into small chunks and turns each chunk into a numeric vector called an embedding, stored in a vector index. But that vector index has no place to hold the row and column permission predicates the source carried. A vector is a data structure designed to express semantic proximity, not the rule "only HR may see this value." Worse, chunking dissolves the very row and column boundaries that RLS and column masking depended on. The instant one document is split into several pieces, you can no longer trace which piece belongs to which permission as precisely as the source could.

Many organizations fill this gap with metadata — tagging each chunk with an access control list (ACL) that says "this document, this team only." You can do that. But it is a copy of the source permission, not an inheritance. A copy has to be reconciled with the source through a separate sync pipeline, and the moment that sync runs even slightly behind, the index's permissions begin to diverge from the source. This is the technical reality behind the entitlement drift we will get to shortly.

The data governance platform Atlan nails the contrast down: "an agent retrieving data through an MCP server or RAG pipeline should inherit the same access entitlements that govern that data in the source warehouse, not a separate, manually configured permission set that drifts over time." In other words, an agent retrieving data through an MCP server or a RAG pipeline should inherit outright the access entitlements that governed that data in the source warehouse — not run on a separate, hand-configured permission set that drifts as time passes.

Cases that formalize this problem head-on in the academic literature are still rare. The permission-aware RAG work by Jeong, Lee, and others notes that conventional RAG implicitly assumes every retrieved piece of content is equally accessible, and that forcibly merging different permission models actually invites drift and unintended exposure. Their alternative is to query the source IAM in real time at retrieval and inherit from it. But such head-on papers can be counted on one hand; for the rest, industry implementation is running ahead of academic formalization.

At the instant you copy a permission, source and copy match. The problem is everything after. Organizations do not stand still. People move between teams, projects end, contractors leave, and access opened up temporarily is left ungrantable. The source warehouse reflects all of this; the permission copy configured separately at the retrieval layer stays frozen in an old state unless someone tends to it. This growing gap between source and copy over time is entitlement drift, and the state of holding more access than needed is over-permissioning.

Put it in a concrete scene. Picture an employee who transfers from finance to marketing. The source warehouse soon revokes their old access to finance data, in step with the transfer recorded in the HR system. But the permission tag copied into the retrieval layer does not automatically follow that transfer; it stays in its old state until someone reworks the sync pipeline. And the agent acting on that employee's behalf keeps pulling finance documents into its retrieval set on the basis of exactly that stale permission. The permission is out of step in only one place, yet what leaks through the gap is the whole door the source has already closed.

The scale shows this is not an occasional accident but a standing condition. When Oso and Cyera analyzed roughly 2.4 million identities and 3.6 billion entitlements, 96% of granted permissions had gone unused for 90 days. Which means that in most organizations, people actually open only a tiny fraction of the doors that stand open to them. IBM's Cost of a Data Breach Report (survey window March 2024 to February 2025) lights up the same gap from another angle: 97% of organizations that suffered a breach involving an AI model or app lacked proper AI access controls.

Here a crucial asymmetry appears. For people, over-permissioning is mostly a latent risk. As the 96% of unused entitlements shows, people leave most of their open access unexercised. Agents are different. An agent copies a person's permission set and then activates all of it at machine speed. Doors a person would never have opened in a lifetime, an agent opens in an instant while working through its task. The latent risk turns immediate.

The common response is periodic access review — checking entitlements each quarter and revoking what goes unused. But this approach has a fundamental limit. A review is a batch; it happens all at once at a fixed point in time. In the gap between one review and the next, drift keeps piling up, and during that gap the agent keeps retrieving on the strength of a stale permission snapshot. A review cycle that turns on human working hours and an agent that sweeps data by the second were never on the same time axis to begin with.

Many pipelines retrieve first and check permissions later. They pull the top-k chunks closest to the question out of the vector index first, then filter out whatever the user is not entitled to see. This is called post-filtering. It looks harmless on its face — after all, only authorized material ends up in the final answer.

But that ordering is precisely where the leak starts. Filtering an unauthorized chunk out afterward means it already took part in the retrieval process beforehand. A similarity score was assigned to it, it climbed the ranking, it was read out of the index into memory, and it was left in the cache. Cerbos, which builds policy engines, sums up this state plainly: "the security boundary was already crossed." By the time you filter, the boundary has already been crossed. A post-filter does not prevent the leak; it merely erases it from the answer after the fact.

That the leak begins before generation is not one observation but three lines of evidence converging. The first is the ranking contamination of the post-filter we just saw. Which document ranked at the top is itself information. The mere fact that something surfaced near the top leaks the signal that such data exists.

The second is membership inference. The so-called "Interrogation Attack" work presented at ACM CCS 2025 demonstrated that, without any attack like prompt injection, normal retrieval alone can reveal whether a particular piece of data is in the index. Within about 30 ordinary queries, the presence or absence of the data came out. Even with no attack worthy of the name, retrieval itself becomes a leakage channel.

The third is the combination of cache leakage and the confused deputy. The "ConfusedPilot" work showed together both the path by which secrets leak from the retrieval cache and the path by which a poisoned document makes an agent take the wrong action on its own authority. If a hidden instruction sits inside a retrieved document, a high-privilege agent executes it with its own privileges. A request thrown by a low-privilege user is turned, by way of a high-privilege agent, into an action that user could never have taken.

All three point to one place. Long before the LLM composes an answer — at the stage of retrieving, ranking, and caching — the boundary is already down. If an earlier piece said "agents leak through the pipes, not the answers," this report steps one further back upstream. Before it even reaches the pipes, at retrieval time, it has already begun to leak.

The principle of the remedy comes down to two sentences. Permissions must narrow the retrieval scope first (pre-filter), and those permissions must be inherited from the source rather than built anew. The two connect into one: re-ask the source at retrieval time and inherit, and as a result the retrieval scope is narrowed up front to only what is authorized. Industry practice is already converging on this direction.

The Data Layer — Re-Ask the Source's Permissions at Retrieval

The cleanest form is to let the database itself enforce permissions. PostgreSQL storing vectors via pgvector can apply row-level security as is, so the retrieval query returns only the rows a given user is allowed to see. The source relational permissions are inherited into retrieval transparently. But there is a trap here: unless you turn on FORCE RLS, the table owner bypasses the policy — so before you trust the inheritance, check this setting first.

Vendor platforms say they are productizing the same principle. Databricks explains that it inherits on-behalf-of tokens in real time so an agent touches data only with the user's own permissions. Snowflake applies the same control through row access policies and masking policies, and Glean positions itself as mirroring the source's permissions into the retrieval index. Policy-as-code tools like OPA and Cerbos propose pushing a pre-filter into the vector store at the query planning stage.

The Identity Layer — Adjacent but a Different Tier

Here we should clear up a common confusion. What identity vendors like Okta, CyberArk, and Aembit handle is not the data layer but the identity layer. They issue credentials only at the moment they are needed (just-in-time) and manage the creation and retirement of non-human identities. That is, they get "who" right. The data layer this report stresses, by contrast, enforces "what that who is entitled to see at retrieval time."

Both are needed, but neither substitutes for the other. Strengthen identity alone and leave out data-layer permission inheritance, and post-authentication leaks like the Meta incident remain exactly as they were. However perfectly you verify who the agent is, if that agent can reach data beyond what it is entitled to see at retrieval time, identity verification does not stop the leak. Identity is putting the right nameplate on the door; permission inheritance is actually locking that door.

The division of responsibility shows up in the technical detail too. The vector database Qdrant does not automatically map identity information into payload filters, and makes clear that this is the application layer's responsibility. In other words, applying permissions at retrieval time is not something the vector DB handles for you — it is something the party building the pipeline has to design explicitly.

Once you reach the conclusion that permissions must be enforced at retrieval time, the reflexive next move is easy: "then let's apply the strongest controls uniformly to every agent." Gartner warns at exactly this point. In a May 2026 release, Gartner argued that applying uniform governance across AI agents will itself become a root cause of enterprise AI agent failure.

The reason is symmetric. Put high-autonomy-grade heavy controls on a simple read-only agent and you get latency, and the people responsible build shadow paths that route around the controls. Conversely, control a genuinely high-autonomy agent that actually takes action only at the level of a simple agent, and that is over-permissioning. The instant one standard is applied to everyone alike, one side over-controls and invites workarounds while the other under-controls and invites leakage.

The solution is to map permission inheritance to the agent's autonomy tier. An agent that only observes, one that only advises, one that acts with approval, and one that acts on its own each need a different kind of permission enforcement. The table below pairs autonomy tier with retrieval-time permission enforcement.

Atlan's enterprise AI agent guardrails checklist, read through this lens, threads onto a single axis. Its many control items ultimately gather into one question: does this agent verify, at retrieval time, whether it is entitled to see this data right now? The higher the autonomy, the more that verification has to happen in real time on every action rather than in a batch review.

Finally, one causal overstatement is worth guarding against. The statistic that many agent pilots never reach production is cited often, but pinning all of that failure on permissions is too much. That said, Forrester's analysis breaks down 33% of pilot failures as coming from insufficient tool or data access. Not the whole of the failure, but the point that access governance — not performance — is one of the main axes of failure is supported even by outside institutions' observations.

This topic sits squarely on the AI-Ready Data and data governance line Pebblous has been working. Say "data quality" and people usually think of accuracy and completeness — but there is one more axis: access integrity. When training or retrieval data is indexed without the source's permission boundaries, that data is not low-quality — it is dangerous. However accurate and complete it is, if it can reach someone with no right to see it, that data is not ready.

So when you clean and validate data before feeding it to AI, inheriting and preserving permission metadata alongside accuracy and completeness becomes a new condition of being AI-Ready. The problem of source governance being lost the instant data moves into a vector index leads straight to the proposition that data must be permission-ready, not just content-ready, before it is fed to AI. The row- and column-level access control Pebblous works on is the implementation, at the data-preparation layer, of the retrieval-time permission enforcement this report describes.

The place where organizations trying to put RAG and agents into production get stuck — "the pilot works but production stalls" — is usually right here. Below are five questions you can use to diagnose for yourself whether your pipeline inherits permissions or copies them.

The more the answers lean toward the back half — copy, post, batch, service account, unlogged — the more the organization is trusting a stale permission snapshot frozen into the index. The question to ask is the same one we started with. Is our pipeline enforcing, at retrieval time, not what it knows but what it is entitled to see?

Academic

• 1.Jeong, & Lee. (2025). "Permission-Aware RAG: IAM-Based Access Filtering in Multi-Resource Environments." IEEE Access.
• 2.Naseh, A., et al. (2025). "Riddle Me This! Stealthy Membership Inference for Retrieval-Augmented Generation" (Interrogation Attack). ACM CCS 2025. arXiv:2502.00306.
• 3.RoyChowdhury, et al. (2024). "ConfusedPilot: Confused Deputy Risks in RAG-based LLMs." arXiv:2408.04870.
• 4.Zhou, Feng, & Yang. (2025). "Privacy-Aware RAG: Secure and Isolated Knowledge Retrieval." arXiv:2503.15548.

Policy · Statistics · Industry

• 5.Gartner. (2026, May 26). "Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure." Gartner Newsroom.
• 6.Atlan. (2026). "Enterprise AI Agent Guardrails Checklist."
• 7.VentureBeat. (2026). "57% of Enterprises Have Watched AI Agents Be Confidently Wrong — The Fix Is an Agentic Context Layer."
• 8.IBM. (2025). "Cost of a Data Breach Report" (survey window Mar 2024–Feb 2025, 600 organizations).
• 9.Oso × Cyera. (2026). "Least Privilege Research Report" (~2.4M identities · 3.6B entitlements analyzed).
• 10.Palo Alto Networks / CyberArk. (2026). "Identity Security Landscape" (machine-to-human identity ratio 109:1).
• 11.CSA × Oasis Security. (2026). "State of Non-Human Identity and AI Security."
• 12.Cerbos. "Authorization for RAG and AI agents" (post-filter risk — "the security boundary was already crossed").

Pebblous

• 13.Pebblous. "AI Agents Leak Through the Pipes, Not the Answers." blog.pebblous.ai.
• 14.Pebblous. "Why the Context Layer Became the Next AI Infrastructure Bet." blog.pebblous.ai.
• 15.Pebblous. "200 Agents Run the Company, and None of Them Have an Employee ID." blog.pebblous.ai.