Agent marketplace

What is an agent marketplace?

An agent marketplace is a catalogue where you find an AI agent somebody else built, install it, and let it work on your own data. It looks like an app store, and that resemblance is the problem.

Two shapes exist. The first is a store inside a product you already pay for. Microsoft calls its Agent Store in Copilot the central hub where you discover and install agents, with agents from Microsoft, from partners and from your own organisation side by side. Salesforce opened AgentExchange on 4 March 2025 with more than 200 launch partners, selling actions, topics and prompt templates for Agentforce. That same catalogue now lists whole agents, subagents and MCP servers. AWS added an AI Agents and Tools category to AWS Marketplace on 16 July 2025, so a third-party agent or an MCP server now lands on your cloud invoice.

The second shape is an open catalogue. The official MCP Registry, backed by Anthropic, GitHub, PulseMCP and Microsoft, has been in preview since September 2025. It holds metadata pointing at MCP servers rather than the servers themselves, and anyone who can prove they own a GitHub account or a domain may publish under that namespace.

The difference between the two is what gets checked before a listing appears. Salesforce runs every listing through its own security review first, and calls the result a curated selection vetted for security. The MCP Registry says the opposite in its own documentation: it delegates security scanning to the package registries underneath it and to the marketplaces that consume its data, and calls its own job namespace authentication and metadata hosting. It confirms who owns the name, not what the code does.

The four questions a listing does not answer

A listing gives you a name, a publisher, a description and a screenshot. Four other things decide whether the install button is safe to press.

What can it reach, and under whose identity? The Microsoft 365 admin centre has a Data and tools tab per agent showing what it can read (organisation files, email, calendar, public web pages) and which tools it can call, third-party MCP servers included. That same page admits the tab is sometimes empty, because the platform never reported the metadata. And an agent with application permissions acts at organisation level with no signed-in user behind it, which is not the same risk as one that only acts for the person who started it.

Who maintains it, and what happens when they stop? A listing shows a publisher name and a last-updated date, not whether that publisher is a company with a support commitment or one person with a side project. For an MCP server from an open catalogue, the honest answer is often that nobody has promised you anything.

What does it cost per run, not per licence? Salesforce prices Agentforce Flex Credits at 500 euro per 100,000 credits and a standard action costs 20 credits, so an action is 10 cent. An agent that takes eight actions per case and handles 400 cases a month runs 3,200 actions, around 320 euro a month, before anybody has called it a success.

What does it do when it fails? Not whether it fails, but what happens next: retry, stop, hand over to a person, or carry on with a wrong answer. Microsoft counts exceptions per agent, meaning sessions that ended in an error, but that activity view, the risk indicators and the security tab all need a Microsoft E7 or Agent 365 licence, so a smaller tenant sees a thinner screen than the documentation shows.

Installing an agent versus installing an app

Both start with a button in a catalogue. The difference is what the thing can reach once it is running.

An app has a fixed set of things it does. It asks for permissions up front, those permissions fit on one screen, and it acts when a person clicks something. If it can read your calendar, it can read your calendar today and next month.

An agent gets an identity, a set of tools and a goal written in words. Which tool it calls, with which arguments and in which order, is decided at run time by a model reading text: your prompt, the document it just opened, the ticket a customer wrote. Its reach is everything its tools can touch put together, and the thing that sets it off is often not you.

Installing an app is a permissions decision you can read on one screen. Installing an agent is closer to onboarding a contractor: you hand over credentials and judgement at the same time, and the judgement is the part no listing describes.

One more effect follows from that. The descriptions of an agent's tools reach the model as instructions, so a hostile tool description can steer the agent while the tool keeps doing its advertised job. Tool poisoning has its own entry; what matters here is that it arrives through an install.

A worked example: the mail tool nobody checked

In September 2025 a package called postmark-mcp was sitting on npm. It presented itself as the MCP server for Postmark, the transactional email service, and across its first fifteen versions it did exactly that. Version 1.0.16, published two days after the package first appeared, added one line: every outgoing message was blind-copied to an address the author controlled. Postmark had not published the package at all and said so publicly on 25 September 2025. Koi Security, the firm that found it, counted 1,643 downloads before npm removed it.

The tool did its advertised job throughout. Whoever installed it had handed over a sending key and the benefit of the doubt that comes with a familiar brand name, and one update turned that into a copy of every invoice, password reset and internal mail. Four questions would have caught it, in this order.

1. Is this really from the vendor it names? Postmark's own documentation did not list the package. That check takes a minute and it is the one that fails most often.

2. Which credential does it want, and how narrow can I make it? A sending key limited to one domain. The account key also reads your logs and your templates, so it has no business here.

3. Who here owns it, and where is that written down? A name in the agent registry. Somebody's memory does not count.

4. Would we notice if it started doing something else? A blind copy on every message shows up in the mail provider's own log. Nobody was reading that log.

Approving, owning and reviewing what gets installed

Four controls hold up in practice. Somebody decides who may install from a marketplace, and that somebody is not everyone. The Microsoft 365 admin centre already works this way for agents built inside your tenant: a maker submits, the request appears under Agents, the administrator reviews the capabilities, data sources and custom actions, then publishes to the store or rejects it.

Anything installed gets a registry entry with an owner: a person, a purpose, the systems it can reach, a risk level. It gets its own credentials, scoped down, never an account shared with a colleague or another agent, which is the difference between withdrawing one grant and disabling a person. And it gets a review date on the day you install, because publishers update their agents quietly and an approval you gave in March describes software that no longer exists in September.

Shadow installation is why those four matter more here than they used to. A marketplace inside a tool your team already has open removes every step that used to make a purchase visible: no invoice, no supplier form, no ticket to IT, no new login to create. Somebody in sales finds an agent in a store inside the application they were already using, and it runs before lunch. That is the shadow AI pattern with credentials attached. Blocking an agent in the Microsoft admin centre removes it from everyone who had already installed it, which only helps you if you know it was installed.

What to watch out for with an agent marketplace

A vendor's curation is not a security guarantee. Microsoft is precise about this in its own admin centre: the certification tab shows publisher attestation, which is the developer's own account of how the agent handles data, next to Microsoft 365 Certification, which is an independent assessment valid for twelve months. Those two labels sit on the same screen and they mean very different amounts of work.

The listing describes the agent, not your configuration. The same agent is harmless with read access to one SharePoint site and dangerous with write access to your ledger. What the catalogue promises and what you granted are separate facts, and only the second one is yours.

The failure mode is not a breach. It is a dozen installed agents, four that nobody can explain, two whose owner left the company, and a bill that grows per run. The value is real and it sits with the narrow, dull agents: one that reads incoming invoices, one that drafts replies from your own knowledge base, one that watches a queue. Install those, put a name next to each one, and set the date you will look again.