Why AI Assistants Bypass Your Permissions — and Why "MCP or API?" is the Wrong Question
A field report about an architectural decision that matters more than the choice of protocol.
I built an AI assistant. Not as a toy, but as a work tool: a bot in Mattermost that accesses our project infrastructure — Notion for documentation, YouTrack for tickets, OpenProject for project planning, Git for code.
The bot works. It answers questions about project status, finds documents, summarises discussions.
And then it started sharing information from Project B in Project A's channel.
What Happened
The setup was clean: every Mattermost channel has its own conversation history. The bot only receives the chat history of the current channel. Summaries are created overnight, separated by channel. So far, so correct.
The problem was not in the conversation. It was in the tools.
When someone in Project A's channel asks: "What is the current status of the migration?", the bot searches Notion. And Notion returns everything that matches the search term "migration" — including documents from Project B, Project C, and the internal strategy paper on corporate reorganisation.
The LLM has no malicious intent. It does not even have a concept of "project boundaries". It receives a question and a list of search results and builds the best possible answer from them. That some of these results do not belong in this channel is something it does not know. And it cannot know, because nobody tells it — and because "telling via prompt" is not a security measure.
Why This Is Not Just a Comfort Problem
One might think: project information lands in the wrong channel, that is unfortunate but not dramatic. That is incorrect. A concrete scenario:
In the "Project Beta" channel, a project manager and a team leader are working. The project manager has access to Project Alpha and Project Beta. The team leader only has access to Project Beta. That is what the permission matrix specifies.
The project manager asks in the channel: "Are there dependencies on the migration in Project Alpha?" The bot searches Notion, finds the relevant documents from Project Alpha, and responds — in the channel, visible to both.
The team leader now has information from Project Alpha. Not because someone made a mistake. Not because a system was hacked. But because the bot did exactly what it was built to do: give the best possible answer to a question.
This is an access violation through an intermediary. The bot bypassed the permission boundaries of the channel — not through an exploit, but through its normal function.
With a human project manager there is social control. They know the team leader has no access to Project Alpha, and formulate accordingly carefully. The bot does not have this awareness. And it gets even more uncomfortable: the team leader probably does not even notice that they are seeing information that was not intended for them. There is no "CONFIDENTIAL" label on it. It appears as part of a helpful bot response.
The Problem in Three Layers
What looks at first glance like a configuration gap turns out on closer examination to be an architectural problem on three levels:
Tool visibility. Which tools may the bot use in a particular channel at all? This is the simplest level. There are gateways and proxies that can filter this. For many scenarios it is too coarse, however — you do not want to block Notion entirely, but restrict access to certain areas.
Data within the tools. The bot may use Notion — but which databases, which pages? It may query YouTrack — but which projects? This restriction must be different per tool and per context.
The LLM's knowledge. Even if the tools are correctly filtered — if the LLM has seen information from another context in an earlier message, it can reproduce it. The information is in the model context, and no subsequent filter retrieves it from there.
The Wrong Question: MCP or API?
My first reflex was: the problem lies with the protocol. MCP — the Model Context Protocol, which is currently establishing itself as a standard for connecting AI assistants to external tools — knows authentication and authorisation, but no context scope. It can ask "Who are you?" and "What are you permitted to do?", but not "In which context are you currently working?".
So I thought: then we go through direct API calls. There we have full control, can inject the scope ourselves, do not need to wait for a protocol that lacks the necessary dimension.
But that was the wrong turn. Because the problem is not MCP vs. API. The problem is more fundamental.
The Right Question: Who Calls the Tool?
Whether an AI assistant accesses tools via MCP or via function-calling with direct APIs — in both cases the LLM decides which tool it calls and which parameters it passes. The protocol is exchangeable, but the architecture is identical: the LLM is the agent, the tools are its instruments, and the results flow unfiltered into its context.
You can put a proxy in front of it that enforces the scope — meaning it manipulates the search parameters or filters the results before they reach the LLM. This works, but it remains a downstream protection mechanism. The LLM still has the initiative, and the proxy must know for each tool how "scope" looks in its specific API.
The actually relevant distinction is not the protocol. It is the question of who has control over the tool call: the AI or the infrastructure.
Three Architectures, Three Maturity Levels
This results in three fundamentally different approaches that in practice correspond to different security requirements:
The LLM as agent. The model receives a list of available tools — whether via MCP or function-calling — and decides itself what it calls. This is flexible and quick to set up. It is also the approach that most tutorials show and that most teams implement first. Context isolation is an unsolved problem here. For internal, non-sensitive applications this may be sufficient. For everything else it is an open barn door — and as the scenario with the team leader shows, a single question in the wrong channel is enough to breach permission boundaries.
The LLM with policy proxy. Between the model and the tools sits an enforcement layer that knows the context and restricts every tool call accordingly. The LLM still calls the tools, but the proxy manipulates the request — it injects scope filters into the search parameters, it filters the results before they reach the model. Better control, but the proxy needs tool-specific configuration for each connected system. And theoretically the LLM can challenge the proxy through creative parameter choices if the filtering is not watertight.
The orchestrated backend. The LLM has no tool access. It is a language layer, not a decision instance. The business logic sits in an orchestrator that knows the context, calls the right APIs with the right scope, prepares the results, and only passes to the model what it needs for the answer. The LLM formulates a response from prepared, filtered data — and can only use what the orchestrator has given it. The scope is architecturally enforced, not by policy. This is the most secure variant. It is also the one with the most development effort.
What This Means for Organisations
These three maturity levels are not an academic distinction. They have immediate consequences for every organisation integrating AI assistants into its project infrastructure.
In classical access control, the concept is known as "environment" in ABAC models. An employee has access to Project A and Project B. But when working in the context of Project A, information from Project B should not flow into their workspace — not because they have no access, but because the context does not require it and the mixing represents a risk.
Need-to-know principles, Chinese walls in finance, tenant separation in critical infrastructure — all of this requires not just access protection, but context separation. And exactly this context separation is missing in the first two maturity levels.
One might object: then let the bot act with the respective user's credentials. Then the backend systems filter automatically. In practice this regularly fails — not every system supports OAuth delegation, not every company policy permits it, and the user boundary is not identical to the context boundary. A project manager has access to all their projects, but expects in Project A's channel an answer in the context of Project A. And even if the answer is correct for the project manager — it is visible to everyone else in the channel, who may have fewer permissions.
The Questions That Need Answering
Whoever is currently integrating AI assistants into their project infrastructure should be able to clarify three things:
What information does the assistant see when processing a request? Not which it may see — which it actually sees.
Who decides which tool is called with which parameters — the AI or the infrastructure?
And: who can read the response — and does everyone among those readers have permission to see the information it contains?
The last question is the one most frequently forgotten. Because with an AI assistant in a group chat, the question does not determine who sees the answer. The channel determines that. And the channel knows no permission matrix.
Andre Jahn is a freelance Solution Architect specialising in legacy modernisation and AI integration. He builds the things he writes about — and writes about the things that go wrong in the process.