How to verify an AI voice agent that calls your business

The problem: who is calling, and who sent it

Phone systems were designed around people. Caller ID reports a number, and the number says little about who is on the line and can be spoofed. A human caller can be asked questions, recognized over time and held accountable. A voice agent can be pleasant, fluent and confident while representing anyone, or no one.

A business that takes calls from agents has two poor defaults. It can refuse every automated caller, which becomes harder to sustain as customers hand routine calls to assistants. Or it can act on claims it cannot check, which invites impersonation: a caller that says it represents a known company costs nothing to make. What is missing is a stable identifier the business can look up for itself, independent of the phone network and of the platform the agent runs on.

Which agent is calling is also not the same question as what it is allowed to do. Knowing who sent a caller does not decide whether to share a record, move an appointment or accept an order. That decision stays with the business.

How a business resolves a calling agent's AgenID

An AgenID is an identifier of the form agenid:<ULID>; the spec's example is agenid:01J8Z3K3F2QZ9X6V7R4T8N2W5Y. When an agent presents one, by stating it, passing it in call metadata or including it in a follow-up message, the business can check it without an account or a relationship with AgenID.

• Resolve it. Open https://www.agenid.com/a/<agenid> in a browser for the Verification Card, or request it with Accept: application/json for the resolution envelope. The verify page does the same from a search box.
• Read the operator's manifest. It names the agent, the operating organization and its domain, the agent's purpose and channels, and the three disclosure attestations.
• Re-verify it rather than trusting the page. The envelope carries the signed ManifestProof and the operator's public key, so the signature and the manifest digest can be checked offline. The registry cannot forge an operator's signature.
• Compare the operator's key from two places: the registry at https://www.agenid.com/v1/keys/<key-ulid> and the operator's own domain at https://<operator_domain>/.well-known/agenid/keys.json. If the operator publishes no copy, you have one source, not two.

What a resolved identity tells you

A successful resolution tells you that an operator registered this identifier, what that operator declared about the agent, and that the declaration has not been altered since it was signed. It is a self-declaration. The reference deployment at agenid.com issues nothing above L1_REGISTERED today: L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved and is not issuable at all.

That is still useful for a phone line. A business can recognize the same agent across calls, see which organization claims to operate it, and keep a record that can be checked again later. It cannot yet conclude that the domain or organization named in the manifest has been independently checked, and it cannot conclude that the voice on this particular call is the registered agent, for reasons explained below.

How operators attach an AgenID to voice agents

An operator registers each agent at /issue, where the signing key is generated in the browser and never sent to AgenID, or with the command-line tool described in the onboarding guide. The result is a permanent identifier that stays the same if the agent later moves to a different voice platform.

For the major voice platforms, AgenID publishes integration patterns describing how an operator could carry the identifier alongside an agent built there. Each is a pattern, not a package: no adapter package exists for any of them, and none is an installable integration.

• Retell AI integration: pattern, not a package.
• Vapi integration: pattern, not a package.
• Bland AI integration: pattern, not a package.
• ElevenLabs integration: pattern, not a package.

Disclosure rules: EU AI Act Article 50 as context

Disclosure that a caller is an AI is increasingly a regulatory topic, not only a courtesy. Article 50 of the EU AI Act, on transparency obligations, provides that AI systems intended to interact directly with natural persons are to be designed and developed so that the people concerned are informed they are interacting with an AI system, unless that is obvious from the context. The article also covers other transparency duties beyond conversational systems.

This is context, not legal advice. Whether and how Article 50 applies to a particular voice agent depends on the facts and on the text in force, which should be read at the source and assessed with counsel. AgenID does not make an agent compliant with any law. What it offers is a place for an operator to state, under its own signature, how its agent behaves, in a form a counterparty can resolve and re-check.

The disclosure attestations are signed self-declarations

Every manifest carries three disclosure fields: is_ai, discloses_to_user and human_escalation. They say whether the agent is an AI, whether it tells the people it talks to that it is one, and whether a human can take over the conversation.

These are operator self-declarations made under signature. They are not verified behavior. No API can observe whether an agent actually announces itself on a call or actually transfers to a person, so no one, including AgenID, can check these claims. What the signature does establish is attribution: the operator made this statement, it has not been altered, and it stays attached to the agent's permanent identifier. If a caller's behavior contradicts its operator's signed declaration, the business has a durable record of what was promised and by whom.

In the browser issuance flow the two behavioral attestations start as false, so an operator has to set them deliberately rather than sign a default.

See it in a scenario

Two scenarios show the mechanism on a phone line. In booking an appointment, a personal assistant calls a dental practice and the practice's own agent resolves the caller before opening the calendar. In sales outreach, an outbound agent calls a prospect and the question runs the other way: who is selling to me, and on whose behalf. Both are illustrations of the protocol and label themselves that way.

The honest limits for voice today

The largest limit is recorded in AgenID's own security analysis as GAP-C1: nothing yet binds a live request, and therefore a live call, to a registered agent in v1.1.1. An agent can state an AgenID, and the business can confirm that the identifier resolves and that its manifest verifies. It cannot confirm from the protocol alone that the voice on the line is the agent that identifier belongs to, because a signature authenticates a signed object and an object can be repeated by anyone who has seen it.

The scenarios show one way this could be closed: the business issues a fresh challenge during the call and the agent answers it with its key. Challenge-response is a proposed pattern. v1.1.1 defines the signed objects, not that exchange, and nothing in the reference deployment performs it today.

Two further limits apply. There is no deployed revocation flow, so an operator cannot yet mark an agent as withdrawn. And there is no signed authorization object in v1.1.1, so an AgenID never tells a business what a caller is permitted to do.