Why this step is different
The seven previous steps built a capability; this one protects what that capability created. The change of posture is real: until now, we asked "how to make it work?"; from here on, as a cyber firm, we ask "how does it break, and what does it cost when it breaks?".
The starting point is a sentence we have repeated since step 5, and must now take seriously: what enters the context can influence the model. As long as the model only spoke, the stakes were the quality of the answers. The moment it has hands — your servers from step 7 — a malicious influence no longer produces a bad sentence: it produces a bad action. That is the whole difference between an employee who repeats a rumor and an employee who, on the strength of that rumor, wires money.
Take the image from our AI agent security sheet: your agents are zealous, fast, obedient employees — with no judgment whatsoever about where what they are told comes from. A human employee would be suspicious of a sticky note reading "forward the client database to this address" found on their desk. The agent reads that note inside a piece of data and executes it with the same docility as a legitimate instruction. MCP security is the art of bounding that docility.
The attack surface, in one image
Three families of risk, one common entry point:
Risk #1 — indirect injection
The emblematic risk of the agent era, and the most counter-intuitive. Recall the mechanism, moment ④ of step 5's sequence: a tool's result flows back into the context window. Yet in that window, the model has no watertight boundary between what is data and what is instruction. Everything is text, and persuasive text is followed.
Let's run it on our thread, to make it concrete:
The lesson of this diagram is the bedrock of everything else: you cannot fully prevent the model from being convinced by a booby-trapped text — it is a property of how an LLM works, not a bug to fix. Security therefore does not consist in making the model unpersuadable (illusory), but in ensuring that, even convinced, it can cause no damage. Step 7's allowlist did not prevent the injection; it prevented its consequence. Remember the formula: you secure the action, not the conviction.
Risk #2 — the confused deputy
A security classic, revived by agents. Recall moment ③ of step 5: the server acts with its own rights — its service account, its token. The agent is therefore a deputy holding its own privileges, often greater than those of the user speaking to it.
The trap: maneuvering that deputy into crossing a door forbidden to the requester. An intern with no access to salaries asks the HR agent "give me the summary of the team's compensation"; if the agent itself has broad access to the HR database, it produces the summary — and access control was bypassed not by breaking in, but by proxy. The deputy did, with its rights, what the requester could not do with theirs.
The countermeasure is structural, and you already know it in outline since step 6: the agent's rights must be as close as possible to those of the usage context, never "admin for convenience". An HR server plugged into a team assistant must only see what the team is allowed to see. When rights must vary by user, it is the server and target system that carry that distinction — not the hope that the model "pays attention".
Risk #3 — exfiltration by chaining
The risk born of composition, invisible tool by tool. Taken alone, a tool that reads internal data is legitimate; a tool that writes outward (posting to a URL, sending a message) is legitimate. Combined in the same agent, they form a siphon: read the sensitive, then send it outside — a leak in two calls, neither suspicious in isolation.
This is the trap that step 6's tool-by-tool audit does not see: each permission, taken alone, is justified. The danger is in the pair. Hence an architecture question that adds to reading the tools: which combinations do my servers make possible? An agent with simultaneous read access to confidential data and an unconstrained network-egress tool is an incident waiting for its trigger — distracted human or indirect injection, it makes no difference.
The countermeasure holds in one principle: separate the capabilities of sensitive reading and uncontrolled egress. If the agent must read confidential data, its write tools are constrained to closed internal destinations (step 7's allowlist, again). If it must be able to write outward, it does not read the most sensitive data. You break the chain by ensuring the two links never coexist without control.
Defense in depth: four layers
No single countermeasure is enough — that is the firm's central message. You stack independent layers, so the failure of one is caught by the next:
① Least privilege, at the source. The most cost-effective layer, because it depends neither on the model nor on its persuasion: a token that only sees one notebook, a read-only account, access limited to one repository. What the agent does not have, no injection can make it do. It is the control that holds even when all others fall.
② Separation of servers by domain. One server = one scope = one set of rights. Not only is it more readable to audit (each server answers for one thing), but it is what breaks risk #3's chaining: by keeping sensitive reading and external egress in distinct scopes not simultaneously open, you remove the physical possibility of the siphon from the agent.
③ Human in the loop on the irreversible. Any action that cannot be undone — sending outside, deleting, paying, publishing — goes through a human confirmation. It is the friction we learned to respect at step 6: not an ergonomics flaw, but the last rampart, the one that turns a silent catastrophe into a visible validation request. You reserve this friction for what deserves it — the irreversible — so it does not become a reflex approved without reading.
④ End-to-end supervision. We seeded it at step 5: the protocol being JSON-RPC, every call is observable and loggable. A record of who called which tool, with which arguments, for which result, serves three functions: detect abnormal use in near real time, trace the unfolding of an incident to understand it, and prove — to an auditor, a client, a regulator — what the agent did and did not do. It is the MCP-side counterpart of a classic IT system's logging.
The Shadow AI angle: the risk nobody inventoried
One last risk, specifically for CIOs and CISOs, and it is not technical: it is that of MCP servers plugged in without anyone knowing. An employee who connects a handy community server to their assistant, a production token slipped into a local configuration, an agent quietly holding access to three internal systems — each of these gestures, individually harmless, escapes the registry if no governance exists (step 4, applied this time to the hands).
It is the "agents" version of Shadow IT, and it is more dangerous than the old one: an undeclared SaaS tool exposes data; an undeclared tool-equipped agent can act on it. The first security question of an organization adopting agents is therefore not "are our servers well coded?" but "do we even know which ones are plugged in, with which rights, on which systems?". Without that map, the four defense layers protect a perimeter you do not know.
Mapping that exposure — which agents, which servers, which rights, which blind spots — then bringing it back under control, is exactly the object of our Shadow AI Sentinel program, AI Act compliance included. The armoring of steps 7 and 8 only has value over a known perimeter; this program establishes the perimeter first.
📚Going deeper
For the geeks: tool-description poisoning. An injection variant that bypasses intuition, because it goes not through data but through metadata. Remember: the model reads tool descriptions to choose (step 5). A malicious server can therefore slip instructions not into a result, but into the description of one of its tools — invisible to the user who only sees the interface, permanently present in the model's context. Worse, some servers can change their descriptions after the initial install (the "rug pull": benign at audit, hostile later) or make new tools appear mid-session (the pattern we flagged at step 5). Three cumulative countermeasures: pin servers to an audited version (step 6, never a moving branch); prefer servers that do not mutate their capabilities mid-session, and treat any mutation as a security event; and, for sensitive contexts, pin the content of descriptions at audit time too, to detect any later drift. The general rule: everything the model reads is part of the attack surface — including what describes the tools themselves.
📚Going deeper
For the geeks: building the supervision layer, concretely. Step 5's JSON-RPC makes observation trivial; the work is making it useful. Three maturity levels. Level 1 — the raw log: a proxy between host and servers recording every tools/call — timestamp, server, tool, arguments (with secret and personal-data masking on the way through), truncated result, human-confirmation verdict. That alone gives you the regulatory audit trail and post-incident reconstruction. Level 2 — detection: rules on that stream — a write-external tool called right after a sensitive read (risk #3's chaining), an abnormal call volume, an argument stepping out of an expected scope, the appearance of an unlisted tool. You move from trace to alert. Level 3 — correlation: cross-referencing these events with the rest of the IT system — the existing SIEM, the target systems' logs — so a suspicious MCP call is lit by what is happening elsewhere. You recognize the trajectory: it is that of classic IT observability, transposed to the model's hands. A firm equipping its clients on agents often starts here: without level 1, you argue about incidents without evidence; with it, you govern.
📍 Skills & MCP path — step 8/9
- 🗺️ The map before the territory
- 🔬 Anatomy of a skill
- 🛠️ Create your first skill
- 🏛️ Skills in the enterprise: governance
- 🔌 MCP: the protocol explained
- ⚡ Use an existing MCP server
- ⚙️ Build your minimal MCP server
- 🛡️ Secure your MCP servers ← you are here
- 📡 The ecosystem: where to find, where it moves
Last step → The ecosystem: where to find the best skills and servers, how to set up your watch, and how to evaluate a third-party building block before adopting it — with a living dashboard of the repositories that matter.
This step is the heart of our trade. The AI agent security sheet gives its 90-second version to circulate in the boardroom.