The MCP protocol made one thing almost trivial: giving tools to an agent. An MCP server exposes an API, a database, an internal service, and the agent knows how to call it. That is exactly what makes it a security topic. Every MCP server is a door into a system. Multiply the servers, and you multiply the attack surface, unless the architecture is designed to prevent it.
In a regulated environment, the right question is therefore not “how many tools can we connect?”, but “how do we connect many without widening what an attacker, or an agent that makes a mistake, can reach?”. Here are the principles of a secure AI agent architecture when the MCP servers number in the dozens.
An MCP server is a door, not just a connector
It is tempting to see an MCP server as one more technical adapter. That is a framing error. From a security standpoint, an MCP server is an access path: it gives the agent, and therefore anyone who can influence the agent, the ability to act on the system behind it. A well-crafted prompt injection does not compromise the agent as such, it uses its tools.
The consequence is direct: you do not reason about how much you trust the agent, but about what each tool makes possible in the worst case. An agent is as dangerous as the most permissive tool it can reach.
Read-only by default
The first principle is a default stance: read-only. An agent that investigates, correlates and recommends needs, in the vast majority of cases, only to read. MCP servers therefore expose read capabilities first, and any write or action capability is the exception, justified case by case.
In practice, this means the right is carried by the tool, not the agent: a “read” MCP server and an “action” MCP server are two distinct surfaces, with distinct permissions. You add an action only when it is at once necessary, reversible and validated, exactly the boundary described in our evaluation framework. Everything else stays read-only, which massively reduces what can go wrong.
Separate the domains
The second principle is compartmentalisation. An agent connected to fifteen systems must not hold unified access to those fifteen systems. Each MCP server covers one domain (monitoring, tickets, identity, network) with its own rights, its own technical identity, its own scope. The compromise or malfunction of one server must not spread to the others.
This separation also applies across environments. Isolating domains often means spreading access over several accounts or several network boundaries, which introduces its own authorisation pitfalls, the ones we detailed regarding cross-account access to an agent runtime. The principle stays the same: the blast radius of an incident must remain bounded to the domain concerned.
Attack surface is counted in permissions, not servers
Adding an MCP server does not widen the attack surface in itself. What widens it is the permissions that server carries. Ten strictly read-only servers, compartmentalised and traced, present less risk than a single server able to write everywhere.
This is why the real work happens at the level of roles and rights, not the number of integrations. Each technical identity must follow least privilege, be bounded by authorisation guardrails, and stay auditable. We documented this work in an AWS context, with the concrete patterns for deploying an agent runtime under an IAM permissions boundary: it is there, in the detail of roles and policies, that the security of an MCP architecture is won or lost.
Trace and revoke
One last principle underpins all the others: every tool call must be traced, and every access revocable in a single move. Traceability lets you understand what an agent did, replay an incident, and prove that a domain was not touched. Revocability lets you cut off a compromised or failing MCP server without dismantling the whole structure. In practice, this relies on short-lived technical identities and access tokens dedicated to each server, which can be invalidated in isolation without touching the rest.
Together, these two properties turn an MCP architecture from a worrying black box into a governable system: you know who has access to what, what was done, and how to stop it all.
What to take away
Exposing many MCP servers to an agent is not a quantity problem, but a design one. Read-only by default, strict domain separation, least-privilege permissions, traceability and revocation: these five principles let you connect many tools while keeping the attack surface bounded and known.
It is this rigour that makes an agent architecture acceptable to a technology organisation in a regulated environment, and it fits within our industrialisation method: a powerful agent is only valuable if the organisation keeps control of what it can reach.
Are you connecting AI agents to sensitive systems and want to scope their access surface? Let’s talk.