Skip to main content

​
ANS Trust Card and trust registry

A caller ID on its own proves nothing — any gateway can write any digits into a SIP header. What gives a caller’s identity weight is a verifiable anchor: a published record an outside party can fetch and check cryptographically, tied to a domain and to keys nobody else controls. Devotel Orbit ships two such anchors today. The first is Orbit’s own ANS Trust Card, a well-known JSON document that declares the platform’s domain-anchored identity for the emerging agent-discovery ecosystem. The second is a public trust registry lookup — a per-organization, opt-in endpoint that lets anyone with the URL ask “is this agent or number really who it presents as, and what is it delegated to do?” against your tenant’s own verification posture. This page is the model behind both.

​
1. Why caller identity needs a verifiable anchor

Brand spoofing is the cheapest attack on voice: vishing calls impersonate a bank, a clinic, or a delivery firm, and the rendered caller ID looks right because nothing in the PSTN ever checked it. Consumers have learned not to answer unknown calls, which punishes every legitimate business caller — your appointment reminders, delivery notifications, and fraud alerts compete against thousands of forged “verified” brands. The industry response spans two layers. STIR/SHAKEN signs the caller ID on every call (see the STIR/SHAKEN attestation model), which binds a phone number to the organization that resolves it. Agent identity is the newer layer: as calls and API traffic get answered by AI agents, the question “which agent, run by which operator, delegated to do what?” needs the same verifiable-answer treatment a voice caller ID gets — and that question is asked before any call exists. Orbit ships anchors for both layers, and the posture behind the registry is tenant-owned: your organization decides whether to publish its verification status publicly at all (opt-in per organization), which numbers carry full attestation, and which scopes its agents delegate. The organization-level controls below are yours to set; nothing in this model is a platform-mandated gate.

​
2. The Agent Name Service in context

ANS is a draft standard (draft-narajala-courtney-ansv2, April 2026) that anchors an AI agent’s identity to a DNS domain verified via ACME, with dual certificates (server + identity) and a transparency-log receipt for when you need it. The Linux Foundation announced its intent in June 2026 to host ANS as the trusted identity infrastructure for AI agents. Mechanically, an ANS name is a URI of the form ans://v{version}.{host}, and the record behind it is a Trust Card served at the well-known path /.well-known/ans/trust-card.json. ANS complements the NANDA AgentFacts document — it does not replace it. AgentFacts is a capability facts sheet (what an agent can do, for the NANDA Index). ANS is a naming and trust layer (who an agent is, anchored to a domain and keys). Orbit publishes both, and they cross-reference each other: the Trust Card’s endpoint metadata points at the AgentFacts URL, and resolvers treat the pair as one identity with two views. (A status note, in the same spirit as the shipped record: ANS is still a draft. Its full resolution flow expects _ans / _ans-badge DNS records and a transparency-log receipt that are not yet provisioned on the public zone — the Trust Card says so plainly rather than fabricating a claim. Fetching and verifying the card itself works today.)

​
3. Orbit’s platform Trust Card

Orbit publishes its own Trust Card at two addresses serving the same record:
  • https://orbit.devotel.io/.well-known/ans/trust-card.json — the canonical, static record on the marketing domain.
  • https://api.orbit.devotel.io/api/v1/public/.well-known/ans/trust-card.json — the API twin, so machine clients that only reach the API host resolve the identical document.
Both are unauthenticated, rate-limited on the public-read plan, and edge-cacheable for five minutes. The record declares:
  • ansName — Orbit’s ANS URI (ans://v1.0.0.orbit.devotel.io).
  • endpoints — the protocol surfaces Orbit speaks (HTTPS API, MCP, Agent2Agent) with each surface’s capability functions and metadata URL.
  • verifiableClaims — the Ed25519 JWK Set Orbit’s agents sign outbound HTTP requests with (HTTP Message Signatures, RFC 9421), so a resolver can match a signed request’s key id against the published keys. Orbit mints no ANS-only keypair: the card reuses the same signing keys that already authenticate its outbound machine traffic.
  • resolverStatus — which parts of the draft’s full resolution flow are not yet live on the public zone (DNS records, transparency receipt), stated explicitly.
A resolver verifies the card in four steps:
The verification is deliberately conventional — standard JSON, standard JWK Set, standard HTTP signatures — so any PKI tooling you already trust can do it without an ANS-specific client.

​
4. The tenant-facing trust registry lookup

The card publishes Orbit’s identity. The trust registry resolves your organization’s posture publicly — per organization, and only when you turn it on. It answers the carrier/enterprise question “is this caller or agent really this brand, and what is it delegated to do?” by composing every verification signal Orbit already computes for you into one public resolve. The lookup is a single GET under the same public well-known scope:
One resolve fans out to three halves:
  • Brand identity — the same unified brand-identity rollup your dashboard’s brand-identity status hub renders (registration and verification status per channel — SMS registration, toll-free, WhatsApp, RCS, branded calling, number verification). The registry reports the rollup’s overall state, trust score, and how many of the channels that apply to your organization are verified.
  • STIR/SHAKEN attestation — resolved with the same attestation logic the dial path stamps on the egress INVITE, so the registry reports the egress-time decision, not a registry-side guess. Per ATIS-1000074 the tier reads as full (A — verified number ownership), partial (B — delegate certificate or active pool lease), or gateway (C — unattributable). With no phone parameter the lookup reports unknown-until-resolve until a number is supplied. Orbit only ever signals the level; Devotel’s carrier of record signs the PASSporT itself — the lookup is read-only and crosses no carrier for outbound traffic.
  • Delegated capability scope — the capability surface of your organization’s active API keys, resolved through the same default-deny scope ledger the hosted MCP server enforces (a scope not granted means no access), de-duplicated across keys and frozen as a settled snapshot. The response enumerates capability scope strings and MCP tool names only — key ids, hashes, and key material never cross this boundary.
An abbreviated response for a hit:
Two deliberate properties keep the surface safe to publish:
  • 404 collapse. An unknown organization, an organization that hasn’t opted in, and a malformed lookup all collapse to the same 404 AGENT_TRUST_NOT_FOUND envelope. A probe can neither enumerate tenants nor learn which organizations publish — one fixed blind spot for all three failure classes.
  • Cacheable. Resolved answers carry a 60-second edge cache — short enough that a newly revoked agent stops resolving within a minute, long enough to absorb lookup fan-out from the parties that need it.
Responses are capability and verification metadata only — there is no credential in the envelope, on either side.

​
5. Improving your attestation posture

What the registry reports is the same posture the rest of the platform enforces, so raising it uses the levers you already have:
  1. Move calling identity onto numbers you own. Full attestation (A) requires the calling number to be in your organization’s own Orbit numbering records — purchased or ported in. Pool leases and delegate certificates top out at partial (B). The worked examples in the STIR/SHAKEN attestation model name exactly which shape reaches which level.
  2. Complete brand verification per channel. The public trust score is the same roll-up the brand identity and trust score concept page describes; every verified channel (SMS campaign registration, toll-free verification, RCS branded agent, branded calling) lifts it.
  3. Register delegate certificates for BYON numbers. A bring-your-own caller ID with a registered delegate certificate moves from gateway (C) to partial (B) — the delegated-attestation path, capped at B by design.
  4. Tighten delegated scope. Keep API-key scopes minimal; the registry’s capability surface is exactly the union of your active keys’ scopes, and revoked keys drop out within one cache TTL.
  5. Turn on publication. The registry answers for an organization only when its public trust-registry flag is enabled; the platform card requires no per-tenant action.
Set your target level and delegate registry on the attestation posture page; the same levers change what the public lookup reports, because both read the one posture.