Strangers With Capabilities
Bolting unvetted third-party skills onto an agent that already holds the keys — because a “marketplace” sounds like someone checked.
What it is
You extend your agent by installing skills, plugins, or MCP servers from a community catalog. Each one is code written by someone you’ve never met, and once installed it runs with everything the agent already has — your inbox, your files, your credentials, your ability to spend money — not just once, but on every invocation, indefinitely. The “marketplace” framing makes it feel curated. It isn’t.
How it happens
An agent is only as capable as the tools wired into it, and the catalog is right there: a skill for everything, one click to add. The person doing the installing is often not an engineer — it’s whoever is exploring what their agent can do. “Add the skill that does X” feels exactly like installing an app. So they do, the agent gains a new power, and nobody read the code — because reading the code was never part of the motion.
Warning signs
- New agent capabilities get added by “install from the catalog,” and no one can say who wrote them.
- The words “marketplace” or “store” are doing load-bearing work in everyone’s sense of safety.
- Nobody can list, from memory, every skill, plugin, or MCP server the agent currently has installed.
- Installed skills run with the agent’s full standing access — email, files, credentials, spend — and nobody scoped them down.
- “Is this one safe?” has never been asked — or was asked once and answered “it’s popular.”
- The people installing skills are the people least equipped to read what a skill actually does.
Why it’s dangerous
Two things stack. First, the App-Store fallacy: a real app store has a review process, sandboxing, a revocation mechanism, and a company on the hook. A community skill catalog usually has none of that — it’s closer to running a stranger’s shell script than to installing a reviewed app, but it feels like the latter because it’s dressed as a “marketplace.” The word implies a bouncer at the door. There isn’t one.
Second, the blast radius is standing, not momentary. A bad skill doesn’t just do damage at install time — it’s wired into an agent with ongoing, autonomous access to your most sensitive systems, and it gets to act every single time the agent runs. A browser extension can read your tabs; an agent skill can read your inbox, email your customers, and move money, on a schedule, while you sleep.
Don’t confuse this with Slopsquatting: there, the AI hallucinates a dependency and an attacker squats the name — accidental. Here, a human deliberately installs a real, published capability without vetting it. Same supply chain, opposite door.
The AI-era hinge: pre-agent, granting third-party code the ability to act in your name took deliberate integration work — API keys, OAuth scopes, a deploy. Now it’s a one-click “add skill,” and the friction that used to force a “wait, what does this thing get access to?” conversation is gone. The capability arrives faster than the judgment about whether to grant it.
How to prevent it
Treat every skill, plugin, and MCP server as a third-party dependency with standing access to production — because that’s exactly what it is. The bar to add a capability should be at least as high as the bar to add a library to your codebase: who wrote it, can you read what it does, what does it touch, and what’s the least access it can run with? “It was in the marketplace” is not an answer to any of those questions.
For a lot of what’s in these catalogs — convert a file, extract text, reformat something — the build-versus-trust math has quietly flipped. The skill is small and self-contained, and the same AI you’d use to install it will write you your own in a few minutes. A utility you generated and can actually read beats a stranger’s you didn’t, and it carries none of the supply-chain risk. Save the vet-and-adopt path for genuinely complex capabilities — a real integration with a maintained upstream — where rolling your own would be its own mistake.
And keep a list. You cannot reason about the blast radius of an agent whose installed capabilities nobody has enumerated. An agent’s skill set is part of its attack surface; treat the inventory as something you own, not something that quietly accretes.
The serious team fix
Three things, reinforcing each other:
- A vetting step before any capability is installed — and the spoken acknowledgment that the catalog isn’t vetting it for you. Someone who can read code reads it first. AI is excellent at the first pass: “summarize everything this skill can access and flag anything it does beyond its stated job.” The default answer to “should we add this?” is no until that pass happens. Kill the App-Store assumption out loud — a marketplace listing is a distribution channel, not a seal of approval.
- Least privilege for every granted capability. A skill that formats text does not need send-email or spend-money access. Scope each capability to the minimum it needs; don’t let everything inherit the agent’s full keyring by default. The blast radius of a bad skill is exactly the access you handed it — so hand it less.
-
A maintained inventory of installed skills, owned like any
other dependency. What’s installed, who approved it,
what it can touch, when it was last reviewed. The same way a
serious team knows its
package.json, it knows its agent’s capability list — and can pull one fast when a skill turns out to be malicious or abandoned.
“Marketplace” implies a bouncer at the door. There isn’t one. You’re the bouncer — and right now you’re waving everyone in, then handing them your keys on the way past.