Agent Marketplace Verification: Who Can Publish?

When an agent marketplace marks a publisher as verified, what did it actually check?

That the person controls an account? That a company exists? That the publisher is authorised to represent the service in the listing? Those are different claims. A badge that leaves the answer open invites buyers to assume more than the marketplace has established.

Agent marketplace publisher verification should establish who is authorised to publish a particular listing, record the evidence behind that decision, and make the limits visible. A persistent identity can give that check a public reference. The marketplace still has to decide what evidence it accepts.

For the broader architecture question, see what belongs in a marketplace versus an identity layer. Here, the question is narrower: what should your marketplace mean when it says a publisher is verified?

Give the badge a specific meaning

Start with the claim you want buyers to rely on.

“Controls this public name” says something about control. “Business identity checked” says something about an organisation. “Authorised reseller” describes a commercial relationship. None of those statements establishes that an agent will handle sensitive data properly or deliver accurate work.

Microsoft makes this distinction in its publisher-verification guidance for Microsoft Entra applications. Its verification concerns the authenticity of the developer organisation. Microsoft explicitly separates that status from app quality, compliance certifications, and adherence to best practices. That is useful discipline for an agent marketplace, too.

You do not need an enormous badge system. You need wording that matches the check. If your process only establishes control of a named service, say so. Reserve claims about business identity or security review for the processes that support them.

And make the explanation accessible from the listing. Buyers should not have to hunt through your terms to find out what the tick means.

Verify the relationship, not just the submitted link

A publisher can paste somebody else's domain into a form. Seeing the same address on a listing and a public profile does not establish that the person submitting the listing controls either one.

The useful check connects three things: the authenticated marketplace account, the exact service identity, and the authority to publish that listing.

Your platform might use a challenge published through a controlled resource, an authenticated confirmation, or a reviewed delegation from the operator. Choose a method appropriate to the identity system and the claim. This is our recommended marketplace design.

Record the full name and its naming system. Keep a display name separate. For the lookup problem behind similar names, use the agent name collision guide.

Control also differs from legal identity. An independent developer can publish under a stable pseudonym. If you claim to have verified a registered business, you need evidence for that additional claim. Buying a name alone does not establish it.

Resellers need particular care. A reseller may have permission to sell access without controlling the service's identity. Your listing should identify that relationship accurately, including which party supplies the service and which party handles the customer's purchase.

Keep imported registry evidence in scope

The official MCP Registry offers a useful example. Its publishing authentication ties publishing rights to namespaces using GitHub or domain-based methods. The permission concerns publication under the relevant namespace.

The registry's own description also separates its metadata role from downstream curation and security scanning. It points to server packages; it does not host their code. Package registries and aggregators have further responsibilities.

If your marketplace imports that metadata, preserve where it came from and when you retrieved it. An authenticated upstream publication does not, by itself, establish that a person claiming the imported listing on your marketplace is its authorised operator.

That second relationship needs a check of its own.

Likewise, do not stretch “published through an authenticated namespace” into “safe to run.” Package integrity, requested permissions, data handling, and runtime behaviour need their own evidence. 

Write a verification statement a buyer can understand

Consider a service called briefworks.agent. A publisher submits it to a marketplace that supports verification of its public identity. The marketplace checks the publisher's authority using its chosen procedure.

A useful listing explanation could read:

Publisher relationship checked. This marketplace checked the publishing account's authority to represent briefworks.agent in the Headless Domains naming system on [check date]. This check does not assess output quality or approve access to your data.

That is an example of wording, not a completed verification or a feature announcement.

Behind the listing, retain enough evidence to explain the decision: the account and listing identifiers, the exact identity checked, the method, the result, and the check date. Include any delegation or expiry that limits the relationship. Keep credentials and other secrets out of the public explanation.

The public statement can stay short. The evidence needs to be specific enough that another reviewer can understand why the label was granted.

Decide what makes the check stale

A verification result describes a relationship at a point in time. Accounts change hands. Operators move services. Delegations expire.

Before issuing the label, decide which changes require another check and how you will detect them. A public record update will not automatically notify every marketplace.

These are suggested policy triggers.

A temporary lookup failure deserves investigation; it is not proof of fraud. Equally, an old successful check should not stay green indefinitely after the relationship it describes becomes uncertain.

Removing a badge also does not revoke existing API credentials or stop every running integration. If your marketplace needs those effects, connect the review decision to the systems that enforce access.

Use a public identity as evidence you can revisit

Headless Domains can provide a named public reference and published records for a service. That reference can help a marketplace find the information it needs to inspect and revisit it later.

The records still require interpretation. An operator's published claim and your marketplace's verified conclusion should remain distinguishable. The identity-record reading guide covers that distinction in more detail.

This approach applies across Headless Domains' namespaces: .agent, .chatbot, .boss, .factory, .protocol, .bpo, and .manifest. The suffix does not determine the strength of your verification process.

A marketplace can accept other identity methods. Requiring every publisher to buy a particular name is a platform policy choice, not a prerequisite for listing an agent. For the wider relationship between naming, discovery, and permissions, see the Agent Identity Stack.

Start with one listing. Write the exact claim you want to verify, choose the evidence needed to support it, and decide when the result must be checked again. Then make that scope visible to the buyer.

To inspect a Headless Domains identity as part of that process, use the current Headless Domains machine instructions.