How Do You Control What an AI Agent Can Access?
You control it the same way you control any other privileged system: on the server, before the request is served, not with an instruction written into a prompt. An AI agent working inside a company with more than one person needs a live execution identity that represents the person currently talking to it, and every sensitive read or action has to pass four separate checks against that identity: does this person have the right role in the organisation, does the specific item allow them, does the underlying data source allow them, and is this tool permitted for this action.
The part almost everyone gets wrong is the timing. Filtering has to happen before the model receives context. Once unauthorised information is inside the context window, you are relying on the model's discretion, and discretion is not an access-control boundary.
I'm Mahmoud Zalt, an AI architect running Sistava, where autonomous agents do real business work in production. This is the problem that took the most architecture time, and the one most teams discover late.
The Tuesday Night Problem
A founder types something into an AI assistant at 11pm on a Tuesday.
Not a task. A situation. A term sheet that arrived, a number lower than expected, and the name of the person on the other side who does not want it known yet.
The assistant is helpful. It drafts a response, weighs the options, and remembers the context so nobody has to repeat it tomorrow.
On Thursday, a collaborator in the same workspace asks that same AI assistant a completely reasonable question: anything coming up that would change our hiring plan for Q3?
That second question is the entire test. Everything you believe about your permissions model gets settled in the moment the retrieval query runs.
Notice what makes this hard. Nobody attacked anything. The collaborator asked a normal question in good faith. The assistant tried to be useful. The failure, if it happens, is architectural.
Why Telling the AI to Keep Secrets Does Not Work
The tempting fix is a sentence in a system prompt. Something along the lines of: never disclose confidential information shared by other users.
That is not a security boundary. That is a request.
A language model cannot un-see what you put into its context window. Once that acquisition conversation has been retrieved, assembled into the prompt and handed to the model, the only thing between it and the wrong reader is the model's judgment about what to say next. Judgment degrades under paraphrase, under a cleverly worded follow up, under summarisation requests, and under text that arrived inside a document the model was asked to read.
So the requirement is not that the AI declines to share it.
The requirement is that the information is never retrieved, never placed in context, and never made available to a tool call for that requester in the first place.
This is the same distinction that separates real output validation from hoping a model behaves. Everything downstream of the prompt is mitigation. Access control lives upstream.
Give the Agent an Execution Identity, Not a Master Key
A traditional application asks one question at the door: can this user access this app, and can they perform this organisation-level action?
An AI agent forces a harder question, and it has to be answered continuously rather than once at login:
When this specific person talks to this agent, which facts, files, memories, connected-app records, tool outputs and actions is it allowed to reach on that person's behalf?
The answer is that the agent should not hold blanket workspace access at all. It should execute with a live, server-enforced identity representing the current requester inside the current workspace. Not a service account with the union of everyone's permissions. Not the agent's own standing credentials. The requester's authority, propagated all the way down into the database query.
Once you hold that model, a lot of design questions answer themselves. A cached agent graph must not retain the authority of whoever warmed it. A background job triggered by one person must not run with the reach of another. A shared conversation thread does not merge the permissions of its participants.
The Four Checks Every Sensitive Operation Should Pass
Before anything sensitive happens, retrieving a memory, searching a knowledge base, opening a file, inspecting a contact, calling a connected tool, exporting data or sending something outward, the server computes an intersection:
allowed = requester_authority
AND resource_policy
AND data_source_scope
AND tool_permissionFour terms, each doing distinct work. Miss any one and you do not have a gap, you have a bypass.
| Check | Question it answers | Typical failure |
|---|---|---|
| Requester authority | Is this person an accepted member of this workspace with the required role? | Trusting a client-supplied user id instead of a server-resolved session |
| Resource policy | Does this exact document, task, contact or attachment allow this person? | Assuming workspace membership implies item access |
| Data-source scope | May the underlying source, memory, chunk, embedding, tool output, be retrieved for this person? | Scoping only by tenant, so everything inside a company is shared with everyone in it |
| Tool permission | May the agent perform this specific action with what it found? | Treating read access as implicit permission to send, export or publish |
The third row is the one that is new. Files and database rows have had access policies for decades. Conversation-derived facts, memory episodes, knowledge chunks, embeddings, cached retrieval results and generated documents usually have nothing but a tenant id, which is the beginning of an access policy rather than one. I go deep on that in RAG access control.
Where AI Permission Leaks Actually Come From
None of the failures worth worrying about look like an attack. They look like ordinary engineering decisions that were completely correct in a single-user product.
A tool that searches a tenant-wide table without a requester-scoped filter. It works, it is fast, and it is a full read of everything anyone in the company ever stored. Tool implementations are where access control goes to die, because they are written as integrations rather than as endpoints. See how tool calling actually works for why the tool layer needs the same scrutiny as your API.
A memory system keyed by tenant and agent instead of by source scope and audience. The model now recalls, on behalf of the wrong person, something it was told in confidence by someone else.
A cached agent graph that retains the authority of whoever warmed it. Second user, first user's reach, and nothing in your logs looks unusual.
A revocation that only updates the sharing UI. The retrieval index, the export path, the precomputed digest and the background job never heard about it.
A hidden button. Hidden buttons are not security. Backend enforcement is security. If the API, the resolver, the direct link, the download, the export, the notification and the retrieval query do not each enforce the same decision independently, the interface was theatre.
How RBAC and Resource Permissions Fit Underneath
The AI layer only works if ordinary access control is already right. Two mechanisms, two different jobs, and they are routinely confused with each other.
Role-based access control governs organisation authority. Owner, Admin, Member. It answers: who invites people, who changes roles, who manages billing, who controls sharing, who removes members.
Resource-level access control governs the individual item. Who can view this document, edit this task, open this contact, read this private notebook, download this generated report.
Held together, the four layers read cleanly:
| Layer | Question |
|---|---|
| Role | What may you administer in the organisation? |
| Resource policy | Who may touch this exact thing? |
| Data scope | Which source data may the AI retrieve at all? |
| Tool permission | What may the AI do with it once retrieved? |
Role-based access control alone answers neither of the last two. That is exactly why AI products keep shipping a permissions model that looks complete on the settings page and is not.
Auditability Is How You Prove Any of This Is Real
The final layer is evidence.
If you want a serious company to trust an AI agent with internal work, you need an auditable record of the sensitive events: who requested access, who approved or denied it, who read what, who shared and who revoked, which tool acted, which policy decision applied, what changed, and when.
Audit logs get sold as a compliance line item, which badly undersells them. They are how you investigate an incident, how you debug behaviour nobody can reproduce, and how you demonstrate that enforcement is real rather than asserted. I go further into that, including why the denied requests matter more than the successful ones, in the piece on delegated authority and audit logs.
Frequently Asked Questions
Is role-based access control enough to secure an AI agent?
No. It decides what a person may administer in an organisation. It says nothing about which specific documents, memories or retrieved chunks an agent may pull into context on that person's behalf, and nothing about which tools it may invoke. You need resource-level policy, data-source scope and tool permissions on top of it.
Can you prevent AI data leaks with system prompts?
Not reliably. A system prompt is an instruction, not an enforcement boundary. Once unauthorised data is in the context window, the only thing standing between it and the user is the model's judgment. Filter at retrieval time so the data never enters the prompt.
What does least privilege mean for an AI agent?
That the agent executes with the authority of the human currently making the request, rather than the union of everything the workspace can reach, and that each sensitive action requires its own grant instead of inheriting a blanket one.
Should each AI agent have its own user account and permissions?
It can have its own baseline, but that baseline should be a ceiling rather than a floor. What the agent may actually reach in any given request is the intersection of its own grants and the current requester's authority, never the union.
Where should the permission check live?
On the server, in the query, at the point of data access and at the point of every tool call. Checks in the client, in the prompt, or in a post-processing step over results are all bypassable in ways that will not show up in testing.
Three Things to Take Away
One. AI permissions are not a prompt-writing problem. They are a data architecture and authorization problem, and no amount of instruction tuning converts one into the other.
Two. Give the agent an execution identity that borrows the current requester's authority, and propagate it all the way into the query. Blanket workspace access is a design decision you will have to undo later, under pressure.
Three. Check all four axes: role, resource, data scope, tool. Products that check the first two feel secure and leak through the last two.
Next in this series: how to do access control inside a RAG pipeline, which is where most of the hard work actually is, and then delegated authority and audit logs. If you want a second pair of eyes on how your own agents are scoped, that is the kind of thing I do in agent development engagements.
