SADAR’s security and trust model is grounded entirely in established cryptographic standards, intentionally avoiding any proprietary trust mechanisms. By relying on standards like OpenID Connect (OIDC), mutual TLS (mTLS), JSON Web Signatures (JWS), and JSON Web Encryption (JWE),SADAR ensures that autonomous agents can discover, authenticate, and interact with capabilities securely and transparently.
A defining architectural principle of this trust model is Registry Isolation. The registry operates strictly as a discovery-time component and never sits in the runtime execution or payment path. While it facilitates the initial introduction between parties, the registry never holds credentials, usage tokens, private keys, or sensitive operational data, eliminating it as a runtime bottleneck or a central point of compromise.
Here is how SADAR establishes and enforces Security andTrust across the agentic ecosystem:
The Signed Manifest as the Identity Anchor Every entity, agent, tool, and data resource is backed by a publisher-signed manifest. These manifests are digitally signed by the owning entity using JSON Web Signatures (JWS) with ES256 encryption, creating an authoritative, tamper-evident record of the capability's identity, operational constraints, and required compliance postures. The manifest includes a JWKS (JSON Web Key Set) endpoint, allowing any party to verify the signature offline and mathematically prove that the presenter controls the key that signed the manifest.
Automated Credential Handshakes via mTLS and OIDC Trust between a requesting agent and a provider service is established directly, without registry mediation. Manifests publicly advertise the OpenIDConnect (OIDC) authentication endpoints for both parties. During an interaction, the requester authenticates directly to the service using standard OIDC Client Credentials flows over mandatory mutual TLS (mTLS), guaranteeing transport-layer security and verifying the identity of both endpoints.
Verifiable Trust, Attribution, and Replay Protection Once a provider accepts a connection, it acts as a sovereign token issuer and provides a time-of-use usage token directly to the requester. This token is securely delivered using JSON Web Encryption (JWE) bound to the requester's public key. To prevent captured tokens from being misused, SADAR mandates DPoP (Demonstration of Proof of Possession) for every request. The requester generates a short-lived DPoP proof that cryptographically binds the token to the specific HTTP method, URI, and a unique nonce (JTI).
Furthermore, to maintain an unbroken chain of authority across complex, multi-agent workflows, every invocation carries a SADAR Context Token (SCT). Separate from the authentication token, the SCT carries the identity of the originating human, the specific business process ID, and the authorized operations. This ensures that any agent in the chain can verify the legitimacy and context of the request, making all actions attributable and auditable.
Controlled First-Use Authorization Because agents autonomously discover new resources, SADAR defines explicit mechanics for first-time interactions between previously unknown parties. Organizations can mandate that the first use of a highly sensitive capability (e.g., one governed by HIPAA) triggers a human review or an out-of-band verification process before automated credential exchange and provisioning are permitted. This establishes a permanent, auditable authorization record for all subsequent interactions.
Federated Trust via the Registry of Registries (RoR) For cross-organizational discovery, a central Registry of Registries (RoR) acts as the trust anchor. The RoR holds signed registry manifests and issues identity tokens that allow authorized registries to authenticate with one another via mTLS.