Agent Trust Infrastructure: Identity, Provenance, and Reputation for the Agent Web

AI agents are beginning to occupy a strange new place on the internet. They are not quite users, not quite apps, and not quite employees, but they can search, negotiate, buy, sell, post, moderate, summarize, schedule, and call APIs. That makes them useful. It also makes them hard to reason about with the tools the web already has.

The web got good at proving domains, encrypting traffic, charging cards, indexing pages, and letting humans sign in. It did not get good at answering the question agents now put in front of every serious platform:

Should this agent be trusted right now, for this action?

A username does not answer it. An API key does not answer it. A wallet does not answer it. Even a verified business account only answers part of it. Those things tell you that someone has a credential. They do not tell you whether this agent still controls its key, whether it is allowed to act for a business, whether its past behavior was real, or whether this particular request is risky.

PurposeBot exists because those answers need evidence, and because they need to stay separate.

What Agent Trust Means

Agent trust is not one big number stamped on a profile. A single score is tempting because it feels simple, but it hides the very things a relying party needs to know. Trust is a set of smaller answers, each tied to evidence:

• Identity: Which agent is this, and does it still control the key it claims?
• Backing: Is a human or business standing behind this agent?
• Authority: Is this agent allowed to act for that business, in this scope, right now?
• Provenance: Did the evidence come from a real transaction, signed provider event, public credential, or audit trail?
• Reputation: Has this agent behaved well over time, across independent interactions?
• Freshness: Is the evidence current enough to matter?

Those answers should stay separate because real trust is contextual. A business can be legitimate while one of its agents is brand new. A buyer reputation should not become seller reputation. A clean commerce history should not automatically make an agent safe to use a social API at high volume. Blend those signals too aggressively and trust stops being a record. It becomes a shortcut.

Identity First

PurposeBot treats agent identity as something the agent proves, not something it types into a form. The agent publishes key material, signs a proof, and receives a stable agent_id tied to that identity.

Humans and businesses can back or authorize the agent, but they do not become the agent. That distinction matters because one person or company may operate many agents, each with different scopes, histories, and revocation needs.

For businesses, the important path is business-agent authority: a verified organization authorizes a specific agent for a bounded role or purpose. That authority should be checkable by outsiders before they rely on the agent. It should also be revocable, because a business agent is not a permanent badge. It is a current permission to act.

Provenance Makes Reputation Useful

Reputation is only useful when the input is hard to fake.

PurposeBot separates casual opinion from reputation-moving evidence. Commerce trust is built from settlement-backed workflows, verified feedback tokens, role-specific outcomes, and dispute history. API trust is built from provider-signed conduct events after real API interactions.

That means a new account cannot simply praise itself into credibility. The trust signal has to come from an interaction with provenance: a settled order, a signed event, a public claim, a current authority proof, or another bounded source that can be checked later.

Trust Decays

Agent trust also has to age. A clean record from last year is not worthless, but it is not the same as a clean record this morning. Old evidence should not dominate current decisions forever, and a short burst of clean behavior should not erase a thin or risky history.

PurposeBot uses freshness, breadth, severity, confidence, and anti-gaming safeguards when turning evidence into reputation. The public docs intentionally avoid exact scoring parameters because a trust system should explain its principles without publishing a recipe for manipulation.

API Trust for Non-Commerce Sites

Commerce is only one part of the agent web. Many sites need agents to use ordinary APIs: discussion platforms, data services, research tools, productivity apps, developer platforms, and private business systems.

For those sites, the trust question is not "will this agent pay?" It is "will this agent behave here?" PurposeBot provides an API-conduct trust lane for that kind of relationship.

The pattern is:

1. An API provider registers with PurposeBot and proves domain control.
2. Before accepting an automated API request, the provider asks PurposeBot for an access recommendation.
3. PurposeBot returns a bounded recommendation with risk context and machine-readable reasons.
4. If more proof is needed, the site can return a PurposeBot challenge so the agent can register or prove key control.
5. After the request, the provider sends a signed, idempotent conduct event describing what happened.
6. PurposeBot updates provider-specific API-conduct reputation for future requests.

The requesting site remains in control. PurposeBot is not a proxy and does not need to sit in the site's data path. It returns trust information; the site decides whether to allow access, lower rate limits, queue moderation, or reject the request.

What a Site Receives

When an API provider calls PurposeBot for an access recommendation, it receives a short-lived response with enough context to enforce local policy: whether the request looks acceptable, whether more proof is required, how risky the agent appears in that context, and why PurposeBot reached that recommendation.

That lets a site make policy without inventing its own agent reputation system from scratch. A discussion site might let trusted agents post normally, slow down new agents, send risky agents to review, and block agents with severe abuse history.

Why Idempotency Matters

Agents retry. Networks fail. Providers resend events. A trust system has to distinguish a retry from a second event.

PurposeBot requires provider-local idempotency keys on signed conduct events. The same event can be retried safely, but the same key cannot be reused with a different payload. That prevents accidental double-counting and makes the evidence trail auditable.

The Goal

The goal is not to make one universal score that decides everything. The goal is to make agent trust legible:

• who is acting
• who backs them
• what they are authorized to do
• what evidence exists
• how current that evidence is
• what risk the current request carries

If the agent web becomes important, businesses will need this kind of infrastructure in the same way websites needed DNS, TLS, search, payment rails, and identity providers. The internet does not need another place for agents to claim they are trustworthy. It needs a way for agents, businesses, and API providers to prove enough of the right things at the moment trust is actually on the line.