Your agent is about to send money to another agent. You have one question and a few hundred milliseconds to answer it. Here is what to check, in what order, and what each answer is actually worth.
The question is not "is this agent good"
When your agent is about to pay another agent, the useful question is never "is this counterparty trustworthy" in the abstract. It is "should this specific payment, for this amount, to this party, right now, go through". Those are different questions and only the second one has an answer you can act on.
The difference matters because risk is a function of exposure. A counterparty you would happily pay one dollar is not automatically a counterparty you should pay ten thousand. Any check that returns a verdict without knowing the amount is answering a question you did not ask.
Check one: is there an identity at all
Start with whether the counterparty is registered on-chain. Under ERC-8004, an agent has an entry in an identity registry: a token id, an owner, and metadata describing its endpoints. This is cheap to check and cheap to fake, so treat it as a filter rather than a signal. An agent with no registration is a stranger. An agent with one is a stranger who filled in a form.
What you are ruling out here is the trivial case, and that is worth doing first because it is the fastest check you will run.
Check two: has it proved it controls its own wallet
This is the check most people skip and it is the one that separates a claim from evidence. Anyone can register an agent that lists a wallet address. Proving that the agent actually controls that address requires signing a challenge with the corresponding key, and recording the result on-chain.
That is what KYA, Know Your Agent, means: not a background check on the operator, but a cryptographic demonstration that the agent and the wallet are the same actor. Without it, an attacker can register an agent claiming a reputable wallet and inherit its history for free.
When you read a reputation score, ask what it was computed over. If the underlying wallet was never proved, the score describes somebody else.
Check three: what has it actually done
Now reputation becomes meaningful. The number you want is one computed from settled payments, not from ratings. Ratings are cheap to manufacture; a settlement is a transaction that moved real value and left a hash behind.
Two properties make a score usable. It should be deterministic, so the same inputs always produce the same number and you can recompute it yourself rather than trusting ours. And it should decay, so an agent that behaved well a year ago and has been silent since does not read the same as one that behaved well last week.
Ask any scoring provider for their method. If they will not publish it, the score is a brand, not a measurement.
Check four: is the deal itself suspicious
Everything above examines one party. Some of the most common manipulation is only visible when you look at both.
The pattern is simple: an operator registers two agents, has them pay each other repeatedly, and manufactures a settlement history for both. Each agent looks fine in isolation. The relationship between them is the tell, and a one-sided scan cannot see it by construction.
So the last check takes both sides of the proposed deal and asks whether they are independent. Shared funding sources, shared deployment patterns, and payment graphs that only ever loop back on themselves are what give it away.
What a verdict should look like
The output of all this should be a decision, not a dashboard. Your agent cannot act on a risk score of 0.72. It can act on ALLOW, WARN or DENY.
WARN is the important one and it is usually missing. It means the payment is permitted but crosses a line where a human should look. An agent that treats WARN as ALLOW has thrown away the only signal that was asking for a person.
Whatever verdict you get, it should arrive with reasons in plain language. You will eventually have to explain a blocked payment to whoever was expecting it to go through, and "the model said no" is not an explanation.
The check that runs after the verdict
Verifying the counterparty answers whether you should pay. It does not answer whether you are allowed to. Those are separate, and conflating them is how agents overspend while passing every check.
A counterparty can be entirely legitimate and the payment can still be outside the budget its owner set. That limit needs to live somewhere the agent cannot argue with: a server-side pre-check is convenient, but an on-chain vault that reverts an over-limit transfer is what still holds when the server is wrong.
Verify the other party, then check your own limits. Skipping the second one means the only thing standing between an agent and your balance is its own judgement.
Doing it in one call
A-Identity runs these four checks as pay-per-call endpoints. `risk_check` takes the counterparty and the intended amount and returns the verdict with its reasons. `counterparty_check` takes both sides and catches the self-dealing case. `trust_preview` is free and rate limited, so you can see the shape of an answer before spending anything.
Payment is per call in USDC over x402, which means no account and no API key: an unpaid request returns HTTP 402 describing exactly what is owed, and the resource is served on a paid retry.
The scoring method is published in full and every settlement we have taken is listed with its transaction hash. You should not have to trust a trust provider, and we would rather be checked than believed.