An agent marketplace is a distribution channel for software that will hold credentials and take actions inside customers' environments. That makes the review gate between "a publisher created a listing" and "a customer can install it" the most security-relevant part of the whole system.

It is also the part most likely to be implemented as a status field with insufficient enforcement behind it. The failure is not usually a missing review step — it is a review step that the publisher can satisfy themselves.

The Listing Lifecycle

Before any listing exists, the publisher themselves has to be established: a verified organization identity, a contact, and agreement to publisher terms. A marketplace where anyone can become a publisher anonymously will distribute malware.

From there, a listing moves through a small number of states, and the exact names matter less than one property: a listing is either reviewed and public, or it is not public. Everything before review — being drafted, awaiting review, returned for changes — sits on the same side of that line. Everything after publication needs a way back across it, for a security finding, a terms violation, or a publisher request.

The state that leaks most often is the one awaiting review, because "submitted" feels like a step toward public, and code that filters on "not a draft" lets it through.

The invariant across all of this: exactly one state appears in the public catalogue. The public query must filter positively on approved rather than negatively on draft. Negative filters break the moment a new state is added, and adding states is normal.

Test this the same way you test any leak boundary: create a draft listing with a distinctive title, fetch the unauthenticated catalogue, and assert it is absent. Submit it for review and assert it is still absent. Both assertions in CI.

Self-Certification Must Be Structurally Impossible

Here is the failure mode that matters most. The review endpoint is under an administrative path, and the check on it is a role check. In a multi-tenant platform, "administrator" is ambiguous: an organization owner is an administrator of their organization. If the review endpoint accepts any administrator, an organization owner can approve their own listing.

That is not a review process. It is a status field the publisher controls.

The requirement: listing review must be authorized to platform staff specifically — a system-level administrator role that no customer organization can hold, checked by a guard that is distinct from organization-role checks. And the check must be on the specific route, not inherited from a controller-level assumption, because administrative controllers accumulate routes with mixed authority requirements.

Two adjacent checks worth making explicit:

Resubmission does not bypass review. A rejected listing that the publisher edits must return to a pre-approval state. An implementation where editing an approved listing leaves it approved lets a publisher get a benign version approved and then change it.

A reviewer cannot review their own organization's listing even if they are platform staff. The conflict-of-interest check is separate from the privilege check.

This pattern — an approval that the requester must not be able to grant themselves — recurs throughout platform administration. See maker-checker for platform administration.

What Review Should Actually Check

A review that reads the description and checks for typos adds latency without adding safety. The substantive checks are about capability and provenance.

Requested scopes and permissions. What connections will this agent ask a customer to grant? Are they proportionate to the described function? A listing that describes itself as a summarizer and requests write access to a customer's CRM is the finding. This is the single highest-value review item.

Data flows. Where does customer data go? Does the agent call the publisher's own endpoints, and if so, what is sent? Is there a data processing agreement? Residency claims? A listing that ships customer prompts to an unnamed third party needs to disclose that. See data residency for AI agents.

Provenance and integrity. Who published it, is the artifact signed, does the version pin resolve to what was reviewed. Review of a floating version reviews nothing, because the code can change after approval. See securing the agent supply chain.

Tool inventory. For agents exposing or consuming MCP tools, the enumerated tool list with descriptions — including descriptions, since those enter customers' model contexts and are an injection vector. See MCP server vetting and registry risk.

Claims consistency. Does the description match observable behavior? Benchmark or evaluation results, if published, need methodology. Unsubstantiated compliance claims ("SOC 2 compliant") should require evidence or be removed.

Prohibited categories. Whatever your terms exclude — credential harvesting, scraping tools that violate third-party terms, anything designed to evade controls.

Automate what can be automated so human review time goes to judgment: signature verification, dependency scanning, scope extraction, tool inventory extraction, and a diff against the previously approved version. Automated checks should gate submission, so a listing that fails them never reaches a human.

After Approval

Approval is a point-in-time assessment of an artifact that will change.

Version-pinned approval. The approval attaches to a specific version. New versions require review — expedited for minor changes, full for scope changes.

Material-change triggers. Any change to requested scopes, data flows, or endpoints requires re-review regardless of version semantics. A patch release that adds a new outbound destination is a material change.

Monitoring installed listings. Signals from the runtime: agents from a listing calling destinations the review did not anticipate, guardrail hits, unusual data volumes, customer reports. This is the only way to catch a listing that was approved honestly and later became harmful.

A revocation path that works. Removing the listing from the catalogue does not affect existing installations. You need the ability to disable the installed agent's connections across customer organizations, plus notification to affected customers. Design this before you need it, because the first time you need it will be urgent.

Publisher accountability. Earnings held pending, a suspension mechanism, and a record of prior findings that informs review of their next submission.

Common questions

How fast should review be?

Fast enough that publishers do not route around you, which in practice means days rather than weeks for a straightforward listing. The way to get there is automation on the mechanical checks plus a tiered process: low-risk listings (read-only scopes, no external data flow) get a lighter review than ones requesting write access to customer systems. Uniform depth across all listings means either slow review of simple ones or shallow review of risky ones.

Should the marketplace verify security claims?

Verify what you can cheaply and structurally: signatures, scope proportionality, dependency hygiene, tool inventories. Do not attest to claims you have not tested — a marketplace that implies it has security-tested every listing takes on liability it cannot support. State clearly what review covers and what it does not, and require publishers to substantiate compliance claims with evidence rather than assertions.

What about listings that are just a wrapper around a third-party API?

Those are the majority, and the review focus should be the data flow: what leaves the customer's environment, to whom, under what terms. The wrapper's own code may be trivial while its data-sharing implications are significant. Require the third party to be named in the listing so customers can make their own assessment.

How do I handle customer-side approval as well?

Marketplace review is necessary and not sufficient — a customer's own governance should gate what gets installed in their organization, with their own review of requested scopes. The marketplace's job is to present the scope request clearly and enforce that the granted scopes match what was requested, so the customer's decision is informed and the installed agent cannot quietly exceed it. See governed agent resource connections.

How Praesidia approaches marketplace publishing

Praesidia's marketplace runs a two-step gate: publishers register, create draft listings, and submit for review, and only approved listings appear in the public catalogue — drafts and pending-review listings are never reachable from the unauthenticated browse surface. Listing review is reserved to platform staff, so a publisher cannot approve their own listing regardless of their role in their own organization, and resubmission returns a listing to review rather than to approved.

Installed listings operate through governed connections with enumerated scopes, so the authority a customer grants is explicit and revocable, and every action is recorded with the agent, connection, and outcome. See agent task marketplaces and escrow and the Praesidia documentation.