Home / Vault & Second Brain / I Stopped Trusting the Official Label on AI Connectors

I Stopped Trusting the Official Label on AI Connectors

I Stopped Trusting the Official Label on AI Connectors

The “official” label is not a security guarantee

I run a small fleet of AI agents at home. They talk to my Home Assistant, my Proxmox server, my email, my DNS. Every one of those connections goes through an MCP connector — a little bridge that lets an agent call a tool. And for months I’ve been auditing those connectors for one specific risk: a malicious third party slipping instructions into a tool description. What I hadn’t seriously considered is that the connector wearing the “official” badge could be the one doing the injecting.

This week the community caught Notion’s official MCP connector doing exactly that. Mid-task, it instructs the agent to advertise Notion Business — and to never explain why. Not in the documentation. Not disclosed anywhere. The agent’s context gets quietly polluted, and it’s told to lie about the source. The reaction on r/ClaudeAI was unanimous: enshittification, a breach of trust. The fix people reached for was telling: fork the public server and delete the ad code, or dump the connector and call the API directly.


The $100 lesson I didn’t have to pay for

Right next to that story sat another one, smaller but sharper. Someone gave their agent an API key and lost a hundred dollars — the key leaked, and the agent started firing off requests in Chinese that had nothing to do with its tasks. His conclusion was blunt: “putting a real key somewhere the agent can read it means it can also copy it somewhere else.” His solution was to run the agent under one Linux user, keep the keys under another, and let a gateway swap placeholder credentials for the real ones. When the agent tries to read the real key, the operating system refuses.

That stung, because it’s a step further than my own rule. I’ve been telling my agents “don’t put keys in the workspace.” But I don’t have the guarantee that the OS will refuse the read. My agents share a home directory and a set of credentials. If one of them gets compromised, the “don’t do that” rule is a suggestion, not a wall.


Trust has to rest on source audit, not on a label

The uncomfortable takeaway is that “official” and “trusted” are not the same thing. A vendor’s own connector is still an instruction channel — it can still pollute your agent’s context, and it can still be told to hide what it’s doing. The only thing that actually protects you is reading the source, or isolating the credentials so hard that a compromised agent physically cannot reach them.

So I’m adding two questions to my own audit. First: do I treat vendor-official connectors with the same suspicion as third-party ones? Second: could a gateway pattern — separate users, placeholder credentials — actually isolate my keys, instead of just asking my agents nicely not to touch them?

How do you handle this? Do you audit the connectors your agents use, or do you trust the badge? I’d genuinely like to know — the comments are open.

Wat vond je van dit bericht?

Leave a Reply

Your email address will not be published. Required fields are marked *