Connecting AI agents to company knowledge with MCP: who controls what

MCP security for company knowledge is shared between four parties: the person using the assistant, the AI application, the service that issues access tokens where one is used, and the server that holds the knowledge. The Model Context Protocol (MCP) requires the application to ask the person before it uses a tool, but its specification says it cannot enforce security by itself. Most of the control therefore sits with the server, which decides what each request may read or change.

This guide is for IT and security teams, and for the knowledge manager they work with, when someone asks to connect ChatGPT, Claude, a Copilot Studio agent or an in-house agent to the knowledge base. It covers what the specification and public guidance say, where they stop, and the questions to settle before the first connection. For the wider picture of what AI answers from, start with our guide to AI knowledge management.

What MCP changes for a knowledge base

MCP is an open standard for connecting AI applications to other systems. The AI application (ChatGPT, Claude, Copilot Studio) is the host. The system that holds the knowledge runs an MCP server. The server offers tools that the model can call, such as "search the knowledge base" or "create an article", and data that the application can read. The current version of the specification is dated 28 July 2026. The protocol is hosted by the Linux Foundation, and technical decisions sit with named maintainers.

Two things change compared with a search box or an export:

• The agent can act as well as read. A server can offer tools that write. Whether an agent may create, edit or delete content is decided per tool, by the server.
• The request comes from software, on behalf of a person. Every call carries a token. Whose identity that token stands for decides what the agent can see.

Who controls what in an MCP connection

The specification splits the work between the parties. It also says, in its overview, that MCP "cannot enforce these security principles at the protocol level": each implementation has to.

The last row carries the most weight. The authorisation chapter works with tokens and scopes, and the tools chapter lets a server show different tools to different callers. Neither describes how a server should filter each document to match a person's rights. That job belongs to the system that holds the knowledge.

MCP permissions: whose rights apply

This is the question teams ask most often before they connect anything, and it has two common answers.

Each person signs in with their own account. The token stands for that person, so the server can apply their own rights to every search and every read. Two people who ask the same agent the same question can get different answers, because they can open different documents. This matches the principle that the French cybersecurity agency ANSSI called need-to-know in its 2024 guidance: an assistant should not give anyone access to more than they could already see.

The agent uses one shared account, often called a service account. Setup is simpler, but the agent sees everything that account can see, and every person who talks to the agent sees it too. The server can no longer tell who is asking, so per-person rights disappear and the logs show only the agent. The OWASP MCP Top 10 lists "Privilege Escalation via Scope Creep" and "Context Injection & Over-Sharing" among its risks for this reason. It is a community project of the Open Worldwide Application Security Project (OWASP), still in beta.

A shared agent raises the same question in a new form. When someone builds an agent with their own sign-in and then shares it with colleagues, the agent may keep the builder's connection or ask each colleague to sign in. This depends on the agent platform and on how the connection was set up, so check it before you share.

MCP security: the risks that matter for company knowledge

General MCP security lists cover developers' laptops and code tools. For a knowledge base, five risks stand out. Each one comes from the specification's security best practices, the OWASP list or the OWASP MCP security cheat sheet.

1. Scopes that are too wide. An assistant that only needs to read gets the right to write. The specification asks clients to request the least access they need.
2. Instructions hidden in content. An article, or a file attached to it, can contain text written to steer the model. OWASP calls this prompt injection via contextual payloads. Treat every document the agent reads as data, not as instructions.
3. Token misuse. A server that accepts a token issued for another service, or passes its own token on, breaks the chain of trust. The specification forbids both.
4. Servers nobody approved. People add servers on their own. OWASP calls them shadow MCP servers. A list of approved connections, and a way to see what is connected, is the answer.
5. No trace. OWASP lists the lack of audit and telemetry. Check what the server and the assistant each log: who asked, which tool ran, which document came back.

Read, write, delete: what an agent may change

Reading is the common case. Writing is where the rules from public bodies are clearest. In April 2026, CERT-FR, the French government's computer emergency response team, said tools given to an AI agent should be limited to what is strictly needed, and that human validation must be required for actions with side effects. The CNIL, France's data protection authority, and France's AI and digital council published an exploratory note on agentic AI in July 2026 that also asks for human validation of the most critical decisions. The MCP specification says there should always be a human in the loop who can refuse a tool call.

For a knowledge base, three settings put those rules into practice:

• writing is off until someone decides to turn it on;
• anything the agent writes is saved as a draft, and the usual approval steps apply before it is published;
• there is no tool to delete an article.

MCP vs RAG: which one for company knowledge

Retrieval-augmented generation (RAG) was described in 2020: before the model answers, a system finds relevant passages and adds them to the prompt. In most companies, RAG means a pipeline that your engineers build: documents are copied into an index, cut into passages and searched by meaning. MCP is a way for an assistant to call the source system directly, at the moment it needs something.

The two often work together. An MCP server can run a meaning-based search behind its tools, which is RAG on the server side. A research team compared an agent that decides its own searches with a fixed retrieval pipeline. The agent cost up to 3.6 times more to run, and a well-tuned pipeline could match or beat it (Ferrazzi et al., 2026, preprint accepted at ACL 2026). Choose MCP when people want to use the assistant they already have, with their own rights. Choose a pipeline when your team owns the assistant and needs full control over how passages are chosen.

