SADAR Features

The Foundation

Registry & Discovery

A Trust Anchor for agents, tools, resources, and processes to be found — deterministically

Grounded in Industry Standards

SADAR defines what an agent, tool, resource, or process does — and the data it exchanges — using established industry standards rather than free-text descriptions. Meaning is consistent across teams, organizations, and clouds.

Capabilities are grounded by IRI in published standards such as: industry classifications (NAICS, ISIC, NACE, GICS), process frameworks (AeTOM, BIAN, SCOR), the O*NET task taxonomy, and operations standards (HL7, X12, ISO 20022, SWIFT, NCPDP).
Any published standard can anchor a definition, as long as requester and provider agree on it; where standards are insufficient, they can be extended using namespaces for APIs, local functions, more detailed processes, etc.
A semantic match in SADAR means two definitions are grounded in the same standard definition of process and data meaning and syntax — not that their names are similar. This is distinct from vector or cosine similarity.
Multi-step processes are themselves a first-class registry entry type, declaring steps, sequencing, prerequisites, and exclusions — scaffolding for planner agents and a basis for dependency enforcement.

Bilateral Match Agreement

The deterministic matching enforces exact matching of requirements vs capabilties. Non-functional requirements of both requester and server can be expressed as mandatory vs desired requiring an exact value match, match in a range, overlapping ranges, and "one-of" for maximum flexibility while preserving control.

The match applies in two directions: what the requester requires vs. what the provider advertises and requires of requesters. Both must pass.
Each requirement carries one of three strictness levels — optional preference, hard requirement, or hard exclusion — and every candidate is returned classified asa full, partial, or non-match.
Provider requirements act as a built-in right of refusal: a non-qualifying requester never discovers an entry it cannot invoke.
Conformant registries must return identical results for identical inputs, regardless of which registry operator processing the query.
Only candidates are returned; the requesting organization's own resolver makes the final selection and cannot bypass the match.

Verifiable Manifests

Every record in the registry — entity, agent, tool, resource, process, and registries themselves— is a publisher-signed, immutable manifest: the authoritative, tamper-evident record of what a capability is, what it requires, and what it guarantees.

Manifests are signed with JWS and immutable; any change produces a new versioned manifest as a new registry entry. The new manifest is signed, preserving version history.
An agent manifest carries both requester and server role sections as appropriate. They use the same vocabulary — what it wants when calling, and what it offers and requires when called. In this way, agents can both request and be a server. The manifest sections define their interface contracts in both capacities.
Manifests contain four non-functional requirements categories — Financial, Operational, Governance/Compliance, and Protocol. These are bound to the request and server definitions.
One capability per manifest; endpoints offering many capabilities publish many manifests under a shared endpoint identifier, each versioned independently.
Lifecycle states (draft, active, deprecated, superseded, retired) apply to each registry entry. Future date/times can be specfied. For deprecated, superseded, and retired, an alternate entry ID (Publisher ID + Entry ID + Version) may be specified.

Federation & Registry Distribution

Registries may run independently or join a federated network. A sovereign, locally-hosted registry can federate globally with no cloud dependency. A governed Directory controls who may interoperate. Private registries are fully supported and may federate privately or consume from publically federated registries.

Six registry types are defined: Provider, Marketplace, Industry, Community, Internal, and Registry of Registries (RoR).
A Directory of Authorized Registries, the RoR, governs federation. It contains a list of Authorized Registries to which federation may be configured.
Federation works through controlled query forwarding and push/pull replication. Home Registries define the non-functional requirements governing their behavior - which may impose rate limits, replication or query costs, etc.
A registry that has forwarded a query via federation and received a response is a Host Registry. The host receives a copy of the Home registry's manifest and that of its publisher along with any returned entries. This allows the verification and authentication patterns to operate consistently.
Every manifest carries its home_registry_id preserved unchanged across all forwarding and replication, so a consumer can always tell a native entry from a replicated one — provenance survives federation. A host registry may not forward a hosted entry - that is the provenance of the home registry to control.
Federation uses the same OIDC-over-mTLS authentication as any other interaction — there is no separate federation token system.

Registry Isolation

