Authenticate as an agent
Once an agent has an identity, it proves that identity to a counterparty without any shared secret or prior arrangement. The counterparty needs only DNS and HTTPS. Three shapes fit different counterparties, depending on what the receiver expects.
Native agent-to-agent verification
Section titled “Native agent-to-agent verification”For DNSid-aware counterparties, no token changes hands at all: the receiving service verifies the agent’s identity directly against the _dnsid record using the SDK verifier. Verify other agents walks the flow, and Verify a domain shows the call in all three languages.
Signed requests
Section titled “Signed requests”To prove identity on every request, the agent signs each HTTP request with its operational key using the DNSid profile of RFC 9421 HTTP Message Signatures. The receiver reads the signer’s domain from the signature’s key identifier, verifies that domain like any counterparty would, and checks the signature against the published key. No issuer is in the loop. Sign HTTP requests shows the flow in all three languages, and the Claude Agent SDK plugin does it automatically for agents built on the Agent SDK.
Signed JWTs
Section titled “Signed JWTs”Where a counterparty expects a bearer token rather than a signed request, the SDKs’ JOSE profile mints a DNSid JWT signed with the agent’s operational key. The receiver verifies the token the same way: resolve the issuer domain’s _dnsid record, fetch its JWKS, and check the signature and claims. See the JOSE package in each SDK’s API reference.