MCP governance: questions to settle before you connect

Teams that plan an MCP connection ask us the same questions. Settle them first, in this order:

1. Which assistants may connect, and who approves a new one?
2. Does each person sign in, or does the agent use a shared account?
3. When an agent is shared, whose rights apply?
4. Does the agent need to write, or only to read? Start with read-only.
5. Can you block one assistant for everyone at once, and can each person remove their own access?
6. What is searched? Article bodies, attached files, tags, summaries: check each one.
7. Can the agent tell whether a document is current? A review date and an owner on each document give it something to check.
8. What is logged, and where?
9. When will you review access again? ANSSI's 2024 guidance suggests a regular review, for example monthly, of what AI tools may reach.

What a governed setup looks like in Elium

Elium, the European knowledge management platform we build, includes an MCP server. Here is how it answers the questions above, as described in our MCP documentation. Every request runs with the signed-in person's own Elium rights. Administrators see every connected assistant in one list and can make an assistant read-only for everyone, for tokens issued from then on. Deleting an assistant makes every token it holds invalid at once. Each person can remove an assistant's access to their own account. Writing is off by default, edits are always saved as drafts, and no tool deletes an article. When an assistant reads an article, it also receives the review date, the approval status and the owner, so it can say how current its source is. Our MCP server page lists what an assistant can do and which assistants have a setup guide.

Where to start

List the AI assistants people in your company already use, and ask which of them are connected to internal content today. Pick one knowledge area with clear owners. Connect one assistant to it, read-only, with each person's own sign-in, and test the same question with two people who have different rights. If you want to measure how ready your content is first, our AI readiness score takes 15 questions. Our guide to Work IQ explains how this works when the agent lives in Microsoft 365.

FAQ

Common questions

Who is responsible for security in an MCP connection?

The server that holds the knowledge carries most of it, because it decides what each request returns and whether it can write. The MCP specification requires the AI application to ask the user before it calls a tool, but it says MCP cannot enforce security by itself.

Should an AI agent use a service account or each user's login?

Each user's login, wherever the content has different rights for different people. With a shared service account, the agent sees everything that account can open, every user of the agent sees it too, and logs can no longer say who asked.

Whose permissions apply when a shared agent reads a knowledge base?

It depends on how the agent's connection was set up. If the agent keeps its builder's connection, everyone who uses it gets the builder's rights. If it asks each person to sign in, each person gets their own. Check this before you share an agent.

Can MCP limit what an AI agent can see?

Yes, but through the server, not the protocol. MCP carries a token and its scopes; the server decides which tools to offer and which documents to return. A server that applies each person's own rights shows the agent only what that person can open.

What are the disadvantages of MCP?

MCP leaves most security to each implementation: authorisation is optional, and the specification does not say how a server should filter documents by person. A server can also offer tools that write, so the risks of a connection depend on the server you choose and how you configure it.

Why use RAG instead of MCP?

Use RAG when your team builds and owns the assistant and wants full control over which passages reach the model. Research published in 2026 found that a well-tuned retrieval pipeline could match an agent that runs its own searches, at a lower cost.

What is the difference between MCP and RAG?

RAG copies documents into an index and adds the best passages to the model's prompt; MCP lets the assistant call the source system live. With MCP, the source applies its own permissions on each request. Many MCP servers use a RAG-style search behind their tools.

Can an AI agent change content through MCP?

Only if the server offers tools that write and you allow them. Public guidance in France asks for human validation of actions with side effects, so keep writing off at first, save what an agent writes as drafts, and do not offer a delete tool.

Sources

• Model Context Protocol, specification, version 2026-07-28: overview, authorization, tools and security best practices, 28 July 2026. Checked 30 October 2026.
• Model Context Protocol, governance and stewardship. Checked 30 October 2026.
• Linux Foundation, formation of the Agentic AI Foundation, 9 December 2025. Checked 30 October 2026.
• OWASP Foundation, MCP Top 10, beta, and MCP security cheat sheet. Checked 30 October 2026.
• CERT-FR (ANSSI), bulletin CERTFR-2026-ACT-016, 13 April 2026. Checked 30 October 2026.
• ANSSI, Recommandations de sécurité pour un système d'IA générative, version 1.0, 29 April 2024. Checked 9 October 2026.
• CNIL and Conseil de l'IA et du numérique, exploratory note on agentic AI and personal data, 20 July 2026. Checked 30 October 2026.
• P. Lewis et al., Retrieval-augmented generation for knowledge-intensive NLP tasks, NeurIPS 2020. Checked 30 October 2026.
• P. Ferrazzi et al., Is agentic RAG worth it?, preprint, accepted at the ACL 2026 Industry Track, revised April 2026. Checked 30 October 2026.

Data and sources

This guide is built from public sources: the MCP specification and its project pages, the Linux Foundation, OWASP, French public bodies (ANSSI, CERT-FR, CNIL) and peer-reviewed or preprint research, read between 9 and 30 October 2026. The questions in the governance section are the ones that customers, and teams considering Elium, asked us about MCP between July and October 2026. We give no names. Elium's capabilities are described from our product documentation.