.svg)
When security architects first hear about SADAR, a reasonable question usually comes up in the first few minutes: can't we solve this with what we already have? API gateways inspect traffic. API firewalls catch injection and abuse. AI firewalls scan prompts and responses. Service meshes handle east-west authorization. Identity providers authenticate principals. Why does the agent economy need a new registry on top of all that?
The answer turns on a distinction that doesn't matter muchin a world of human-driven API calls but matters enormously once agents start calling agents: lookup is not discovery. Every control listed above isbuilt on the assumption that the caller already knows what it wants to call. The agent economy breaks that assumption.
A lookup starts with an identifier. You have a URL, an endpoint name, a service ARN, a model ID. You're asking infrastructure to resolve that identifier to a destination and to police what happens along the way. DNS is lookup. API gateways are lookup. Service meshes are lookup. Most of the controls we think of as "API security" assume lookup.
A discovery starts with an intent and a context. You have a task to accomplish — "summarize this claim adjudication decision," "initiate a refund," "retrieve the patient's most recent A1c reading." You don't yet know which agent (or tool, or service) is the right one. You need the infrastructure to answer three questions simultaneously:
Lookup-based controls can't answer any of those questions because they don't exist in the lookup model. They begin after those questions have already been silently answered — usually by whatever the agent's developer hard-coded or what a language model's context window happened to contain at the moment of decision.
It helps to be precise about the scope each existing control covers.
API gateways and API firewalls. These operate once a caller has chosen an endpoint. They enforce rate limits, validate schemas, detect injection, and apply policy to the traffic to a specific URL. They do not answer "which API should be called for this intent." They don't federate discovery across clouds. They have no concept of the originator behind the immediate caller. They are invaluable — and they are downstream of the problem SADAR solves.
AI firewalls and prompt-guard systems. These inspect inputs and outputs of a chosen model for prompt injection, sensitive dataleakage, jailbreak patterns, and toxicity. They presume the model has alreadybeen selected. They do not govern which agent should run, by whom, inwhat business process, on behalf of which originator. They govern the content of a conversation, not the authority to have the conversation.
Service meshes. These handle mTLS, retries, andtraffic policy between known services inside a trust boundary. They assume aknown service catalog with known workloads. They do not discover capabilities semantically, and they do not federate across trust domains.
Identity providers and IAM. OIDC and OAuth authenticate principals and issue tokens scoped to resources. They do not match intent to capability. They do not verify bilateral compatibility. A valid token says "this principal is allowed to call this scope" — it says nothing about whether this agent is the right agent for the task at hand, or whether the current originator chain authorizes this particular invocation in this business process state.
Service catalogs, developer portals, OpenAPI repositories. These publish metadata. They are lookup directories. They do not enforce anything at invocation. They have no runtime primitive.
Every one of these controls is necessary. None of them, alone or in combination, constitutes a discovery layer.
The shift from human-driven APIs to agent-driven workflows changes three things at once.
The caller is no longer a human. A human developer makes endpoint decisions once, at build time, and embeds them in code. An agent makes endpoint decisions continuously, at runtime, based on whatever context is present in its working memory. Lookup-based controls don't see the decision — they only see the call that follows it.
The number of possible callees explodes. A mid-sizedenterprise that used to integrate with dozens of SaaS APIs now faces hundreds or thousands of candidate agents, many of them dynamically instantiated, some running on-premises, some in partner tenants, some hosted by model providers. The N² problem is real: without a discovery layer, every agent has to hard-codeknowledge of every other agent it might call, in every environment it might encounter.
Attribution becomes non-trivial. When agent A calls agent B which calls agent C, the IAM-level answer to "who authorized this?" is "agent B" — which is true and useless. The question that matters to risk, audit, and regulation is "which human or business process originated this chain, and was that origination authorized to cause the action that ultimately happened?" No lookup-based control answers this. Without a spec-level mechanism for propagating and verifying originator identity, attribution degrades at every hop.
These are not nice-to-haves. They are the table-stakes governance properties that regulated industries already assume exist for human-driven systems and that currently do not exist for agent-driven ones.
A registry is the right primitive because the problem is fundamentally one of finding and committing to a capability atomically, with authorization as part of the commitment.
SADAR's core invocation primitive is searchAndInvoke. Ittakes an intent description, a context (originator, business process step, aller identity), and a selection strategy, and it returns either the invocation of a matched capability or a reasoned refusal. Discovery and authorization happen in one operation, against a registry — or a federation of registries — whose manifests are signed and bilaterally matched.
Several properties fall out of this design that lookup-based controls structurally cannot provide.
Bilateral manifest matching. The caller's manifest and the callee's manifest both express requirements. A call only proceeds ifboth sides' constraints are satisfied. This is not something an API firewall can check because it requires knowledge of the caller's manifest, the callee's manifest, and the semantic compatibility rules between them — all before traffic is emitted.
Signed manifests as ground truth. Capability claimsare cryptographically signed by publishers. Discovery does not depend on trusting the network, the DNS answer, or the developer who wrote the client. This is not something a service mesh or a catalog can offer without becoming, in effect, a registry.
Four-mechanism attribution. OIDC authentication, mTLS channel binding, publisher-signed manifests, and an OIDC claim extension for originator propagation together produce an attribution chain that survives arbitrary agent-to-agent hops. No combination of existing controls produces this chain, because none of them carry originator identity as a first-class propagated claim.
Registry-of-registries federation. No single central authority owns agent discovery. Registries federate peer-to-peer, with eachenterprise, cloud, or sovereign domain operating its own while participating in a global substrate. Lookup-based controls are either local (service meshes) or centrally owned (commercial gateways). Neither scales to a cross-cloud, cross-provider, cross-sovereignty agent economy.
Conformance levels. L1 through L3 let consumers treatdifferent registries and agents with graduated trust based on demonstrableproperties of their manifests and enforcement. This is a spec-level governance primitive, not a feature any single product can provide by itself.
"Can't we just extend OpenAPI?" OpenAPI describes endpoints. It is not a discovery protocol and has no bilatera matching, no attribution model, no federation, and no signed-manifest groundtruth. You could use OpenAPI as a description language inside a registry — butthe registry itself is the thing you still have to build.
"Can't service meshes federate?" They can, within trust domains and with significant operational complexity. They do notdo semantic discovery. They do not carry originator identity. They assume knownworkloads. A mesh is complementary to SADAR, not a substitute.
"Can't we solve this with policy-as-code in the agent framework?" An agent framework can enforce any policy it wants on its own workloads. It cannot enforce anything on workloads running in otherframeworks, other clouds, other tenants, or on-premises systems owned bypartners. Governance that lives inside one framework does not scale to a heterogeneous agent economy.
"Can't we wait for cloud providers to solve this?" Every major cloud is building some version of an agent registry. Each will be proprietary, aligned with that cloud's model provider relationships, and not federable with its peers. The outcome of that trajectory s visible in advance: fragmentation, vendor capture, and no end-to-end attribution across provider boundaries. A neutral specification is the only substrate that produces universal visibility and federation — including for sovereign, locally-hosted deployments that need to federate globally with no cloud dependency.
Where SADAR sits
SADAR is not a replacement for API firewalls, AI firewalls ,service meshes, or identity providers. Those controls continue to do the jobs they do well. SADAR is the layer they all quietly assume exists — the one that answers "which agent, invoked by whom, on whose behalf, in what business process, under what bilateral contract" — before any of the lookup-based controls get a packet to inspect.
The shorthand is deliberate: lookup controls secure the call you already decided to make. SADAR governs the decision to make the call. Without a registry operating at that layer, everything downstream is protecting a conversation whose authorization was never established in the first place.
That is the case for a new registry, and that is why the agent economy needs SADAR.