The registry is a discovery-time component only. It is never in the runtime call path and never holds sensitive operational data. This removes the registry as a bottleneck or a single point of compromise.

The registry facilitates exchange of the signed manifest; after discovery, consumer and provider communicate directly.
It never holds usage tokens, credentials, keys, or sensitive operational data. That is directly exchanged agent to component. Since manifests are publisher signed, they are tamper evident.
It is never the token issuer for invocations — tokens are issued by the target's own authentication endpoint.
Once discovery completes, runtime interactions don't depend on registry availability, until the discovery TTL expires and rediscovery is required.
The RoR and registries follow standard enterprise high-availability and geographic-distribution patterns across clouds, geographies, and jurisdictions. RoR's are a system of fully replicated directories of registries. For federation, the participating registries configure a primary, secondary, and tertiary RoR for high availability.

Verifiable By Design

Trust & Attribution

Cryptographic Proof — every entry verifiable, every interaction attributed, no call anonymous

Standards-Based Security

SADAR's security model is built entirely on established cryptographic standards — OIDC, OAuth, JWS, and JWE — with no proprietary trust mechanisms.

OIDC Client Credentials over mTLS]is the normative authentication baseline for every interaction; TLS 1.2 minimum, with algorithm and minimum key strength declared in the manifest.
Every registry entry publishes a JWKS endpoint exposing a signing key for manifest verification and an encryption key for usage. Key rotation is by endpoint update, no manifest republication.
Every manifest is signed by its publishing entity, so only the authorized entity can publish it and any consumer can independently validate integrity.
Manifests are immutable — changes produce a new versioned, signed entry.

Secret-less Credential Handshake

Each manifest carries the authentication endpoints for its entry. This enables credentials to be exchanged directly between requester and provider at runtime — never through the registry. The provider returns a time and requester bound token removing stored keys from transactional usage.

Each manifest declares the party's OIDC authentication endpoint, trusted by virtue of the entity's signature on the manifest - only the publisher can sign the manifest.
The requester authenticates directly to the provider. The provider's own endpoint issues a usage token bound to the requester's identity.
Tokens are minted at request time, carry replay protection, the transaction instance ID, and are bound to the requester. Tokens have a TTL and are reauthenticated upon expiry - not simply renewed.
Six OIDC scopes guard registry interactions: registry search, manifest resolution, registry listing, health, telemetry repatriation, and invocation.
First use mechanisms allow for automated or human-in-the-loop first time discovery.

Authority That Travels - the Context Token

A SADAR Context Token (SCT) travels with each invocation, carrying the originator's scope of authority through every step of a multi-agent flow and recording, cryptographically, how that authority propagated.

