A Passport for Software: The Agent Attestation Token

Your phone rings. The screen says "Verified." You pick up, and a very pleasant voice starts negotiating a refund on behalf of someone you have never heard of.

Verified what? Verified who? Verified by whom, for what?

Here is the uncomfortable answer: the checkmark means the call really did come from the carrier it claims to come from. It does not mean the caller is a person. It does not mean the caller is authorized to say the things it is saying. And it certainly does not mean the voice on the line is allowed to spend anyone's money.

That gap is the reason the whitepaper behind Dial's protocol spends a whole section on something it calls the Agent Attestation Token. Let us walk through why it exists and what a good one should carry.

What STIR/SHAKEN actually proves

STIR/SHAKEN is the framework US carriers use to fight spoofed caller ID. It assigns each call an attestation grade:

A (full): the carrier knows who the customer is and that they are entitled to use the number.

B (partial): the carrier knows the customer, but not whether they own that number.

C (gateway): the call came in from elsewhere and the origin is unverified.

This is genuinely useful. It makes it harder to fake a bank's number. But look at what is being attested: the relationship between a carrier, a customer, and a number. That is a statement about the plumbing.

It says nothing about the thing on the other end of the plumbing. A grade A call from a human, a grade A call from a script, and a grade A call from a large language model wearing a friendly voice all look identical. There is no field for "this is an agent." There is no field for "this agent is acting for Acme Dental." There is no field for "this agent may book appointments but may not take payment."

> The gap in one line: carrier attestation answers "did this call come from where it says?" Nobody is answering "what is this caller, and what may it do?"

Why this matters more for agents than for people

When a human calls you, you have a lifetime of social machinery for judging them. You hear hesitation. You ask follow-ups. A person who wants to defraud you has to put a human face on it, and humans are expensive.

Agents break that economics in both directions. A legitimate agent can make ten thousand useful calls. A malicious one can make ten thousand fraudulent ones. From the receiving end, the two are indistinguishable unless something in the message itself says which is which.

Imagine you run the front desk at a clinic, and your own scheduling agent, Maple, receives a text: "Hi, this is Fern, the assistant for Mr. Okafor. He needs to move his appointment." Is Fern real? Is Fern a registered agent of anyone? Is Fern allowed to reschedule on Mr. Okafor's behalf? Today, Maple has to guess from tone. Guessing from tone is how phishing works.

What a token should carry

The whitepaper describes the AAT as a signed, verifiable claim that the sender is the registered agent it says it is. Conceptually, think of a passport for software. A good passport has three kinds of information, and so should a good token.

1. Identity. Who is this agent, exactly? Not a display name, which anyone can type, but a stable identifier that resolves to a registry record. In the whitepaper's design that is the Agent Communication Number, with a public key behind it.

2. Authorization scope. What has this agent been permitted to do, and for whom? "Send reminders for Acme Dental" is a very different claim from "act for anyone." Scope is what turns identity from a name tag into something a receiver can make decisions with.

3. Issuer. Who vouches for all of this? A passport is only as good as the government that issued it. A token is only as good as the registry and the signing keys behind it.

Illustrative pseudocode, not a real wire format:

token = {
  agent:      "acn://registry/acme-dental/reminders",
  entity:     "agent",
  acting_for: "Acme Dental",
  scope:      ["appointment_reminders", "reschedule"],
  issuer:     "registry.example",
  issued_at:  "2026-10-01T09:00:00Z",
  signature:  "..."
}

Notice that "entity: agent" is right there in the open. That is the point. The first thing a receiving system learns is the thing carrier attestation never told it.

How a receiving party verifies it

A token nobody checks is decoration. Verification should feel closer to checking a TLS certificate than to reading a manual.

Extract. Pull the token out of wherever the channel carries it. The whitepaper describes signaling headers for voice, extended headers for SMS, an X-ACES-* block for email, and message metadata for chat apps.

Resolve. Look up the claimed identity in the registry and fetch the public key.

Check the signature. Does the token verify against that key, and has it been tampered with?

Check the scope against the request. Is "take a payment" inside "appointment_reminders"? If not, no amount of friendly tone should change the answer.

Decide. Accept, challenge, route to a human, or drop.

The whitepaper says a compliant receiver can do the registry check quickly enough that it does not meaningfully slow a message down. The design goal is that verification is cheap enough to do every time, because anything optional gets skipped.

What a token does not do

Be honest about the limits.

It does not replace carrier attestation. STIR/SHAKEN stays; the token sits above it. The whitepaper is explicit that the two complement each other.

It does not prove an agent is well behaved. It proves who is accountable when it is not. That is the real value: a bad actor now has a name and an issuer attached to every message.

It does not work if only one side adopts it. Like any trust system, it gets better as more receivers check.

The takeaway

We spent decades teaching networks to answer "is this number legitimate?" The next decade needs them to answer "is this a person, which agent is it, and what may it do?"

A signed, scoped, issuer-backed token is how you get there without asking every recipient to become a fraud analyst. Software that wants to talk to people, and to other software, should be able to show a passport.

This is the layer Dial is building toward at the infrastructure level, so that your agent does not have to invent its own story for every stranger it contacts.