RBAC Across Agents, Knowledge, Tools, and Models

Enterprise AI security keeps getting scoped to the chat window — who is allowed to open the assistant, who sees which buttons. The breach never comes from the window. It comes from the layer underneath, where the user's identity quietly stopped traveling with the request and nobody noticed until the wrong document came back.

In a security review that has become almost routine, an engineer demonstrates that the new AI assistant respects permissions. She logs in as a junior analyst, and the interface behaves exactly as it should: the admin panel is hidden, the export button is greyed out, the sensitive dashboards do not render. Everyone in the room nods, because this is what access control has always looked like — a set of things the user can and cannot see. Then someone asks the analyst's account a plain question in the chat box, something about a customer account she has no business reading, and the assistant answers it perfectly, pulling three sentences from a contract stored in a knowledge base she was never cleared for. Nothing about the interface was wrong. The button was still greyed out. The problem was that the question went somewhere the button never guarded, and the analyst's identity did not make the trip.

That gap is the entire subject, because it is where enterprise AI security actually fails, almost every time. Organizations have spent decades getting good at controlling what a user can see on a screen, and that competence gives a false sense of completeness when the same discipline is pointed at an AI system, which is not a screen but a request that fans out — to an agent that decides what to do, to a knowledge store that answers a question, to a tool that touches a live system, to a model that processes whatever text got assembled along the way. Each of those is a place where the question "is this user allowed to do this?" has to be asked again, with the real user's identity in hand, and the discipline that secured the screen does not automatically reach any of them.

The identity stops traveling at the first hop

The specific failure has a shape, and once you see it you see it everywhere. A request enters the system carrying a real, authenticated user — a person with a role and a defined blast radius — and the interface checks that identity and renders correctly. But the moment the request crosses from the interface into the machinery behind it, the identity tends to get replaced by the system's own credentials, because that is how the plumbing was built. The service account that reads the knowledge base reads everything. The connector that calls the CRM calls it as the integration, not as the analyst. By the time the request is doing the interesting work, the person who made it has been abstracted away, and every downstream layer is operating with the union of all permissions rather than the intersection the user was supposed to have.

This is not a bug a careful engineer forgot to fix. It is the default behavior of nearly every system that wires an AI layer on top of services built to be called by trusted backends, not by an agent acting for a specific, less-trusted human. When you place an autonomous system in front of a knowledge base built to be queried freely and an API built to trust its callers, and let it act on any user's behalf, you have created a confused deputy — something with broad privileges taking instructions from someone with narrow ones — and unless the user's identity is threaded through every hop, the deputy will happily use its own access to answer a question the user had no right to ask. The interface permissions are real, but they guard the front door of a building with no interior walls.

What makes this so easy to miss is that it does not look like a breach. No alarm fires and no boundary is visibly crossed; a user simply asks a reasonable-sounding question and gets a helpful, accurate answer that happens to contain something they were never cleared to know. The system did exactly what it was told, which is precisely the danger, because the thing it was told to do was never checked against who was asking. This is why the current wave of enterprise AI has a trust problem that runs deeper than its accuracy problem, and it is part of why Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing inadequate risk controls among the reasons.

Four layers, and the breach is always the one you didn't check

It helps to name the layers, because access control has to be enforced at each independently, and the security of the whole is the weakest of them, not the strongest. The first is the agent itself — which Specialist Agents a given user is even allowed to invoke, because an agent that can initiate wire transfers or modify production infrastructure is not one every role should be able to summon. The second is knowledge — which slices of Enterprise Knowledge a request may retrieve, enforced at the moment of retrieval against the actual user, so that the same question asked by two different people returns two different answers scoped to what each is permitted to see. The third is tools — which external systems an agent may touch on this user's behalf, and with what verbs, so that read access to a record never quietly becomes write access, and a connection scoped to one team's data cannot be pointed at another's. The fourth is models — which underlying models a given workload may reach at all, so that regulated or sensitive content is never routed to an endpoint outside its allowed boundary, whatever the agent happened to decide in the moment.

The reason all four have to hold simultaneously is that an attacker, or an honest accident, only needs one of them to be missing. You can enforce agent-level permissions flawlessly and still leak through the knowledge layer, as the analyst did; you can lock down retrieval and still cause damage through a tool that writes to a system the user should only read; you can secure every tool and still violate a data-residency obligation because the model layer had no rule about where a class of content was allowed to be processed. The interesting requests — the ones that reach across systems, the ones an agent composes on its own — are exactly the ones most likely to fall outside the region where all four controls happen to overlap. Security enforced at one layer and assumed at the other three is not defense in depth. It is a single point of failure wearing the costume of four.

This is also why the layer that gets breached is almost always the one nobody was watching. Teams instrument the layer they understand — usually the interface — and treat the layers beneath it as plumbing that "inherits" the security above it. But permissions do not flow downhill on their own; the knowledge store does not know what the interface decided unless the identity was carried down and re-checked at retrieval, and the tool does not know the user's role unless the call was made in that user's name. Every layer that is not independently enforcing access control is trusting the one above it to have done so, and that trust is the whole vulnerability, because the request has by then usually shed the identity that would have made the check possible.

Access control has to move with the request, not sit at the door

The correction is simple to state and demanding to build: the user's identity, and the permissions that come with it, have to travel with the request through every hop, and each layer has to enforce against that identity rather than its own privileges. When an agent retrieves from Enterprise Knowledge, the retrieval is filtered by what the requesting user may see, not by what the service account can index. When an agent calls an external system, it does so through a governed path — a Model Context Protocol connection scoped to that user — so the verbs and data boundaries are the user's, not the integration's. When a request reaches a model, it passes through an LLM Gateway that decides, per policy, which models this workload may use and where its content may go. And the agent a user can invoke at all is itself an entitlement, so the Reasoning Core orchestrates only the capabilities that person is cleared to set in motion. This is the architecture behind the move toward a genuinely autonomous enterprise — one where autonomy is safe precisely because access control is enforced end to end rather than assumed after the first hop, and where a Human-in-the-Loop gate sits on the actions whose consequences warrant a person's sign-off rather than standing in for the controls that should have been enforced automatically all along.

The demanding part is that this cannot be retrofitted as a filter at the edge, because the interface is the one place where the failure has already been prevented and the four layers beneath it are where it actually happens. Access control has to be a property of the request as it moves, re-evaluated wherever the request does something consequential, which means it has to be designed into the way agents retrieve, call, and reason from the beginning. A system built that way can tell a security team, at every layer and not just at the door, what a specific person can see, do, and process — and the door was never where anyone was going to get in.

The mental model worth carrying out of all this is that permissions in an AI system are not a wall you put up once at the entrance. They are a passport the request has to keep showing. Every time it crosses a border — into an agent, into the knowledge, into a tool, into a model — someone has to check the passport again, against the person who actually holds it, because the request itself has no loyalty and will do whatever its privileges allow. The organizations that internalize this will stop asking whether their AI respects permissions, a question that only ever tests the front door, and start asking whether identity survives every hop of every request. That is the only version of the question whose answer is the same as the answer to "are we secure" — and the gap between the two questions is exactly the width of the breach.