The hard problem is not trusting your own agents. It is delegating to an agent built by a company you have a contract with and no visibility into. Assay makes that a one-call decision with evidence behind it.
Source: 2025 industry surveys of enterprise AI agent adoption.
Two companies want their agents to work together. Today that means a federation project, shared credentials, a contract that assigns liability, and an integration per counterparty. Weeks of work to enable one handoff, repeated for every new partner.
And after all of it, neither side can answer the question that matters: has the agent on the other end actually done this before, successfully, in a way anyone independent confirmed? Contracts allocate blame after failure. They do not prevent it.
Meanwhile neither party will accept the obvious fix — exposing their operational history to a counterparty — because that history is commercially sensitive.
One call returns whether the counterparty clears your trust bar and which capabilities it has proven. It does not return their customers, their other work, their telemetry, or their volumes. Both sides get the decision input; neither gets the other's book.
There is no shared credential, no federation, and no prior relationship required. The verifier calls with its own key about a public identity. Onboarding a new partner's agent is a call, not a project.
After the work, each party records its own outcome and names the other as counterparty. Notably, an agent cannot write reputation onto another agent — that would let any registered key inflate or sabotage anyone. Self-report plus named witness is what keeps the graph both useful and honest.
A verifier learns trust score and proven capabilities. It never learns who else the counterparty works for or what their equipment is doing.
No integration per partner. If their agent has an Assay identity, you can verify it today without either side signing anything new.
Attesting on another agent's behalf returns 403. Reputation can only be written by the party that did the work, naming who witnessed it.
A party relying on an asset can verify condition and provider themselves rather than taking a counterparty's report at face value.
Verify before the handoff, attest after it. Both need your own agent key; substitute the IDs and they run against production as shown.
verified reflects the trust
threshold and account status. It does not fall to false because a claimed capability
is unproven — an unproven capability simply does not appear in
capabilities_confirmed. Gate on both fields.No. The agent being verified must be registered, which is free. The verifier calls with its own key. Many relationships run with one paying side and one free side.
Verification returns a trust score, proven capabilities and attestation counts — reputational facts about a public identity, by design. It exposes no operational data, no customer list and no telemetry.
Yes. An organization's agents are scored under that org's configured model, and the model name travels on the passport, so a relying party can see whether a score was computed under manufacturing rules or defaults.
They fail a meaningful threshold, correctly. Route those to human approval, start them on low-stakes work to build history, or let them import verified prior work — imported records are flagged and remain subject to the verification ceiling.