A connector is a third-party dependency that acquires a workspace credential in about two clicks. Every control I have written about governs what it does after that. None of them asks who published it.
I have written a fair amount about the Model Context Protocol, and I have written all of it from the wrong end. The IAM playbook was about a server my own team operated against our own AWS accounts, where the question was which permissions sat behind the tool manifest. The approval-gap piece was about what happens when a connector executes a write with no confirmation screen in front of it. Both ask what a connector can do once it is running. Neither asks what comes first.
Who wrote it, and how did it get in.
I run information security and DevOps at SavvyMoney, where we sit behind more than 1,500 financial institutions, which means I own both the third-party review process and the pipelines that route around it. In that job, a new piece of software that holds a credential and reaches into a system of record does not simply appear. It gets a named vendor, a security questionnaire, a review of what it executes, a contract with data-handling terms, and a line in an inventory somebody can produce on request. That is not bureaucracy for its own sake. It is the record you hand an examiner who asks who has access to member data.
A connector clears none of it. An engineer opens a plugin panel in a coding agent, picks a listing, chooses an install scope, authenticates to the vendor with a real workspace account, and goes back to work. Elapsed time under a minute. No purchase order, no reviewer, no entry anywhere the risk function reads. The thing that just entered the environment is a third-party dependency holding a credential and an action surface, and its acquisition channel is a developer menu.
A connector with no purchase order is still a third-party relationship
The usual objection is that none of this is procurement because nobody bought anything: no invoice, no MSA, no negotiated DPA, just a free listing in a tool the engineer already had. Banking regulators closed that argument two years before most people had heard of MCP. The Interagency Guidance on Third-Party Relationships: Risk Management (opens in new tab), issued jointly by the Federal Reserve, FDIC, and OCC and published at 88 FR 37920 on June 9, 2023, applies to "any business arrangement between a banking organization and another entity, by contract or otherwise." It then says the quiet part out loud: "A third-party relationship may exist despite a lack of a contract or remuneration." The same guidance lists "maintaining a complete inventory of its third-party relationships" among sound risk-management practices.
Read those sentences next to a plugin panel and the shape of the problem is obvious. The absence of a contract is not an exemption from the gate. It is precisely the case the drafters anticipated, because a decade of free integrations had already arrived without paperwork and carried real data anyway. A connector holding an OAuth grant into a ticketing system or a repository is a business arrangement with whoever wrote it, and "we did not pay them" is not an answer that survives a supervisory exam.
This is the argument I have made about being the third party in someone else's diligence, pointed inward. If I expect a financial institution to ask me hard questions about what my software touches, I do not get to skip the same question about a connector an engineer installed on a Tuesday.
The label on the listing describes the review, not the reach
To Anthropic's credit, the tiering here is documented and honest. Their connector verification documentation (opens in new tab) defines three states. Verified means Anthropic reviewed the connector for quality and security. Community means a third-party developer built it and "it passed Anthropic's automated checks, but Anthropic has not reviewed it in depth." Custom means you added it yourself and Anthropic has not reviewed it at all.
Then comes the sentence that belongs on every vendor-risk wall. Anthropic writes that the label "is a quality signal. It affects how the connector is displayed and discovered in the directory, not how the connector itself functions: once connected, a community connector works the same way as a verified one." The badge governs discovery, not reach. A community connector and a verified one receive the same OAuth grant, expose tools into the same instruction channel, and act with the same authority as the account behind them. Every AI vendor review I sit in opens with the same reassurance: the integration is read-only and it is from a reputable name. Both halves of that sentence are usually about the badge. Neither half is about the publisher. Anthropic's directory documentation adds a detail worth sitting with: no domain-ownership proof by DNS or .well-known is required for a directory listing, because that requirement applies only to the open MCP Registry. A listing carrying a familiar product name has not necessarily proved it controls the domain that name refers to.
A bundled plugin ships vendor code and vendor instructions in one install
The acquisition problem sharpens when the unit of installation stops being a single connector. Anthropic's plugin documentation (opens in new tab) is explicit that a plugin contributes commands, skills, agents, hooks, MCP servers, and language servers, and that its "external integrations" category exists to bundle pre-configured MCP servers so you can connect without manual setup. The catalog spans GitHub, GitLab, Atlassian, Linear, Notion, Vercel, Supabase, Slack, and Sentry.
The same page states the risk in language no security team could improve on: "Plugins and marketplaces are highly trusted components that can execute arbitrary code on your machine with your user privileges. Only install plugins and add marketplaces from sources you trust." A second warning adds that Anthropic "doesn't control what MCP servers, files, or other software are included in plugins and can't verify that they work as intended." Arbitrary code at user privilege from an unreviewed publisher is a category my team knows how to handle, even if we handle it badly under deadline.
What I have no process for is the other half of that payload. A bundled plugin also ships skills and agents, which are prose instructions the model reads and follows. That is not code, so no scanner parses it. It is not configuration, so no drift detector flags it. It is persuasion, authored by a third party, delivered into the model's instruction channel, and treated as guidance by a component that already holds the credential. I wrote once that an SBOM nobody reads is compliance cosplay. This is worse, because the bill of materials for an agent has a layer no SBOM format describes. A manifest that enumerates packages and omits instructions is not an inventory of what influences the agent's behavior.
The tooling is closer than the practice. Recent Claude Code versions show a "Will install" section listing a plugin's commands, agents, skills, hooks, and MCP and LSP servers before you install it, and claude plugin details prints the same component inventory afterward. That is a bill of materials with a review step attached. In every environment I have looked at, it is a screen people press Enter through.
The rug pull is documented, not hypothetical
Provenance is not a property you verify once at install, because a publisher's identity is stable and its behavior is not. In September 2025, researchers at Koi published an analysis (opens in new tab) of an npm package named postmark-mcp that copied a legitimate email-service connector's codebase and republished it under the same name. Fifteen versions, 1.0.0 through 1.0.15, behaved like the original. Version 1.0.16 added a single line that silently BCC'd every outbound email to an address the attacker controlled. The package was pulling roughly 1,500 downloads a week.
Nothing about the publisher changed between 1.0.15 and 1.0.16. Same name, same description, same install command. The fifteen clean releases were the attack, they were how the package earned the trust that made the sixteenth worth shipping. No install-time review catches that, because at install time there is nothing to catch.
Anthropic states the general case flatly in the same verification doc: "A connector's developer controls which tools it exposes and can change them at any time." That is the vendor telling you the menu is mutable and the mutation is theirs to make. A connector inventory recording what a tool could do on the day it was reviewed is a snapshot of a moving object.
The mitigations already exist and already have names. Anthropic's community marketplace pins each plugin to a specific commit SHA. Official Anthropic marketplaces auto-update by default; third-party and local development marketplaces do not. Those are version pinning and update policy, two of the oldest supply-chain controls we have, sitting in a developer tool's settings file where no change-management process is looking for them.
The gate already ships in the product, nobody routed anything to it
Here is what changed my mind. I went looking for the missing control and found it already built. Claude Code supports managed marketplace restrictions: an administrator can declare approved marketplaces in managed settings, install plugins at a managed scope users cannot modify, and set strictKnownMarketplaces to stop engineers adding catalogs of their own. On the Claude side, a Team member without connector permission does not see a connect button on a directory listing at all. They see Request, and the request lands in an admin console where someone with authority enables it or dismisses it.
That is a procurement workflow. It has a requester, an approver, an approval record, and a denial path. The reason it feels novel is not that the capability is missing, it is that the capability lives in a developer settings file and a workspace admin console while accountability for third-party risk lives three floors away with whoever signs the attestation. Nobody connected the two, so the queue sits empty while the installs happen at user scope.
If you want one action for Monday, that is it. Open the connectors page in your workspace admin console, turn off the permission that lets members enable connectors on their own, and watch the request queue for a week. The list you get back is your unmanaged third-party inventory, assembled for free by the people who built it. Then publish the approved marketplace list, so the fast path is also the sanctioned path.
Record six things before the connector holds a credential
What I want at install time is not a lengthy review. It is a short, boring record that makes the connector visible to processes that already exist. Six fields cover it.
- The publisher tier, written down. First-party from the company that owns the product, a third-party wrapper around someone else's API, or a server your own team operates. Three different trust models that look identical in a connector list.
- The component inventory, not just the tool list. Every skill, hook, agent, and server the install brings, because the instruction layer is part of the payload.
- The exact version you approved, pinned. A commit SHA or a version, plus a named human who owns the decision to accept the next update.
- The terms you accepted on someone's behalf. Directory listings carry vendor terms and a data-handling posture. Someone should read them before member data moves.
- The identity it borrowed and the scope of that identity. Which account, which workspace, read or write, and which human owns the credential.
- A review date and a removal trigger. Claude Code already surfaces plugins unused for at least two weeks across at least ten sessions. That signal is a decommissioning queue nobody is working.
None of those six requires a new tool. Five are columns your third-party inventory already has, and the sixth, the component list, is printable from the CLI. The gap is not capability. The gap is that connectors got classified as developer configuration instead of as vendors, and configuration does not get a gate.
Here is the honest version. Asked for a complete inventory of third-party relationships that touch regulated data, I would produce a tidy spreadsheet of contracted vendors, and it would be missing every connector an engineer authenticated into a repository or a ticket system with a real account. That omission is not a documentation lapse. It is the definition of an unmanaged third-party relationship, in the language the regulators already published.
So the reframe I am asking for is small and uncomfortable. A plugin directory is not a feature menu. It is an acquisition channel with an approval workflow, a publisher tier, a version, and a set of terms, which makes it procurement whether or not anyone in procurement has heard of it. Treat it that way while the inventory is still short enough to write down by hand.
I would like to hear from teams who put a real gate in front of connector installs without becoming the department engineers route around. Specifically: did you go with an approved-marketplace allowlist, an admin-approval queue, or a detect-and-clean-up posture, and what did the developers do the first week after you turned it on? That is the part nobody writes up.