Skip to main content

How to offer Talon to multiple customers (multi-tenant / MSP)

If you are an MSP or ISV and want to offer Talon (or a compliance layer) to multiple customers, use tenant isolation, per-tenant tenant keys, and (optionally) multiple gateway callers per customer. This guide gives the steps; for architecture and adoption narrative see Adoption scenarios.

1. Tenant isolation​

Talon scopes evidence and costs by tenant. Each customer is a tenant. You map tenant keys to tenants so that:

  • Evidence and cost queries are scoped to the tenant.
  • One tenant cannot see or access another tenant’s data.

Tenant keys: Define one or more gateway.callers entries with tenant_key and tenant_id. Example:

gateway:
  callers:
    - name: "customer-acme-api"
      tenant_key: "key_acme"
      tenant_id: "acme"
    - name: "customer-globex-api"
      tenant_key: "key_globex"
      tenant_id: "globex"

When a request is made with Authorization: Bearer key_acme, Talon treats the tenant as acme. Tenant-scoped evidence and cost APIs return only that tenant's data.

2. Gateway: one caller per customer (or per app per customer)​

When using the LLM API gateway, define a caller per customer (or per application per customer). Each caller has its own tenant_id and can have per-caller limits.

gateway:
  callers:
    - name: "customer-acme-app1"
      tenant_key: "talon-gw-acme-abc"
      tenant_id: "acme"
      policy_overrides:
        max_daily_cost: 50.00

    - name: "customer-globex-bot"
      tenant_key: "talon-gw-globex-xyz"
      tenant_id: "globex"
      policy_overrides:
        max_daily_cost: 20.00

Customers use their own caller API key; they never see other customers’ keys or data. Costs and evidence are stored under their tenant_id.

3. Operations: data directory and exports​

  • Data directory: TALON_DATA_DIR points to the state (vault, evidence DB, etc.). You can run one Talon instance with a shared DB and rely on tenant_id in every table, or (if you need hard isolation) run separate instances or separate DBs per tenant. The default single-DB design uses tenant_id for isolation.
  • Exports and verification: To hand off evidence for one customer, export and verify scoped to that tenant. Use talon audit export (or the API) with the tenant context, or call the API with that tenant’s key so the export only includes their data. See How to export evidence for auditors.

4. Summary​

StepAction
Map keys to tenantsgateway.callers[] with tenant_key + tenant_id
Gateway callersOne or more callers per tenant with tenant_id and optional policy_overrides
ExportsUse tenant-scoped export (API with tenant key or tenant filter) for each customer

For deeper context on adoption and architecture see Adoption scenarios and Architecture: MCP proxy.

You're done​

You now have tenant isolation and (optionally) gateway callers per customer. Talon is scoping evidence and costs by tenant so each customer sees only their own data.

Next steps:

I want to…Doc
Cap cost per tenant or callerHow to cap daily spend per team or application
Export evidence for one tenantHow to export evidence for auditors
Wrap a vendor (Zendesk, Intercom) per tenantVendor integration guide
Understand the gateway pipelineWhat Talon does to your request