We Connected AI to Our Security Platform. Here's How We Kept Your Data Out of It.

Model Context Protocol, or MCP, has quietly become the standard way to connect an AI assistant to a real system. Point ChatGPT, Claude or a locally hosted model at an MCP server and it can read records, run operations and answer questions in plain language. It is genuinely useful. It is also, if you do it carelessly, one of the fastest ways to hand your most sensitive data to a third party.

We recently built and shipped an MCP server for AETOS, our cybersecurity assurance platform. Connecting AI to a system that holds penetration test findings, vulnerabilities, detection data and client information is exactly the scenario that concentrates the risk. Here is how we approached securing it, and the principles that apply to any MCP server worth trusting.

Start with the threat model, not the features

The interesting question is not what the AI can do for you. It is what can go wrong when an AI sits between a user and a sensitive system. For an MCP server the honest list is short and specific.

• Sensitive data leaving your environment and reaching the AI provider.
• The AI acting with more authority than the person driving it.
• Credentials and secrets being handed out in ordinary API responses.
• Instructions hidden inside returned data steering the model.
• One customer's data becoming reachable from another's session.
• The AI being used to weaken the controls that protect it.

Every control below closes one of those doors.

Minimise what leaves, before it leaves

The single most important control is data minimisation at the boundary. Sensitive values are detected and replaced with tokens inside your own infrastructure, before a single byte reaches the model. The originals stay with you. The AI works with placeholders and never sees the real thing.

We do this in three layers. Pattern matching catches structured data such as IP addresses, credentials and connection strings. Machine-driven entity recognition catches the names, organisations and locations in free text that patterns miss. And a customer-defined list lets an organisation register its own client names, project identifiers and internal terminology, so the things that matter most to it are always protected. Detection runs on your server, and the mapping back to real values never leaves it.

A control that only works when it is switched on is not a control

This is the principle we would most encourage others to adopt. Scrubbing is conditional by nature. It protects you only while it is enabled and configured correctly. That is not good enough for a credential.

So we treat secrets separately and unconditionally. Integration keys, tokens and passwords are masked at the source, in the API itself, and encrypted at rest, so no caller ever receives one in full, whatever any downstream setting happens to be. Defence in depth means assuming any single layer can be bypassed, and making sure the sensitive thing still does not escape. If you only scrub on the way out, a direct call or a changed setting undoes you.

The AI inherits the user's permissions, enforced on the server

An MCP connection should never be able to do more than the person using it could do at the keyboard. The way to guarantee that is to enforce authorisation on the server, on every call, no matter how it arrived. Role-based access control, tenant scoping and least-privilege keys do the real work. Confirmation prompts and tool-level guardrails help prevent accidents, but they are not a security boundary, because the AI can satisfy its own confirmation. Be clear which of your controls are convenience and which are enforcement.

Do not let the AI edit its own guardrails

A subtle but important rule. The protections that constrain the AI must not be editable by the AI. In our server a connected assistant cannot turn off scrubbing, and it cannot add to or remove from the list of protected terms. Those are deliberate, human-only actions. If an AI can rewrite the rules that limit it, those rules are decoration.

Give the customer the choice of where processing happens

Even with everything above, non-sensitive content still reaches whichever AI provider you connect to, and is then subject to that provider's data handling terms. The only way to guarantee that nothing leaves at all is to keep the processing inside your own environment. A good integration lets you choose: a cloud provider that meets your requirements, or a locally hosted model for zero egress. For regulated or sensitive data, that choice matters more than any single feature.

The unglamorous controls still matter

The rest is familiar security engineering, and skipping it is where most integrations fail. The server validates and constrains every outbound request so it cannot be steered at internal infrastructure. Sessions are bound so one cannot be used to reach another's data or credentials. Requests are rate limited and size limited. State-changing actions are audit logged. Errors are written so they never leak secrets or internal detail. None of it is novel, and all of it is necessary.

Test it like an attacker, including your own build

Assume your first version is wrong and prove it. We ran our own MCP server through a live adversarial review, driving it exactly as a customer would. It surfaced a real issue: a configuration secret that reached the model despite scrubbing being enabled. We found it, fixed it at the source, and added coverage so it cannot recur. That standard only comes from trying to break your own work.

The takeaway

MCP is a real step forward for how security teams can work, but the convenience is only worth having if the boundary is built properly.

1. Minimise what leaves, and do it before it leaves.
2. Protect secrets unconditionally, not only when scrubbing is on.
3. Enforce authority on the server, on every call.
4. Keep the AI away from its own guardrails.
5. Give the customer the choice of where data is processed.
6. Test the whole thing like someone trying to break it.

That is the standard we hold our own platform to, and the one we would apply to any AI integration we reviewed. If you are connecting AI to systems that hold sensitive data and want a second pair of eyes on the boundary, that is exactly the kind of work we do.