Provider catalog and credential boundaries

How Trinity represents provider readiness, credential slots, fallback posture, and secret-safe setup state.

Keyboard: / focus search Cmd/Ctrl+K open command menu
Status: implemented Version: latest Review: source-backed Last scanned: 2026-06-25T00:00:00Z Review required: false

Provider catalog and credential boundaries

How Trinity represents provider readiness, credential slots, fallback posture, and secret-safe setup state.

Provider catalog role

The provider catalog is the safe public map of what Trinity can connect to. It explains provider names, required credential slots, readiness posture, fallback status, and setup state without exposing credential values.

Provider family Catalog purpose Secret boundary
Hermes Runtime endpoint, profile posture, task submission readiness Runtime key and private task context stay server-side
NVIDIA Official route readiness, model labels, fallback labels API key and private model payloads never render
Stripe Checkout/webhook/spend readiness Secret key and webhook signing secret never render
Gmail OAuth mailbox, scopes, account alias, project Gmail setting, send/draft readiness Access token, refresh token, and raw unreleased email bodies never render
Jido Policy/firewall action availability Policy internals and private quarantined content stay server-side
Tigris/S3 Artifact/document object storage posture Object body and private storage credentials stay gated

Readiness vocabulary

Status Meaning
Metadata configured Public connection metadata exists, but no secret claim is made
Secret stored Credential material exists in a vault-backed path
Test-mode verified A non-live provider smoke passed
Sandbox verified Sandbox policy and account mode are proven
Fallback-only The provider can support non-official fallback behavior only
Live verified An operator-controlled live provider smoke passed

Why this matters

Provider readiness is not the same as credential possession. Trinity shows enough information for an operator to understand what is configured, what is missing, and whether a route is official or fallback-only, while keeping secret material out of LiveView assigns, logs, docs, model context, ToolCall rows, and public proof.

Official references

System Use in Trinity Official docs
Hermes Runtime/provider setup posture Hermes providers
NVIDIA NIM Official model route readiness NIM LLM API reference
Stripe Checkout and webhook readiness Stripe webhooks
Gmail OAuth and scope readiness Gmail API scopes

Source paths

  • lib/autonomous_agency/integrations/provider_catalog.ex
  • lib/autonomous_agency/integrations/readiness.ex
  • lib/autonomous_agency/integrations/provider_credential.ex
  • lib/autonomous_agency/integrations/credential_vault.ex
  • lib/autonomous_agency/integrations/secret_store.ex
  • lib/autonomous_agency/integrations/provider_resolver.ex
Was this page useful? Source-backed feedback keeps public docs honest.