TrustGraphSDK

Security

Token handling, private key boundaries, public query behavior, and proof caveats.

Security

Token boundary

Authenticated trust graph methods require an AuthenSee bearer token. The SDK can take a string token or an async token provider:

createTrustGraphSdk({
  serverUrl,
  authToken: async () => getFreshJwt(),
});

Do not put AuthenSee JWTs in long-lived logs, analytics events, public browser bundles, or client-side state stores.

Private key boundary

Graph private keys sign edge certificates. They should be held in an HSM, WebAuthn/passkey-backed flow, secure enclave, or short-lived server process.

The SDK intentionally does not return private keys, witnesses, path edges, raw event payloads, AuthenSee JWTs, or session tokens.

Persona metadata

Graph nodes can be tagged as human or agent and may carry AuthenSee/provider persona identifiers. Prefer the least revealing stable identifier that still supports the product need. In most provider-facing surfaces, providerPersonaIdDerivative is a better default than a raw provider persona ID.

Do not put secrets, bearer tokens, private keys, recovery answers, or sensitive profile fields in metadata. Treat it as graph-visible application metadata.

Public query boundary

requestEdge, listEdges, getCurrentEpoch, queryReachability, and verifyProof do not send the configured bearer token. This keeps public graph reads from unnecessarily leaking credentials through caches, proxies, or logs.

Proof caveat

dev-reachability-v0 is an envelope integrity check, not a production zero-knowledge proof. Treat it as an integration shape until the server replaces it with the final Noir/Barretenberg proof system.

Error handling

TrustGraphSdkError carries:

  • statusCode
  • optional code
  • optional validation details

Do not expose raw validation details to end users without filtering.

On this page