Third-party connectors are your agent's supply chain

Writing every tool an agent uses by hand is slow, and it is increasingly unnecessary. Most systems an agent might touch — the calendar, the ticket tracker, the file share, the database — now have a ready-made connector, often speaking an open protocol such as MCP. Install it, paste a token, and by lunchtime the agent can do a good deal more than it could in the morning.

That convenience imports three things at once: code that runs inside your environment, credentials it holds on your behalf, and text your model reads and believes. Most teams review the first loosely, the second barely, and the third not at all.

What you are actually installing

Code that holds your keys. A connector is a program with a token to one of your systems. If it is malicious, or its maintainer’s account is compromised, it does not need to fool the model; it already has the key. This is ordinary software supply chain risk, which is why the OWASP Top 10 for LLM Applications lists supply chain among its risks.

Instructions written by a stranger. Every tool comes with a name and a description that the model reads to decide when and how to use it. That description is prompt text written by a third party. It can tell the model to include the conversation so far in every call, or to prefer this tool over the one you built, and almost nobody reviewing the integration ever reads it.

Behaviour that changes after approval. A connector reviewed in spring can update in summer with new tools, new descriptions and new destinations. If versions float, what you approved is not what runs.

Scopes chosen by the author. Connectors tend to request the broadest permission that makes every feature work. Your agent needs, say, two of the connector’s twelve operations; the token allows all twelve.

A shared room. Every connector loaded into an agent puts its descriptions into the same context. The text that came with a harmless weather tool sits next to the tool that sends email, and the model does not keep them in separate rooms.

Dependency discipline, plus one addition

The controls are the ones you already apply to software dependencies. The addition is that a connector’s descriptions are reviewed as prompt, because that is what they are.

Infographic

Before a connector reaches production

• A named ownerSomeone accountable for why it is there and what it may do.
• A pinned versionUpdates arrive as reviewed changes, never automatically.
• Reviewed descriptionsTool names and descriptions read as prompt text and diffed on each update.
• Minimal scopeOnly the operations the task uses; everything else filtered out.
• Its own credentialA dedicated token, revocable without touching anything else.
• Isolated runtimeSeparate from other connectors, with outbound traffic limited to its target.
• Re-tested on changeAgent behaviour evaluated again whenever a connector version moves.

An inventory with owners. Which connectors each agent loads, who asked for them, and what for. A connector nobody can justify is removed, not tolerated. This is harder than it sounds, because connectors are easy to add from a developer’s own machine and rarely pass through procurement. An agent in production loads only connectors from the approved list, enforced by configuration rather than by asking nicely.

Pin, review, then upgrade. Versions are fixed, and an update is a change like any other: the code diff, the description diff, and a run of the evaluation set before it reaches production. A changed tool description is a changed agent.

Narrow in front, not inside. When a connector exposes more than the task needs, put a thin layer in front of it that offers only the required operations, rather than trusting the model to leave the rest alone.

Run it as untrusted code. Its own process or container, its own credential, and outbound traffic limited to the system it connects to. A calendar connector has no reason to reach anything other than the calendar.

Build, wrap or adopt

None of this is an argument against connectors. For read-only, low-stakes sources, an adopted connector with a pinned version and a narrow token is a sensible trade. The closer a connector sits to something irreversible — sending, paying, deleting, changing a customer record — the more of that path should be code you own and have read.

Wrapping is often the middle path. The adopted connector keeps doing the protocol plumbing, and your own typed operations, limits and checks sit in front of it. You get the speed of the ecosystem without letting a stranger’s code decide what the agent may do.

The same standard either way

An agent’s safety does not depend on who wrote the tool. In an AI agents engineering engagement, a third-party connector is held to the same standard as a tool we write ourselves: an explicit list of operations, permissions of its own, and a reason to be there that someone has signed.