AI Connector Security: Read the Code First

We were looking for connectors for a client recently, a mid-sized company with a lot of systems that need to talk to each other. One looked close to perfect. It covered forty or fifty tools, including most of the ones on the list, and AI connector security was front and center in how it was sold.

The promise was that no data leaves your laptop. That sounds like the strongest privacy claim a tool can make. It is worth slowing down on, because it is not a guarantee. It is a description of where the copy goes.

Why is a local copy worse than a remote one?

Because AI connector security depends on where records end up, and your systems of record are the most protected place your data lives while a laptop is the least.

The accounting system, the ticketing system, the customer database: those sit behind access control, audit logging, backups, and someone whose job includes noticing when something odd happens. A copy on a laptop has none of that. It has whatever disk encryption is switched on and whoever happens to be holding the machine.

For a company with compliance obligations, the damage is more specific than a general feeling of risk. You lose the ability to answer where customer data lives, which is a question you have probably answered in writing, for a customer, in a contract.

The site passed every check most people run

It looked legitimate, and looking legitimate is cheap now.

The design was good. There was a company behind it and a public code repository, which is more than many tools offer and is exactly the signal most buyers treat as proof. Read a little closer and the copy had the cadence of something generated rather than written, and there was no privacy policy and no terms of service anywhere on the site.

That gap is the thing worth internalizing. For AI connector security, a polished site, a company name, and a repository are now the low bar rather than the high one. None of them tell you what the software does with your data.

Our AI connector security checklist before installing anything

We read the documentation and the source before anything gets installed, not after.

• Read what it claims to do, then read the code to see whether that is what it does
• Look up whoever wrote it, and see whether they have a findable background in this work
• Find the privacy policy and the terms of service, and treat their absence as an answer
• Work out exactly what access you are granting, and what that access would allow at its worst
• Decide what happens to the data it touches, including where copies end up and who can reach them

In this case the connectors themselves were weak, and then the copying behavior showed up in the source. We stopped there. Nothing was installed, no client data was involved, and the whole exercise cost half an hour of researching and reading.

Is this specific to the Model Context Protocol?

No. The pattern is older than the protocol and will outlive it.

Model Context Protocol, usually shortened to MCP, is the emerging standard for connecting AI assistants to tools and data. It is a genuinely good development, and the specification is public. What is new is not the risk, it is the surface: connectors are easy to write, easy to publish, and they ask for broad access to the systems that matter most.

Most people building them are doing careful work. Some are enthusiastic and not yet skilled enough for the access they are requesting, and the packaging looks identical from the outside.

What this costs you if you get it wrong

The tool that copies your data is not usually the tool that gets you in trouble.

AI connector security failures surface late. A customer asks where their records are held, or an auditor does, and the candid answer involves a laptop. By then the copy has been there for months and nobody remembers making it.

This is the same reasoning behind checking whether AI tools train on your data. Both come down to one question asked early: where does this end up, and who can reach it.

Frequently Asked Questions

Do I really need to read the source code?

Someone does, and it does not have to be you.

If nobody on your team can read it, that is a real answer about your AI connector security posture and which tools you should be installing. Either restrict yourself to vendors with a compliance posture you can verify on paper, or get someone to read it for you before the install rather than after the incident.

What are the fastest AI connector security signals to check?

Missing privacy policy and terms of service, first.

After that: a creator you cannot find anything about, marketing that describes safety without describing mechanism, and any claim that sounds like it removes a tradeoff rather than moving it. Broad access requested without an explanation of what each permission is for belongs on the same list.

Is local-first architecture always a problem?

No, and plenty of it is well built.

The problem is not local execution, it is copying records out of a governed system into an ungoverned one and describing that as privacy. A local tool that queries a system and holds nothing is a different thing from one that replicates the database onto a laptop.

What should we do about connectors already installed?

Find out where the data lives and how much access the connector has been granted.

Start with anything touching customer records, financial data, or credentials. The question is not whether the tool is trustworthy in general, it is what exists on which machines right now as a result of it.

Half an hour of reading

We did not install it, and nothing happened. That is the entire story, and it is the point.

The cost of finding this out was half an hour. The cost of not finding out would have landed on a client, months later, in a conversation with their customers. If you are working out which AI tools your team should be allowed to install, that is a conversation we have often, and it is part of what our engagements cover.