Securing an AI agent: what MCP servers and skills can actually reach

En bref. Un agent n'est pas un chatbot : il appelle des outils, porte des identifiants, écrit dans vos systèmes et garde une mémoire. Chacun est un chemin d'accès. Cet article cadre les quatre surfaces — les outils (serveurs MCP), l'identité sous laquelle l'agent s'exécute, les entrées qu'il lit, et sa mémoire — puis la question qu'on oublie toujours : comment le couper à trois heures du matin.

An agent is not a chatbot

A chatbot reads and writes text. The worst outcome is a bad answer.

An agent calls tools. It holds credentials, writes to systems, triggers workflows, and remembers things between sessions. The worst outcome is an action.

That difference is the whole of agent security, and it is why the controls that made a chatbot deployment safe do not transfer. The useful mental model: an agent is a junior employee you have handed a set of keys. The question is not whether the model is trustworthy. It is which keys are on the ring, and who can tell it what to do.

Four surfaces, in the order they matter.

1. The tools: every MCP server is a third party

The Model Context Protocol is how most agents now reach the outside world. An MCP server exposes tools — read a file, query a database, send a message, open a ticket — and the agent calls them.

This is genuinely good architecture. It is also the surface people underestimate, because installing an MCP server feels like installing a library and is closer to onboarding a vendor.

An MCP server is code you did not write, running with the permissions you gave it. A server connected to your ticketing system can read every ticket. One connected to a database can run whatever queries its tools expose. If it is community-maintained, the supply-chain question is the same as any dependency — with the difference that this dependency holds live credentials to a production system.

What to do:

• Inventory what is connected. Most teams cannot list their agent's MCP servers from memory, which is the first finding of any review.
• Read what each tool actually does, not what the README says it does. A tool named search_documents that accepts a raw query string may be a database read with no filter.
• Scope the credential to the tool's job. A server that only needs to read tickets gets a read-only token, not the integration account somebody already had.
• Pin versions. An MCP server that auto-updates is a third party who can change what your agent can do without telling you.
• Prefer servers you can read. For anything touching production, the ability to audit the source is worth more than convenience.

2. The identity: whose permissions is it using?

This is the single most common misconfiguration, and the most consequential.

An agent that runs under an employee's identity — an integration set up with somebody's account, or a service that impersonates the requesting user — inherits everything that person can open. Including the SharePoint sites they forgot they had access to, the shared mailbox from a previous role, and the finance folder somebody granted them in 2023.

A user who would never go looking through those files now has a tireless assistant that will, on request, without knowing it is doing anything unusual.

What to do:

• Give the agent its own identity. A service principal or managed identity, not a person's account and not a shared admin account.
• Grant it only what the task requires. Start from nothing and add, rather than starting from a working integration account and trimming.
• Separate read from write. Most agents need far more read than write. Splitting them means a compromise of the reading path cannot change anything.
• Scope write access narrowly. "Can create a ticket" is a different grant from "can modify any ticket."
• Make the identity auditable. Actions taken by the agent should be distinguishable in logs from actions taken by people. If the agent uses a person's account, every investigation starts by asking whether that person did it.

3. The inputs: anything it reads can instruct it

Prompt injection is not a phrasing problem and it is not solved by better system prompts. It is a trust boundary in the wrong place.

The model cannot reliably distinguish instructions you wrote from instructions embedded in content it reads. If an agent processes an email, a web page, a PDF, a ticket or a document, the contents of that thing are inputs from whoever wrote it — and they can contain text that reads, to the model, like a request from you.

A support agent that reads customer tickets and can also send email is one crafted ticket away from sending email on an attacker's behalf. Nothing about that requires an exploit; it requires a sentence.

What to do:

• Treat every input as untrusted. Not "mostly trusted because it came from our CRM." The CRM's contents were typed by someone.
• Do not put a dangerous tool behind an untrusted input. The combination that hurts is reading attacker-influenced content and holding a tool with consequences. Separate those agents.
• Require confirmation for actions that matter. Sending external email, changing permissions, moving money, deleting anything. A human approval step on a small number of actions costs little and removes most of the damage.
• Constrain the tool, not the prompt. A tool that can only email addresses on an allowlist is robust in a way that "do not send email to strangers" in a system prompt is not.

4. The memory: it is a database nobody classified

Agents that remember across sessions store that memory somewhere. Vector stores, conversation history, a scratchpad in a database.

That store accumulates whatever passed through the agent — customer details, internal discussion, document contents, credentials somebody pasted. It is a data store holding personal information, and it is very often the one nobody has classified, labelled, backed up, or included in a retention policy.

Under Loi 25, personal information in that store is personal information you hold, with the residency and retention obligations that follow.

What to do:

• Know where it lives and who can read it, including the vendor.
• Apply a retention period. Most agents do not need memory older than a few months, and open-ended memory is an open-ended liability.
• Keep it out of prompts where it does not belong. Memory retrieved into context can end up in a response to a different user if scoping is wrong.
• Include it in your data inventory. If it is not on the list, it will not be considered in a breach assessment or a subject access request.

The question everyone forgets

How do you turn it off?

Not "how do we take the feature down" — how does one person, at three in the morning, stop this specific agent from acting, without a deploy and without breaking everything else?

If the answer is "revoke the credential," which credential, and who has that access out of hours? If the answer is "disable the integration," has anyone tried it?

The same applies to logging. When something goes wrong, you need to know what the agent was asked, what it decided, which tools it called and what came back. If prompts and responses are not logged, the investigation consists of guessing.

Both of these are cheap to build before launch and expensive to retrofit during an incident.

A scoping checklist

Before an agent goes near production:

• Every MCP server and tool is inventoried, with what it can reach
• The agent has its own identity, not a person's
• Permissions are least-privilege, read and write separated
• Untrusted inputs and consequential tools are not in the same agent
• Actions with real consequences require confirmation
• Memory is located, retained on a schedule, and in the data inventory
• Prompts, responses and tool calls are logged
• There is a documented, tested way to revoke it
• Somebody owns it by name

In short

An agent is an employee with a keyring, working at machine speed, who believes what it reads.

Most of the work is not about the model. It is deciding which keys are on the ring, making sure the ring belongs to the agent and not to a person, assuming everything it reads is hostile, and knowing how to take the ring back.