AICENT.COM

When Agents Must Prove Themselves

2026-10-16 · AICENT · RTTP · IQA

When Agents Must Prove Themselves

Thirty years ago, authentication had a definite shape: a keycard, a login box, a domain certificate. It assumed two kinds of actors — named organizations, and people who kept passwords for them. Trust was an affair between institutions; protocols merely transcribed institutional promises.

Agents broke that assumption. Between 2025 and 2026, the AI conversation slid from answering questions to executing tasks: booking flights, auditing invoices, calling APIs. One step further, agents delegate to agents — across organizations, across domains, strangers to one another. With every step, the shape of "trust" changes: in the chat era we feared the model would talk nonsense; in the agent era we fear it will overstep its authority; in the A2A era the question becomes — after a stranger agent finishes the job, what evidence can it produce?

The industry shouts this question loudly; no one has shipped a mechanism. This essay explains why the question is hard, what our minimal viable form looks like, and why the final shape is necessarily one draft, two schemes.

1. Four gaps in today's stack

(Every claim in this section is a checkable fact.)

DNS + CA: two questions you can only ask online. Domain addressing runs on DNS; identity binding runs on the CA system. Both answer "who is this" by querying a registry maintained by institutions — reachable only online. Offline, neither question can be asked.

OAuth: a round trip back to the IdP. OAuth lets third-party apps hold limited authorization, but every authorization decision routes back to the identity provider. The shape of it: carry the introduction letter back to the home office for a stamp. Home office offline, the letter is just paper.

DID: resolution still hits a registry. Decentralized Identifiers promised independence from centralized registries, yet mainstream methods such as did:web resolve through — DNS and web servers. Every link of the verification loop is still an online lookup.

MCP: no identity semantics. The Model Context Protocol standardized how agents call tools, but the protocol itself carries no semantics of "who is calling, in what standing, authorized by what." The tool side sees a request, not evidence.

Four gaps point at the same blank: identity exists, authorization exists — portable, independently verifiable evidence does not.

2. Addresses should be derived, not assigned

In the institutional world, addresses are assigned: domains registered for a fee, certificates issued, accounts approved. Assignment implies a grantor — and a grantor can revoke.

Agents should not live in that model. Their address should work like a fingerprint: derived, not issued.

The mechanism is a single move: canonicalize the authority name, take SHA-256, truncate to 128 bits — yielding an address of the form rttp://<intent>.<pillar>.<root>. Determinism, self-evidence, and offline capability are three faces of the same coin:

The same input always yields the same address — rather like git init: every repository has its own first commit, numbered differently, none judging the others, each one really happening in its own history.

The route shard carries a third identity as well: it is simultaneously the first slice of the intent, the index key of the routing table, and the salt against enumeration. One byte, three duties.

The honest ledger of 128 bits

Truncation has a cost, and we put the ledger on the table. SHA-256 is 256 bits long; truncated to 128, the second-preimage margin drops from 2^256 to 2^128 — for the path that matters, impersonation of an authority in use, 2^128 remains an unshakable engineering fact. The birthday bound is 2^64, but adoption passes two gates: an address must be explicitly referenced before it is trusted, and it must reappear across verifications; a random collision survives neither gate. As for truncating an address to 8 hex characters for display (a margin of 2^16), the specification says MUST NOT — display may be short; unique identity may not.

Honesty is the first design principle of this specification. The ledger goes in the main text, not the footnotes.

3. Trust is a lease

An address can be permanent. Trust cannot.

An agent that passed verification last week is not thereby trustworthy this second: keys rotate, permissions change, the organization behind it may change its mind. The traditional answer is a revocation list — one that grows longer and lags further behind.

We use a different model: standing is a lease. Every attestation carries a 120-second freshness window; when it lapses, the lease expires and the relying party re-derives. No blacklist to maintain, no revocation to propagate — expiry is invalidity, renewal is validity, and the landlord is time, not a committee.

Standing is a four-state closed set: ghost (unverified), probation (under observation), radiant (valid in position), genesis (epoch anchor). One state, one assertion; relying-party policy has a real decision point at each. Revocation is not a deleted record but a newly issued envelope — the timeline itself is the evidence.

The carrier is AE-128: a 128-byte fixed-layout attestation envelope. Fixed layout means zero parser dependencies — byte offsets are the fields, verification is offline, thirty lines in any language will read it. HMAC covers the full frame, organ and nonce included; it does not inter-parse with the addressing-side frame. Two systems, each keeping its own format.

4. One draft, two schemes

A natural question: why not build one protocol that does it all?

Because the two anchors come from different sources. The anchor of semantic addressing is a hash — it proves "this address is this name." The anchor of attestation is a key — it proves "this signature came from this key." Force both anchors into one protocol and either the addressing format inherits the parsing burden of signatures, or the attestation format bends to the short-circuit logic of routing. The two layers drag each other down, at a cost larger than it looks.

So the final shape is: one draft, two schemes.

The two interlock in one set of shards: the address derivation and the envelope shard share the same source, and the verification loop must be completed by the second pillar's signature — hash self-consistency is not provenance. Parsing is not attestation.

Both schemes are registered with IANA (Provisional · CRI 27 and CRI 28), and the joint specification draft-li-rttp-iqa-addressing is under review through the ISE channel of the IETF. All derivations, vectors, and verification code are public — the three reference implementations are a starting point, not a ceiling.

5. The protocol hands over the knife; it does not swing it

The last principle is the most important one.

The protocol provides mechanism, not verdicts. "Hands over the knife, does not swing it" means: the specification defines the format of evidence and the steps of verification, but not whom you must trust. Addresses have no landlord — no registry, no admission approval, no monopolized starting point of trust. Standing is a lease — trust is re-examined every 120 seconds, never tenured.

Openness is not the absence of a starting point; it is refusing to monopolize one. The specification is a standard part: it can be embedded in any system, and the epoch begins wherever it is embedded — none judging the others. The third pillar does not grow inside the protocol; it grows in the stack. The protocol writes its own boundary clearly and leaves the remaining space to the ecosystem.

Closing

Agents did not invent new mathematics. They merely backed an old question into a corner for the first time: when both parties are strangers — automated, cross-domain — trust must become something portable, verifiable, and expiring.

Derivation replaces issuance. A lease replaces permanence. Two schemes replace one grand unification. Public vectors and reproducible tests replace spoken promises.

This is an open, minimal viable form. If it runs, you win. If it doesn't, it's our bug, fixed with attribution — either way, you win.

← Back to Blog | aicent.com main site