Who Registered This Agent? ATI Builds Trust Into Discovery

TL;DR for operators

When hundreds of agents span internal teams, vendors, and partner domains, discovery has to answer more than which agent can do the task. Operators also need to know who registered it and what evidence justifies trusting its identity. Agent Trust Infrastructure (ATI) addresses those questions by separating trusted-registry governance, per-agent publication, and resolver-side discovery rather than collapsing them into one directory.¹

That separation lets organizations govern which registries are trusted, preserve registration provenance, expose lifecycle state, and filter revoked or otherwise ineligible agents before returning them for use. In the authors’ tested prototype, mean discovery latency was 25 ms and sustainable discovery throughput exceeded 29,000 requests per second; these are feasibility results from one deployment, not evidence of Internet-scale performance.

The important boundary is that fast, authenticated discovery is still not behavioral trust. ATI can verify identity, credentials, metadata, and lifecycle state, but it does not establish that a discovered agent will behave correctly, safely, or reliably after invocation.

Agent discovery becomes difficult when the directory is not enough

Consider an enterprise with hundreds of agents distributed across internal teams, software vendors, and partner organizations. Finding an agent capable of a task is only the first question. An operator also needs to know who registered it, which administrative domain stands behind that registration, whether the credentials are still valid, and what evidence supports the claimed identity.

A centralized allowlist can answer some of these questions while the environment remains small. It becomes less attractive once different organizations control their own agents and identifiers. Discovery then requires coordination among separate administrative domains rather than merely faster search.

ATI addresses this by separating the infrastructure into three roles. The Agent Root maintains the catalog of trusted registry namespaces. Agent Registries verify and register individual agents, issue or bind credentials, publish metadata, and record lifecycle information. Agent Resolvers synchronize information from trusted registries, maintain local capability and identity indexes, and answer discovery requests.

The consequence is architectural: the Root does not need to contain every agent record, and a Resolver does not have to treat every reachable registry as trustworthy.

Naming carries trust provenance with it

Different agent platforms may identify agents with domains, platform-issued IDs, decentralized identifiers, or key-derived identifiers. ATI does not require them to abandon those native identities.

Instead, registration produces a composite identity:

Here, $I_a$ is the agent’s native identifier and $S_r$ is the suffix of a Root-authorized registry. Normalization converts the native identifier into a DNS-compatible prefix.

This couples two pieces of information that would otherwise be separate: the agent identifier and the registry responsible for placing it into the discovery system. The resulting identity can participate in DNS-compatible publication, caching, synchronization, and resolution while retaining a link to its original identifier.

For an enterprise spanning several vendors or business units, that suggests a way to keep heterogeneous identifiers while still imposing a common governance namespace. That is a Cognaptus inference from the design rather than something established by the prototype benchmark.

Authentication is a graded decision

ATI also avoids treating authentication as one binary state.

The levels are progressive. Enhanced authentication adds transparency evidence to Basic authentication, while Advanced authentication adds DNS-based public-key binding.

That design gives operators a policy lever. An internal, low-risk capability lookup may not require the same verification path as a cross-domain agent preparing to invoke a sensitive service. ATI supplies the infrastructure for such differentiation; the paper does not determine what risk policy an enterprise should adopt.

The prototype supports feasibility, with a visible tail

The quantitative evidence is a prototype benchmark, not a controlled comparison with alternative architectures.

The authors report mean latencies of 58 ms for registration, 25 ms for discovery, 9 ms for data publication, and 4 ms for review. At the 95th percentile, those rise to 127, 32, 10, and 6 ms respectively.

Discovery has the most noticeable tail: its 99th-percentile latency reaches 165 ms despite a 25 ms mean. Registration reaches 153 ms at the same percentile. Publication and review remain much tighter at 11 ms and 7 ms.

The prototype also sustains more than 19,000 registration requests per second and more than 29,000 discovery requests per second without observable response-latency degradation in the tested deployment.

Those measurements show that the proposed decomposition can operate at high request rates under the authors’ test conditions. They do not establish how the same design behaves across distant geographies, heterogeneous organizations, different registry topologies, or Internet-scale synchronization. The source package also reports no head-to-head baseline and does not provide enough workload detail—such as total request counts, repetitions, and fuller concurrency configuration—for strong independent replication of the performance claims.

Enterprise value lies in governing discovery

For enterprises, the design is most relevant before one agent invokes another.

A governed Resolver could restrict discovery to approved registries, reject expired or revoked agents, expose authentication requirements, and return candidates based on structured capability metadata. The same primitives could support internal agent catalogs, partner ecosystems, agent marketplaces, or automated routing layers.

Root-level registry authorization also provides a broader control point. If a registry becomes compromised or untrusted, governance can act on that registry relationship rather than editing every downstream agent entry individually.

This is where ATI extends beyond a conventional service directory. The directory answers what exists. The surrounding infrastructure also records who is authorized to publish entries, how an identity is bound to that authority, and whether the published agent remains eligible for discovery.

Verified identity still stops short of trustworthy behavior

The sharpest boundary in the paper is also the easiest one to overlook.

ATI can verify identity credentials, registration evidence, metadata, registry status, and lifecycle state. None of those checks proves that an agent’s answer is semantically correct, that its service quality is acceptable, that its tool use is safe, or that it will comply with application policy after authentication.

Commercial deployments therefore still need higher-layer controls such as behavioral monitoring, policy enforcement, risk scoring, output or tool-use auditing, and application-specific authorization.

The practical contribution is narrower and more defensible: ATI provides a proposed infrastructure for deciding which identity evidence should accompany agent discovery and who governs that evidence. If agent ecosystems grow across organizational boundaries, that problem arrives before behavioral trust can even be evaluated.

Cognaptus: Automate the Present, Incubate the Future.