Skip to main content
Meerkat separates what model/backend you want from which credentials or account should be used. The core pieces are:
  • realms
  • auth profiles
  • backend profiles
  • bindings
  • auth_binding
This model matters because the same app/session/mob can:
  • switch providers without changing its overall structure
  • run different mob members under different tenants/accounts
  • use env-var fallback for fast paths and explicit bindings for controlled paths

​
Mental model

​
Inheritance: reads inherit, writes are strict-owner

Realms can form a parent chain ending at the reserved global realm, and credentials inherit down that chain while writes do not:
  • A child realm can resolve a binding defined in a parent or in global (read-inherit). This is what makes rkat auth login — which provisions the home-rooted global realm — usable from every workspace realm via the chain tail.
  • auth login and config writes target the realm that owns the binding (where its config section is defined). You cannot write into an inherited binding’s doc from a child; persisting a credential for a child realm whose binding is inherited is rejected with a typed error naming the owning realm (write-strict-owner).
  • A resolved binding records owning-realm provenance: its realm is the realm that defines it, not the requesting realm. So an inherited global binding used from realm team resolves and persists under global.
Store-backed credentials (ManagedStore, OAuth leases) are realm-namespaced and follow owning-realm provenance; Env, inline-secret, and command sources are realm-agnostic. See Realm inheritance for the full model.

​
What this concept owns

  • binding identity
  • credential resolution path
  • per-session / per-turn / per-member provider identity choice

​
What it does not own

  • the general model catalog (Providers)
  • session lifecycle (Sessions)
  • config write/CAS mechanics (Configuration)

​
See also