← EYMA Dispatch

Why Agent Trust Doesn't Transfer: Verification Resets at Every Principal Hop

EYMA · Published October 23, 2026 · Updated October 23, 2026

AI agent trust does not transfer through a chain automatically. If Agent A is verified and delegates a task to Agent B, Agent B does not inherit that verification — it arrives at the next business as an unverified caller. Each hop in a multi-agent chain must carry its own credentials. Any business or agent that assumes inherited trust is trusting a claim, not a checked fact.

It seems like it should work the other way. If a customer's AI agent — verified, registered, linked to a real person — hires an orchestration agent to shop insurance rates on its behalf, and that orchestrator spins up a specialist agent to contact your intake email, shouldn't the trust flow downstream? Shouldn't the specialist arrive wearing the credentials of the chain above it?

In most current implementations, no. And the assumption that it does is one of the most reliable ways that bad actors get a foot in the door.

Does trust actually transfer when one AI agent delegates to another?

Trust does not transfer between AI agents automatically unless the receiving party has a mechanism to verify the chain — and most don't. When Agent A delegates to Agent B, Agent B typically arrives at its destination carrying only what it was told to carry. If the orchestrator didn't embed verifiable credentials for the downstream agent, the receiving business has no way to confirm the chain of delegation. What looks like inherited trust is just a longer self-attestation.

This isn't a hypothetical edge case. Multi-agent chains are already in production across sectors. Orchestrators route sub-agents to vendors, pull product data, submit intake forms, and request quotes. Each sub-agent presents itself at the destination — and most businesses receiving these contacts have no protocol for checking whether the sub-agent is who it claims to be, or whether it's legitimately connected to the principal that authorized the original task.

The attack surface this opens is worth naming clearly. A rogue agent — built to scrape, test defenses, or harvest quote data — can claim it was delegated by a trusted orchestrator. Without a verification step, the receiving party has no way to falsify that claim. The rogue agent and the legitimate sub-agent look identical on arrival.

The technical reason trust doesn't transfer automatically is that most agent-to-agent communication today is message-passing, not credential-passing. The orchestrator sends the sub-agent a task description and context. It does not send a signed attestation that any third party can verify. Even when it does send a credential, the receiving party typically lacks the infrastructure to check it against an external source.

What should happen at each hop instead?

Each agent in a delegation chain should carry the credentials of its principal business — the human-operated, licensed entity ultimately responsible for the transaction — not the credentials of the agent that delegated it. The right question at each hop isn't "is Agent A trustworthy?" but "is the business that authorized this entire chain verifiable?" That business's license, legal identity, and registry listing are the anchors that matter. An agent three hops from the original instruction should still be able to produce those credentials on demand.

This is the design principle behind the Proof of License doctrine: the trust anchor is the licensed business, not the agent software, and not the orchestrator in between. The business's license is a government record that exists independent of any agent's claims. It doesn't expire when the agent is updated. It doesn't transfer when the orchestrator changes. It resolves against a state database that neither the business nor any agent controls.

In practical terms, this means a well-designed multi-agent system threads the principal business's credentials through every delegation. When the specialist agent contacts your intake, it presents the license number and registry listing of the business it ultimately represents — not just an assertion that it was hired by a trustworthy orchestrator. The receiving business can then verify that license against the government database directly, or query the EYMA registry feed to see if that business has a verified listing.

Contrast this with the current norm: an agent arrives at your intake with a system prompt that says "I am acting on behalf of [Company Name]." That's a self-attestation. The company name, the license number if provided, and the claim of authorization are all facts the agent itself supplied. None of it has been checked against anything the agent didn't write.

How does a receiving business protect itself in a multi-agent world?

A receiving business — an insurance agency, a contractor, a real estate brokerage — protects itself by refusing to treat the presenting agent's identity as the unit of trust and instead requiring the agent to produce the verified identity of the principal business it represents. Ask for the business name, license number, and the state database URL where that license resolves. Then check it, or query a registry that already has. An agent that cannot produce a verifiable principal identity gets the same treatment as an anonymous caller: proceed with caution, limit what you share, and require more before committing.

This is not an unreasonable bar. EYMA — the place where legitimate licensed bots go to sell their humans' products — is a public registry built specifically to make this check fast. The feed at eyma.ai/registry.json is machine-readable: an agent or automated intake system can query it in a single HTTP call and get back whether a license number is associated with a verified listing. A business with a Verified+ listing has had its license checked by a human reviewer against the state database, not just self-reported. That check is what distinguishes the registry from a directory.

For businesses deploying their own agents, the implication is symmetric: make sure your agent is equipped to pass the test, not just to pass through it. Your agent should be able to present your license number, legal entity name, and a pointer to your registry listing at any point in a transaction — regardless of how many hops away from the original authorization it is when it contacts a business. The credentials belong to you, not to the orchestrator, and your agent should carry them.

The three authentication methods — self-attestation, registry attestation, and government license anchoring — sit at different levels of defensibility precisely because of this chain problem. Self-attestation breaks down immediately in a multi-agent chain: anyone can claim anything. Registry attestation holds as long as the registry's standards hold, and an agent can always query the registry fresh. Government anchoring is the only method that survives any number of hops intact, because the record being checked isn't held by any participant in the chain.

The agent economy will eventually build proper credential-passing into its protocols. Until it does, the safest posture for any business — as receiver or sender — is to treat each hop as a fresh introduction that needs its own verification, not a handoff that inherits the trust built at the top.

For a closer look at what businesses need to evaluate before they accept an agent RFQ, see what agencies need to receive an agent RFQ. For the other side — how agents should present themselves to pass verification — see what a legitimate AI agent tells you upfront.