Skip to content
B BYOAg
Menu
Browse BYOAg
Implemented

Implemented 0.1 binding

Pair without putting trust in the prompt

The platform initiates pairing, its exact domain anchors discovery, the connector proves control of a new installation key, and the result is a scoped, revocable registration.

BYOAg discovery and pairing sequence A human requests a code from a platform, an agent client discovers it through a local connector, the connector redeems protected pairing material, and the platform returns a scoped registration before an engagement becomes active. OPT [platform-confirmation] ADD MY AGENT DOMAIN + CODE CONNECT TO PLATFORM START DISCOVERY GET /.WELL-KNOWN SIGNED DESCRIPTOR PROTECTED CODE REF CODE + PUBLIC KEY CONFIRM THIS AGENT? USER CONFIRMED SCOPED REGISTRATION ENGAGEMENT ACTIVE HumanACCOUNT OWNER Platform UIFIRST-PARTY Agent clientSECURE INPUT BYOAg connectorPAIRWISE KEY Connection bayPLATFORM AUTHORITY LEGEND DISCOVERY RETURN SUCCESS
Compatibility mode may expose only the one-time code; a fully conformant client keeps pairing codes, private keys, and credentials outside model context.

Step 1 · Discovery

The domain is the initial trust anchor

A brand name or search result may help someone locate a service, but it cannot establish protocol trust. The connector accepts a canonical hostname—not a URL, path, query, fragment, or embedded credential.

Connector validation

  • Exact hostname supplied by the person
  • HTTPS outside explicit loopback development
  • Fixed /.well-known/byoag.json path
  • Supported protocol version 0.1.0
  • Issuer, endpoints, and JWKS on the requested origin
  • Schema-valid document and detached EdDSA signature
  • Redirects and private-network destinations rejected 
GET https://platform.example/.well-known/byoag.json
Accept: application/json

Step 2 · Pairwise identity

A different identity for every platform

The connector generates separate Ed25519 key pairs for the agent’s platform-pairwise identity and the local installation. Another platform receives different identifiers and keys by default.

This makes cross-platform correlation an explicit user decision rather than an accidental consequence of a global agent identifier.

Step 3 · Proof of possession

A stolen bearer token is not enough

Pairing completion carries a DPoP proof signed by the installation key and bound to the HTTP method and pairing endpoint. The issued registration credential is then bound to that same key’s JWK thumbprint.

Later authenticated requests bind fresh proofs to the target URI, method, access-token hash, timestamp, and replay-protected identifier.

Human confirmation

Two advertised pairing modes

Code is consent

Successful redemption of the short-lived, single-use code completes registration. The code is bound to the platform account, issuer, expiration, intended use, and rate-limit state.

Platform confirmation

After code redemption, the platform asks its authenticated account holder to approve the presented agent. The connector polls status with a fresh proof and never resends the pairing code.

Secret handling

Compatibility is explicit about its limits

A fully conformant client collects pairing codes through protected input and keeps pairing codes, private keys, and credentials outside model context. The model sees only the operation’s public result.

The bundled connector also offers an opaque, single-use protected-code reference. If a client can only pass the code as an ordinary tool argument, it must explain that the one-time value may be model-visible before asking the person to provide it.

Fail closed

Errors remain specific without leaking unrelated accounts

discovery_not_found issuer_mismatch unsupported_version pairing_code_invalid pairing_code_expired pairing_code_replayed pairing_rate_limited confirmation_required proof_of_possession_failed

Expired, replayed, tampered, mismatched, rate-limited, or cryptographically invalid inputs stop the connection. Error responses must not reveal whether unrelated accounts, identities, or registrations exist.