Every phone book has two kinds of numbers: listed and unlisted. Listed numbers are for anyone to find. Unlisted numbers exist – but only the people you give them to can reach you.
AI agents don't have this distinction yet – and that creates a visibility problem.
The way agent discovery works today
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 is fine for agents that are meant to be public. It's a serious problem for agents that aren't.
Imagine a company deploying an internal agent with access to financial data, HR records, or production systems. That agent has an endpoint. Any other agent – internal or external, authorized or not – can discover it, probe its capabilities, and attempt to initiate a session.
Authentication happens after contact is attempted. But by then, the agent's existence is already known.
Current agent frameworks solve how agents communicate. Nobody has solved who should be able to find them in the first place.
The emerging agent attack surface
As agent ecosystems grow, the attack surface grows with them. Recent research has highlighted risks in agent-to-agent systems – from session manipulation to accidental exposure of credentials in automation pipelines.
These incidents are not specifically about discovery, but they illustrate a broader problem: agents are becoming networked services, and networked services require visibility control.
The gap is specific: agents can authenticate callers, but they cannot control who is able to discover them.
An old idea applied to a new problem
In telephony, this problem was solved decades ago. Unlisted numbers. You exist on the network – but you're invisible to anyone who doesn't already have your number.
SARL (Selective Agent Reachability Layer) is a registry-based visibility layer that determines whether an agent should be discoverable before any contact attempt occurs.
Where SARL fits in the stack
SARL is not a transport protocol and it does not replace A2A. It operates earlier in the discovery process. A2A defines how agents communicate once they know each other's endpoint. SARL defines whether that endpoint should be revealed at all.
SARL allows an agent to expose different reachability tiers:
- Public – any authenticated agent can reach you. No policy needed.
- Group – only agents with a matching credential can find you.
- Private – only agents that know your exact token can reach you.
- Ephemeral – a time-limited token for a specific operation.
One agent can hold all four tiers simultaneously. A partner agent queries the Group token – they can reach you, but they never learn the Private or Ephemeral tokens exist.
The critical detail: the registry evaluates access before the caller receives the agent's endpoint. An unauthorized caller doesn't get a rejection – they get silence. The agent doesn't exist for them.
How it works in three steps
1. Agent registers: POST /register {id, tier, credential}
2. Caller queries: GET /resolve {token, credential}
3. Registry decides: 200 (endpoint returned) or 404 (agent not found)
The caller only receives the endpoint if the policy allows it. This is transport-agnostic. SARL extends A2A – it doesn't replace it. Agents without a SARL registry remain fully A2A-compatible.
See it live
A minimal working prototype is running at:
https://sarl-spec-production.up.railway.app/
Three panels: register an agent, set a reachability policy, resolve an endpoint. Click Start Demo for a guided walkthrough that shows the 404 → 200 transition as a policy is added.
The full specification is at:
https://github.com/vizmutlabs/sarl-spec
What's missing and what comes next
SARL v0.1 is a protocol specification, not a production system. Known gaps include federated registry synchronization, token rotation, and rate limiting. These are solvable – they're not in scope for v0.1.
What I'm looking for now: developers building on A2A who have run into the discovery control problem. If you've built a workaround – separate endpoints, manual allowlists, network-layer isolation – I want to hear how you approached it.
The spec is open. Feedback welcome on GitHub.
SARL is an open protocol specification released under the Apache 2.0 license.
Top comments (0)