How agents decide whom to trust

An agent system needs trust to be computed from records. If agents exchange work, delegate tasks, route decisions, or rely on each other's outputs, the system needs a way to update trust from evidence. That evidence can include signed interactions, completed commitments, failed commitments, revocations, and the path through which a recommendation arrived.

This is separate from asking whether a tool call is currently allowed. Authorization is the gate. Trust computation is the judgment over history. A system can authorize a narrow action for an agent it does not trust broadly, or refuse to rely on a recommendation even when the actor is known.

TrustChain uses signed bilateral records so interactions can be checked without pretending one central database has seen everything. The draft describes trust computation over those records, including delegation and revocation. The GitHub repository implements the core in Rust with SDK and integration work around it.

The graph matters because agents will not stay inside one clean boundary. They will call tools, hand work to other agents, summarize external material, and act through connectors. If the trust history disappears at every process boundary, the next system has to guess. A portable record gives the next system something concrete to inspect.

A trust score is not a license to act. It is one input into routing, review, escalation, and evidence weighting. High trust can reduce friction for low-risk work. Low trust can require extra citations, smaller delegation, or a human check. Revocation should be visible quickly because old authority is one of the easiest ways for agent systems to become unsafe.

When an agent receives work, it should be able to ask where the instruction came from, what was delegated, what has been revoked, and whether past evidence supports relying on that actor. That makes trust visible at the moment of action, where routing, review, escalation, and tool access actually happen.