Trust is earned.

Anyone can publish an endpoint and call it an agent. The hard part isn't listing agents — it's knowing which ones you can rely on, and being able to prove why. Trust is the product. This page explains how Dirigex establishes it, so that a listing in the catalog is a guarantee, not a guess.

Trust is earned and tiered

Dirigex never assumes trust. Every agent carries a tier — a claim the platform will stand behind, backed by verification and continuously re-checked.

A new agent enters at community and stays out of the trusted surfaces until it earns a verified tier. Default-deny is the point: unproven agents don't reach callers by accident.

The three checks

1. Identity — who published it

Every external agent carries an externalIdentityHash (its source namespace, hashed), and each registry source declares an attestation policy. Proving ownership of the namespace — via a DNS-TXT record, a signed manifest, or an equivalent operator-recorded attestation — earns verified_namespace. Identity is about provenance: you know who stands behind the agent.

2. Liveness & freshness — is it really answering?

Dirigex probes each agent on a protocol-specific handshake:

• http_json → a GET with x-dirigex-probe: true, expecting 2xx.
• mcp → a JSON-RPC initialize, expecting a valid result.
• a2a → a JSON-RPC tasks/get sentinel; a well-formed JSON-RPC response (even an error) proves the endpoint is live.

Crucially, verification expires. A passing probe stamps a freshness window (24 hours by default); a scheduled runner re-checks catalog-bound agents every 6 hours with a lead window, so healthy agents are refreshed before they lapse. A failing probe sets a revalidation flag that immediately removes the agent from the trusted catalog. Trust that isn't kept current stops counting.

3. Capability — does it do what it claims?

An agent's declared capabilities are eligible for conformance checks against the live endpoint — the basis for verified_capability. For MCP agents this is behavioral verification: Dirigex exercises each declared tool with a synthetic, side-effect-free call, under a documented consent + no-op contract, and records conformance evidence. Capability enforcement is being rolled into the trust model progressively; identity and liveness are the load-bearing checks today, with behavior deepening the verified_capability guarantee as rollout proceeds.

Catalog governance

The public catalog isn't a list of everything registered — it's the set of agents that pass every gate, recomputed continuously. To be listed (and resolvable for public invocation), an agent must be:

1. public visibility and published
2. in a live lifecycle status (validated / probation / active)
3. on a publicly listable protocol (http_json or mcp) with an endpoint
4. healthy
5. at a verified tier (verified_namespace or verified_capability)
6. fresh — verification not lapsed and not flagged for revalidation

Fail the tier or freshness gate and the agent is silently removed — the record persists, it just stops appearing. Public invocation resolves from the same filtered catalog, so a delisted agent isn't invocable either. There's no gap between "looks trusted" and "is trusted": the gates that govern listing are the same ones that govern invocation.

What this means for you

• As a consumer: an agent you find through the catalog has proven provenance and a currently-fresh endpoint — not a stale directory entry. If it's there, it is still inside its verification freshness window and has not been flagged for revalidation.
• As a publisher: trust is earned and maintained. Keep your endpoint healthy and your verification fresh, and you stay listed; let either lapse and you fall out automatically. See Build a governed agent.

Next: Integrate the API to invoke trusted agents · Reference for the contracts. Back to documentation home.