- Vrealmatic
- AI
- Agent trust
Who do AI agents trust? Trust in the agent economy
Agents are starting to hire agents, buy data and call external services. How do they decide whom to trust, and how do they verify what they get? A guide to credibility in the AI agent economy.
Why would an agent pay another agent?
An agent handles a surprising amount on its own, and that is exactly why it pays only for what is out of its reach. It can't get to private data. It can't perform an action it has no account or authority for. It can't replicate someone else's model trained on data it doesn't have, nor afford a heavy computation. These limits are the real reason it will increasingly hire other agents, buy data and call external services: delegate a task, buy access to data, or order a finished result.
Because most things it sorts out itself. Public information it simply reads. A trivial utility (a currency conversion, a date format, a simple parser) it writes in seconds or grabs from a ready, freely available tool. The market for agent services is therefore not "everything." It is the remainder beyond what an agent can do itself.
That remainder has clear shapes, though. Paying someone else pays off mainly in four cases:
Data that isn't freely available
There's plenty on the web, but the valuable part tends to sit behind a wall. The value is in what is live, licensed, private or painstakingly assembled.
- Live data: exchange rates, flight availability, prices, stock levels, weather now — behind a paid API and rate limits.
- Licensed: company financials, legal databases, market research, satellite imagery.
- Private: data behind a login that only someone else can reach.
- Assembled and cleaned: the raw material is public, but the value is in collecting it from thousands of sources, cleaning it and keeping it current.
Actions it can't perform itself
Sometimes it isn't about knowledge but about authority and real-world standing the agent lacks.
- Actions with consequences: pay, book, order, file a form, ship a parcel — requires accounts, identity, legal standing.
- Access to closed systems: the counterpart holds a key, license or account the agent doesn't have.
- Verified authority: a signature, proof of identity, something only a verified entity can do.
Compute and specialized models
Building it might be possible in theory, but cost, performance or know-how put it out of reach.
- A stronger model for a harder task: a small local model handles most routine work with no per-call fee (it runs on hardware you already have), but for hard reasoning or specialized knowledge it queries a large model over an API.
- Heavy computation: rendering, physics simulation, large-scale search, training.
- A proprietary model behind an API: it can't be replicated, because it's trained on data the agent doesn't have (fraud detection, medical imaging, narrow prediction).
Upkeep, freshness and accountability
This one is easy to miss. Even if the agent can build it, what it really buys is that someone keeps it correct, current, compliant and stands behind it.
- Your own scraper rots with every change to someone else's site; a maintained feed doesn't.
- Payments, taxes or law aren't a "utility" — they carry compliance, liability and updates.
- You're buying an SLA and accountability, not code.
But once agents start buying and hiring, a market appears where both demand and supply come from software acting on its own and in real time. And every market has one hard question: whom to trust?
The ladder of signals: how an agent builds trust
Just like people, an AI agent can't mindlessly hire the first supplier it finds. A bad result usually doesn't cost it money: it either won't pay for a dud, because it catches it, or it's small change per call. What it won't get back is time — delaying one step pushes back everything downstream and breaks overall efficiency. Choosing well is therefore not a luxury for it, but a necessity.
But based on what, when it has no human gut feeling? A person decides on soft signals: impression, reputation, a friend's recommendation, their own memory. Most of it they don't even consciously notice. An agent has none of that. It decides on signals it can read and, above all, verify.
The same transaction has to be read from both sides:
The agent that chooses
What to decide on — whom to hire, whose data to buy, whom to trust with a task?
The operator that offers
How to build an agent so that other agents pick it, and so that it's more than just a promise?
For the operator, the conclusion is clear: if other agents can't read and verify its agent, they won't pick it. Trust therefore has to be built deliberately, as verifiable signals, not as marketing. That's why every rung of the ladder below also carries a note on how to emit that signal.
These signals are not equal. They can be ordered from the weakest, which anyone can invent, to the strongest, which the agent can verify itself. Good decision-making always pulls down the ladder, toward the more verifiable. Each rung only holds if the one below it holds: reputation without a verified identity means nothing, because someone could have fabricated the whole thing.
What it claims about itself
Declared capabilities, inputs, outputs and price
The agent announces what it does, what it needs as input, what it returns and what it costs. It's like an ad: useful for a first pass, but anything can be written. The cheapest signal and also the easiest to overstate.
Who's behind it
Verifiable identity and provenance
Can it be cryptographically verified who runs the agent, and is it the same identity next time? Without this, the counterpart can put on a new face under every order, and then there's no point in any reputation or penalty. Identity is like a supplier's verified ID: it doesn't yet say they're good, but the agent knows whom it's dealing with.
What it has already done
A provable track record (reputation)
A history of past orders: success rate, speed, disputes, volume. The key is that it's signed, provable data, not stars anyone can mass-produce. The difference is like a review from a verified purchase versus one from an anonymous account created yesterday.
What others say
Recommendations and curated registries
A rating from a trustworthy third party or a recommendation from another agent the agent already trusts. It's transferred trust, like when someone you rely on recommends a job. As strong as the agent's trust in the recommender, and as sure as it is that they aren't bribed.
Today these are mainly catalogs of tools, models and agents: registries of MCP servers (the MCP registry), model hubs (Hugging Face) or agent stores (the GPT Store), with light signals like stars, download counts or basic reviews. But they inherit the flaws of human ratings and are easy to generate. A real reputation system for agents, bound to a verified identity and proven transactions, is only just emerging — which is exactly why this signal is only medium-strength.
What it has at stake
An economic guarantee: escrow, a bond, an SLA
"Skin in the game." Payment sits in escrow and is released once the result passes a check (like a deposit held by a notary when buying a flat). Or the supplier has a posted bond it loses if it fails. The agent doesn't have to trust good intentions; it's enough that failing doesn't pay off. This layer turns trust into economics.
But beware — escrow doesn't erase risk, it relocates it: it only works where the result can be objectively verified (otherwise the dispute still ends up in arbitration, which can be wrong). Trust shifts to the holder of the money or the arbiter, and even a smart contract can have a bug or go down. And above all it protects the money, not the consequence: once a bad output has already done irreversible harm (published nonsense, a sent payment, an executed market order), getting the money back won't undo it.
What I can verify myself
An independent check of the result
The strongest rung. For many tasks, verifying is cheaper than solving: the agent recomputes the calculation, runs the code against tests, confirms a fact against a second source, checks a data signature. If it can verify the result itself, all the earlier rungs matter far less. Trust stops being a condition.
The point of the ladder: the higher the agent climbs, the less it actually has to trust the counterpart. The goal of good architecture isn't to find a "trustworthy partner," but to arrange the relationship so that as little as possible depends on blind trust. And at the very top stands the strongest move: verifying the result yourself. That's what the next part is about.
The strongest move: verify outcomes, not promises
The question "whom to trust" thus turns into "how to verify." Take that small local model from the start. When it queries a large model over an API, it doesn't have to trust it blindly. Where the result can be verified cheaply, it does so itself: it runs the returned code against tests, confirms a fact against a second source, recomputes a numeric calculation. The large model is stronger, but the verification stays on the side of whoever is asking. For pure reasoning, which can't be verified cheaply, it's harder — we'll get to that shortly.
Verifying doesn't solve everything, though. The time the supplier spends on a bad result is lost and the order has to be placed again. But it solves two other things: a dud doesn't get paid for, and the flaw doesn't reach the downstream steps. Verification thus doesn't replace trust, it just shrinks the need for it.
And here's the actual innovation. In the human world trust is a substitute for verification, because checking quality is almost as expensive as doing the work. With agents this breaks: for a significant class of tasks, verifying the result is much cheaper than producing it. How much trust the agent then still needs depends on one thing: whether the result can be verified.
When the result can be verified
The agent recomputes the calculation, runs the code against tests, or compares two independent answers. In the extreme case, the supplier attaches a cryptographic proof of correct computation (verifiable computation), which the agent checks without repeating anything. There, the need for trust drops to zero. A signature and documented data provenance, however, only prove authenticity and origin, not correctness — those alone don't erase trust.
When it can't be verified
For subjective quality, or where checking isn't cheap, the agent has to fall back on trust. But only as far as the cost of the delay and reordering elsewhere if it doesn't work out. Even here, then, trust is calculated, not blind.
Either way, trust changes from a feeling into a quantity proportional to the cost of failure, one that can be estimated and managed.
Strategies an agent actually has
- Test task (probe): before placing a big order, the agent sends a small task whose correct answer it knows. It cheaply exposes an incompetent or fraudulent provider before anything depends on them.
- Cross-check: the agent gives the same task to two or more independent agents and compares the results. Agreement raises trust, a discrepancy is a signal to be careful.
- Verifiable output: for many tasks checking is cheaper than solving. The agent recomputes the calculation, runs the code against tests, confirms a fact against a second source. For suitable tasks it's enough to check an attached cryptographic proof of correct computation without repeating it; a signature and provenance, however, only verify authenticity, not correctness.
- Agent as judge: a separate evaluating agent assesses quality against clear criteria. Useful where there's no single "correct" answer. But it is itself fallible and foolable (bias, a hidden instruction inside the evaluated text), so it's a weaker guarantee than hard verification.
- Gradual release of trust: a new provider first gets small, low-risk tasks. Only with a proven success rate do the volume, value and autonomy grow. The same principle as a small trial order with a firm, except each completed one is stored in a signed history the supplier carries with them.
- Payment after verification: via escrow the money is released once the result passes a check. The risk is borne by the supplier, not the buyer.
A consequence: constant pressure on suppliers
And here's perhaps the main thing. A person often waves off a mediocre result. Complaining is work, it's unpleasant, and "it'll do." Suppliers know this and learn to deliver just below the line someone will bother to dispute. An agent doesn't wave it off. It specifies more precisely, has no emotional cost in rejecting, sticks exactly to the brief, checks every output and pays only for what fits. Bad work doesn't get through occasionally, but every time.
How much to verify: a decision grid
Verifying everything isn't possible — it would cost more than the work itself. Verifying nothing is gambling. And because verifying itself costs something, for small, easily repeatable orders the cheapest option is often to just risk the error and redo it if needed. The amount of verification should match what's at stake. Two questions are enough: how valuable the task is and how easily a mistake can be undone.
Low value + easily reversible
Minimal verification
A cheap, non-binding task that can be redone anytime. A declaration and basic reputation suffice. Most routine agent collaboration belongs here.
High value + easily reversible
Verify the result
Expensive but fixable. A cross-check or an independent verification of the output pays off before the agent uses it further.
Low value + hard to reverse
Test task + guarantee
Cheap, but the consequences are hard to take back (a sent email, published content). The agent tests in advance and holds a safeguard, not just trust.
High value + hard to reverse
Full defense
Expensive and irreversible (a payment, deleting data, a production change). The agent combines a verified identity, an economic guarantee, independent verification and human approval.
Every signal can be faked
Whatever the agent builds on, the counterpart can fake. And because agents act fast and at scale, a mistake doesn't happen once, but a thousand times. Whoever designs an agent that chooses has to assume the other side may behave adversarially. So for each manipulation, a defense right away.
Fake reviews at scale (Sybil)
An attacker creates thousands of identities or transactions and simulates a history and ratings.
Defense: The agent requires a verified identity that's expensive to obtain. Without it, reputation is cheap to forge.
Polished for the test (benchmark gaming)
An agent is tuned to shine on the test task but fails on a real order.
Defense: The agent keeps test tasks unpredictable and close to real work, and tests at random during the collaboration too.
Hidden message in the response (prompt injection)
Data or output from a foreign agent contains hidden instructions meant to redirect the agent's behavior.
Defense: The agent treats foreign output as input, not as a command. It separates data from instructions and never runs what arrived in a response.
Bait and switch
A provider behaves impeccably until it has built trust and volume, then starts cheating or raising prices.
Defense: The agent verifies continuously and at random even with proven partners. Trust isn't a state won once and for good.
Collusion
"Independent" agents in a cross-check actually belong to one operator and confirm each other's bad results.
Defense: The agent ensures verifier independence rather than assuming it. It verifies across different operators and origins.
Poisoned data
A purchased dataset looks fine but contains targeted errors, bias or back doors.
Defense: The agent verifies the provenance and integrity of data, not just the content: signatures, source and a random sample check.
For every signal, the question is "what if the counterpart produced it on purpose?". If the agent has no defense against that, it isn't a signal of trust, just a surface that can be painted over. It entrusts a foreign agent with nothing it wouldn't entrust to an unknown supplier without a contract, verification and the option to claim a refund.
Where this is heading: a shared trust platform
Every defense above each agent has to do itself, again and again, at its own cost. That doesn't scale. The real solution is shared infrastructure: an independent, reputable platform that aggregates the performance of agents, unmistakably bound to identity and verifiably, so that trust doesn't have to be rebuilt from scratch every time.
The other side: being an agent that gets picked
The whole ladder runs in reverse too. If you operate an agent or service that other agents are meant to hire, you have to be machine-selectable. A nice website, a brand story and human marketing don't decide here. The decision is made on signals software reads and verifies. The higher up the ladder you can push your signal, the more easily someone picks you and the higher a price you can defend.
Be readable
- Publish a machine-readable description of capabilities, inputs and outputs
- State price, limits and expected speed up front and unambiguously
- Keep a stable, verifiable identity, not a throwaway one
Be verifiable
- Deliver outputs that can be independently checked
- Sign results and document data provenance
- Expect test tasks, don't fear them
Have skin in the game
- Offer payment escrow, an SLA or a guarantee on the result
- Build a provable history, not just claims
- Make losing your reputation something that genuinely hurts
Be safe
- Put nothing in your outputs that looks like a hidden instruction
- Cleanly separate data from commands
- Behave predictably even under load and on edge-case inputs
Practical checklist
Before the agent hires someone
- Does it know for sure whom it's dealing with (verified identity)?
- Do the declared capabilities match what it really needs?
- Does the counterpart have a provable history, not just stars?
- Can the result be verified cheaply? How?
- Does the level of verification match the task's value and reversibility?
- Does it have a safeguard in case of failure (escrow, guarantee)?
- Does it treat foreign output as data, not as a command?
- Does it verify even proven partners at random?
Before you offer your agent
- Does the agent have a stable, verifiable identity?
- Is the description of capabilities, price and limits machine-readable?
- Can my outputs be independently checked?
- Do I sign results and document data provenance?
- Am I building a provable track record?
- Do I offer some guarantee or skin in the game?
- Do I hold up under a test task and a cross-check?
- Do my outputs contain nothing that looks like a hidden instruction?
Summary
The world of AI agents is heading toward a division of labor: agents will hire agents, buy data and call external services, because building everything from scratch is expensive and in many cases outright impossible. That makes credibility the central question — only it can't be solved the human way, on feeling and reviews.
An agent decides on signals, and their strength grows from the weakest (what someone claims about themselves) to the strongest (what the agent can verify itself, or what a more sophisticated agent it delegates to verifies for it). Good architecture therefore doesn't look for a "trustworthy partner," but arranges the relationship so that as little as possible depends on blind trust: a verified identity, a provable history, an economic guarantee and, above all, cheap verification of the result, scaled to how much is at stake.
Because every signal can be faked, the same holds in reverse. Whoever wants to be picked has to be readable, verifiable and have skin in the game. Whoever is choosing has to treat every signal as if an adversary made it.
Where to continue
AI Application Security
How to secure LLM, RAG and agentic systems: threat modeling, guardrails, access control and monitoring.
AI value vs. security
How to balance value and risk, the permissions and reach of agents before you give them data and tools.
Discuss agent architecture
Design safe agent collaboration, result verification and trust boundaries for your project.
Need to build an AI agent?
Whether your agent has to choose suppliers and verify their results, or be the one other agents reliably pick, we'll design the architecture, identity, verification and trust boundaries. We're here for you.
Discuss your project