What STIR/SHAKEN Doesn't Tell You About Who's Calling

If you've worked with voice telephony in the last few years, you've encountered STIR/SHAKEN — the framework that assigns attestation grades to phone calls to combat spoofing:

A (Full attestation): The carrier knows the caller's identity and that they're authorized to use the calling number

B (Partial attestation): The carrier vouches for the call origin, but not that the number belongs to this caller

C (Gateway attestation): The call passed through; origin unverified

STIR/SHAKEN is a genuine improvement over the spoofed-caller-ID era. But it answers exactly one question: did this call legitimately originate from the carrier network it claims?

For AI agents, that question is necessary but not sufficient.

The identity gap

STIR/SHAKEN attestation tells you "this call came from Verizon" or "this call came from AT&T and the number checks out." What it doesn't tell you:

Whether the caller is a human or an AI agent

What organization the agent works for

What the agent has been authorized to do

Whether appropriate consent exists for this communication

What the agent has told this contact in prior interactions

An AI agent with a Twilio number calling on behalf of a company gets the same STIR/SHAKEN treatment as a human employee using the same number. The attestation is at the carrier level, not the application level.

Why this matters

As AI agents make more calls, recipients need more information than carrier attestation provides. They need to know:

1. Is this a human or an agent? Under the EU AI Act Article 52 and emerging US legislation, there are disclosure requirements for AI-to-human interactions. Carrier attestation cannot fulfill these requirements because it doesn't capture entity type.

2. Is the agent authorized? A legitimate agent calling on behalf of a company should be able to prove that authorization cryptographically — not just rely on the company's carrier relationship.

3. Is the consent in order? TCPA requires express written consent for automated calls. That consent record should be verifiable by anyone who needs to audit the call — not stored in a proprietary database that only the calling company can access.

What application-level trust looks like

The right answer is a trust layer above the carrier layer. STIR/SHAKEN handles carrier attestation. ACES handles application-level attestation.

Every ACES-native call carries an Agent Attestation Token (AAT) — a signed, verifiable claim in the SIP/WebRTC signaling headers that establishes:

The agent's ACN (cryptographic identity)

The agent's authorization to communicate on behalf of its organization

The consent status for this specific contact

The entity type (agent, not human)

Any ACES-compliant receiving system can verify this token against the ACN registry in under 50ms. No STIR/SHAKEN grade can tell you what the AAT can.

The disclosure requirement

For calls from AI agents to humans, ACES enforces mandatory disclosure. When the agent's policy includes "disclosure": "required" (which it should, for any human-outward call), the first turn of any voice interaction must include a natural-language disclosure:

> "Hi, this is an AI assistant calling on behalf of Genway. I'm reaching out about your trial signup. Is now a good time?"

This is not advisory. It's enforced at the infrastructure layer before the call is connected. The compliance isn't in the agent's prompt — it's in the protocol.

The bottom line

STIR/SHAKEN is a carrier-level trust system for a carrier-level problem. It was the right thing to build in the robocall era.

The agentic era has different trust requirements. Recipients need to know entity type, authorization, and consent — not just carrier origin. Those requirements need an application-layer trust standard, because the carrier layer was never designed to carry that information.

The two layers are complementary. STIR/SHAKEN remains necessary. What's missing is the layer above it.