The assistant with more access than anyone who uses it

An engineering lead at an enterprise software company told me about an architecture that had felt clean until they said it out loud in a security review. Their AI assistant ran under a single service identity, and to be useful across the whole product, that identity had been granted broad access to the underlying data. Every user’s request flowed through it. So when a junior employee asked the assistant a routine question, the query underneath ran with permissions far beyond that junior’s own, because the assistant, not the user, was the one reaching the data. The assistant had more access than any individual who used it, and it applied that access to whatever anyone asked.

This is a quiet, common design. Give the assistant broad access so it can help with anything, then let all users share it. It is convenient and it demos well. It also concentrates enormous privilege into one identity that answers to whoever happens to be typing, which turns the assistant into the most over-permissioned actor in the system.

Broad shared access collapses your permission model

Your product almost certainly has a permission model. Different users can see and do different things. That model is doing real work, keeping people inside the boundaries appropriate to their role. An over-privileged assistant routes around all of it. The user’s own permissions never enter the picture, because the assistant is the one holding the keys, and the assistant holds keys to everything.

The result is that the assistant becomes a way to reach data the user could never reach directly. Not through an attack, just through normal use, because the assistant applies its broad access to answer whatever it is asked. A carefully built permission model is silently bypassed for every request that goes through the assistant.

It is also a single point of failure with a huge blast radius. If that one identity is compromised, or if the assistant can be steered through injection, the attacker inherits access to everything the assistant can reach, which is far more than any single user account would grant. You have concentrated the crown jewels behind one identity that talks to anyone.

Scope the assistant to the caller

The fix is to make the assistant act with the caller’s permissions, not with its own broad set.

What that looks like:

Carry the user’s identity into the data access. The assistant should reach only what the current user is allowed to reach, so its effective access changes with who is asking.
Do not grant the assistant blanket access for convenience. Broad access is the shortcut that collapses your permission model. Scope it to the minimum the task requires, per caller.
Enforce permissions at the data layer, not in the prompt. The check that a user may see something has to run where the data is fetched, not as an instruction the model might ignore.
Limit the blast radius of the assistant’s own identity. For anything the assistant does need to do as itself, keep that set as small as possible.

The teams that get this right treat the assistant as an extension of the user, bounded by that user’s rights, rather than a privileged intermediary that acts on everyone’s behalf with keys to everything. The assistant becomes helpful within the boundaries that already exist, instead of a hole through them.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we look at whose access the assistant actually uses. Its own broad identity, or the permissions of the person asking. When it is the former, we map what a normal user can now reach that they never could directly, and we design the scoping before it ships. An over-privileged assistant is one of the most common and most quietly serious findings we see.

An assistant that holds more access than the people who use it turns your permission model into a suggestion. Scope it to the caller, so it can only reach what the person asking was already allowed to see.