Why AI Agents Need Unlisted Numbers

Source: Dev.to

The Visibility Problem for AI Agents

Every phone book has two kinds of numbers: listed and unlisted.

• Listed numbers are searchable by anyone.
• Unlisted numbers exist, but only the people you give them to can reach you.

AI agents currently lack this distinction, creating a visibility problem.

When an AI agent wants to be reachable, it publishes an Agent Card – a machine‑readable file describing its capabilities. Other agents that know its location can read the card and attempt contact. This works for public agents, but it is a serious issue for agents that should remain hidden.

Why discovery matters

• An internal agent with access to financial data, HR records, or production systems has an endpoint.
• Any other agent—internal or external, authorized or not—can discover it, probe its capabilities, and try to start a session.
• Authentication happens after contact is attempted, so the agent’s existence is already known.

Current frameworks solve how agents communicate, but not who should be able to find them. As agent ecosystems grow, the attack surface expands. Recent research highlights risks such as session manipulation and accidental credential exposure, illustrating that agents are becoming networked services that need visibility control.

The gap: agents can authenticate callers, but they cannot control who discovers them.

Unlisted Numbers for Agents: SARL

In telephony, the problem was solved with unlisted numbers. The Selective Agent Reachability Layer (SARL) applies the same principle to AI agents.

Where SARL fits in the stack

• SARL is not a transport protocol and does not replace A2A.
• It operates earlier in the discovery process, deciding whether an endpoint should be revealed at all.
• A2A still defines how agents communicate once they know each other’s endpoint.

Reachability tiers

An agent can expose all four tiers simultaneously. For example, a partner agent querying the Group token can reach the agent without learning that Private or Ephemeral tokens exist.

Core principle

The registry evaluates access before the caller receives the agent’s endpoint. An unauthorized caller receives silence (e.g., a 404), making the agent appear nonexistent.

Minimal SARL protocol flow

POST /register
{
  "id": "agent-123",
  "tier": "group",
  "credential": "cred-abc"
}

GET /resolve?token=group-token&credential=cred-abc

• 200 – endpoint returned (policy allows)
• 404 – agent not found (policy denies)

The caller only receives the endpoint if the policy permits it. This mechanism is transport‑agnostic and extends A2A without replacing it. Agents that do not use a SARL registry remain fully A2A‑compatible.

Demo & Specification

• Live prototype:
  Three panels: register an agent, set a reachability policy, resolve an endpoint. The “Start Demo” walkthrough shows the 404 → 200 transition as a policy is added.

• Full specification:

Known gaps (v0.1)

• Federated registry synchronization
• Token rotation
• Rate limiting

These issues are acknowledged but out of scope for the initial version.

Call for Feedback

I’m looking for developers building on A2A who have encountered the discovery‑control problem. If you’ve implemented workarounds—separate endpoints, manual allowlists, network‑layer isolation—please share your approach.

The SARL spec is open‑source, released under the Apache 2.0 license. Feedback and contributions are welcome on GitHub.