The SCT is a JWS-inside-JWE token carrying authorization claims attested at each trust-boundary crossing. The chain cyrptographically accrues entries at each boundary building an immutable non-repudiation record.
Five chain operations cover the patterns: Open (establish the originator's context), Continue (pass it forward), Hold (suspend for asynchronous or human-in-the-loop steps), Authoritative Carry (continue under elevated authority), and Close (terminate).
Four trust models — direct_auth, asserted, impersonation, and deputy — define how an originator's identity propagates downstream, negotiated bilaterally at discovery.
Deputy preserves both the agent's and the originator's identity at every hop, and is preferred over impersonation in negotiation ties because it keeps attribution intact.

Full Attribution & Non-Repudiation

Every invocation is authenticated and generates an attributed, time-limited audit record — no action in a SADAR flow is anonymous.

Each invocation produces a structured Telemetry Record — the per-call, ground-truth audit fact — alongside the SCT chain's attested context history.
Every conformant trace span carries provenance attribution identifying the issuing entity, agent, and environment. Both ends of an interaction are attributable enabling tamper-evident cross-checking.
Federation works through controlled query forwarding and push/pull replication. Home Registies define the non-functional requirements governing their behavior - which may impose rate limits, replication or query costs, etc.
Cryptographic parity requires values that appear in multiple layers (Baggage, span attributes, SCT claims, Telemetry Record) to agree at every point of observation. This serves as the trust foundation for tamper-evident audit reconstruction.
Telemetry repatriation returns redacted/encrypted trace fragments across flow boundaries, with both sides declaring exactly what is and isn't disclosed — visibility for the originator, data control for the provider.

Agreed Before - Not Assumed

Governance & Compliance

Operating, financial, legal, and compliance postures — all matched at discovery, before any interaction occurs

Process Consistency

SADAR grounds every capability in an explicit process context - business or technical. Sequencing, prerequisites, scope coverage can be checked at discovery — addressing silent failures from inconsistent/erroneous process execution.

Manifests declare the process step a capability provides, grounded in standard frameworks (APQC PCF, HL7 workflows, X12 transactions, and others).
Manifests may declare prerequisites — steps that must have been completed before that capability is invoked. The manifest may also declare scope exclusions explicitly stating what parts of a process it does not perform.
SADAR supports a registry entry of type process. The process defines a process flow to be executed across multiple steps. The process is defined using the same industry frameworks the agent, tool, and resource manifests use to advertise capabilities. This enables a planner agent to consume the process definition as a template serving to define the capabilities required to fullfil the process's objectives.

Compliance Posture Matching

Both requesters and providers declare the regulatory frameworks under which they operate, and discovery matches compatibility before any interaction. Trust in the asserted framework compliance is via the trust in the publishers. Even for internal-only components, this ensures that discovery only finds ones with matching control postures. This can also be used to express sensitivity and risk ensuring that sensitive data only is accessed and processed by registry entries thus marked. The same applies for risk posture.

Requesters declare their compliance frameworks requirements (HIPAA, GDPR, SOC 2, FedRAMP, ISO 27001, etc.) using SADAR compliance IRIs as a Governance non-functional requirement.
Providers advertise the compliance frameworks that they support to match requesters requirements. By marking a framework as MANDATORY, the provider asserts that the requester must also support that framework, not simply require it of the provider, in order to be allowed to interact.
This bilateral matching of compliance terms ensures that compliance is consistent across the execution chain as a transitive requirement.
Either party may reference compliance documentation or proof within their manifest. Sensitive artifacts (such as audit results) may require authentication using the authentication endpoints in the Publisher (e.g. entity) registry manifests of each party using the same mechanism.

Controlled First-Use Authentication and Authorization

SADAR defines the mechanics for a first-time interaction between previously unknown parties — credential exchange, licensing acceptance, payment authorization, etc. — with an option for human review before automated provisioning occurs.

The standard defines first-use mechanics for establishing a new provider relationship, including acceptance of existing API keys or licensing credentials.
Organizations configure whether first use triggers automated provisioning or requires human review first. This can be a blanket policy or have filters such as accepting new agents, tools, or resources from an allowed list of publishers (e.g. internal, trusted partners, etc.).
First-use events are attributed and recorded, establishing an auditable authorization record for every subsequent interaction.
Either party may expose certifications or letters of attestation, optionally behind authentication. These can be programatically assessed or routed to human-in-the-loop for review.

Machine-Readable Terms

Operations & Financials

Runtime characteristics, costs, and payment methods declared in the registry and matched at discovery - agreeed before use

Enforceable Operational Controls

Entries advertise machine-readable non-functional requirements — across Financial, Operational, Governance, and Protocol categories — matched at discovery so operational constraints are settled before invocation, not negotiated after.

Financial terms — cost model, pricing, payment methods are declared in the manifest - visible to the requester before selection and enforced during discovery.
Operational terms — rate limits, quotas, throughput, availability, and SLA commitments — are machine-readable and enforceable by both sides.
Governance terms — terms, data sovereignty, jurisdiction, privacy, encryption, compliance, and licensing — are declared per capability.
Each requirement carries a three-tier strictness flag, so a constraint can be a preference, a hard requirement, or a hard exclusion. Capabilities that fail a hard requirement are never surfaced in discovery.

Usage Payment

Manifests carry everything needed for direct requester-to-provider payment settlement. This includes support for third party processors such as STRIPE and emerging agentic payment models such as x402.

Registries and capabilities may charge for usage as declared in their manifests, subject to the same NFR matching as any other dimension.
Costs may be assigned even for internal components for cost accounting, chargeback, or cost-driven agent decisions.
Manifests carry public merchant codes and payment endpoints, enabling direct requester-to-provider settlement.
Matching decisions can use within-the-range, max, etc. pricing filters as criteria.
Clear requester attribution provides the necessary information to the provider to accumulate tier usage at the component or entity level. Entities can defined as a hierarchy allowing for cost granularity at the enterprise, legal entity, department, project, system, etc. level as desired.

Cummulative Risk

Risk-Aware Operation

Risk isn't defined by any one action - it is the acummulation of each action's risk profile

Grounded in Industry Standards

As a process executes, individual steps and actions may not represent a material risk on their own but a pattern of steps, or the cummulative affect of them may. To address this, SADAR defines a cumulative, in-flight risk score — a value from 0 to 1 that starts at zero and is adjusted up or down as a flow proceeds. Risk score adjustments are signed by the adjuster creating verifiable proof of the adjustment making it tamper evident.

SADAR provides a normative mechanism for conveying this risk score across the process. The decisions about how to adjust and interpret the score are beyond the scope of the specification allowing the user of a conformant system to do so in accordance with their enterprise risk management policies and risk appetite.

Agents, tools, resources, and guardrails emit signed Risk Score Adjustments — positive for risk-increasing events, negative for risk mitigation or reduction — each carrying a delta, a TTL, a standard reason, and free-form context.
The adjuster must sign the adjustment with its manifest's published key for verification and tamper evidence. The adjuster may include data encrypted with the same key in the free-form context providing evidence while protecting sensitive data.
A starter set of reasons covers events like sensitive-data access, state change, external invocation, policy violation, attestation anomaly, bias detection, and hallucination detection; organizations extend it in their own namespaces.
Adjustments propagate as a list in OTel baggage; an attested scalar is carried in the SCT chain at each trust-boundary crossing, forming a tamper-evident record of how risk evolved.
The risk score is floor-clamped at zero, so a flow cannot "bank credit" against future risk-taking and ceiling clamped at 1 for similar reasons.

Substrate, Not Policy

SADAR carries and propagates risk signals; itdeliberately does not decide what they mean. The data model and propagation arenormative — the accumulation algorithm and any intervention are left to theimplementer.

Conformant implementations must accept and propagate adjustments without dropping, reordering, or altering them, and must preserve unknown reason codes for forward compatibility.
How adjustments combine into a current score is the user of the conformant platform's concern; the spec mandates no method or process.
Intervention thresholds and mitigation actions are out of scope — what to do about accumulated risk belongs to the consuming system.
A separate, optional impact score lets a provider declare the static potential severity of misusing its capability, distinct from the in-flight risk score; NIST SP 800-30 is referenced informatively for calibration.

How Agents Use It

The Tool Interface

Discovery,selection, and invocation delivered to agents as one governed operation —through MCP, A2A, or direct integration

searchAndInvoke

SADAR defines a standard tool interface that delivers discovery to requesting agents through MCP, A2A, LangChain, or direct framework integration. Its primary tool, searchAndInvoke, performs bilateral discovery, applies the organization's selection logic, and invokes the chosen service — as a single governed operation.

Retrieves the requesting agent's manifest (cached where possible) and submits a search to the registry, authenticating as the agent via its isolated workload identity, with the search built from the requester's own declared requirements.
The tool runs at the agent's request and acts only with the agent's identity. Where it runs in-process, it inherits that identity directly. Where it runs as a shared service, the agent delegates a scoped, single-request authority to it — the tool acts as the agent's deputy, never obtaining the agent's signing credential, and every call remains attributed to the originating agent.
An organization-supplied resolver makes the final selection from the candidates and may neither query the registry independently nor select outside the returned set.
The requesting agent passes input with the search request, and the selected service is invoked directly by the tool.
The agent's manifest may name input- and output-validation handlers, to run before and after invocation to validate and structure data.
The resolver and validation handlers are themselves signed registry entries with content hashes — subject to the same integrity verification as any other capability. They present as tools.
Implementation patterns for the resolver and tool internals are explicitly non-normative — the spec defines the contracts, not the implementation.