Paybond is tenant-scoped. Every read, write, export, and signed artifact belongs to one tenant, and the platform derives that scope from authenticated credentials rather than from unauthenticated client input.
Core rule
Cross-tenant data access is never part of the product contract. A caller should not be able to read or modify another tenant's intents, ledger rows, standing artifacts, or operational records by guessing identifiers or replaying requests.
How tenant scope is derived
State-changing and sensitive read paths derive tenant or operator context from authenticated credentials before any persistence or outbound payment call.
Examples of authoritative scope carriers include:
- Session tokens used by the console and browser flows.
- Service-account credentials used by the SDKs and machine integrations.
- Support or audit tokens issued for a narrow operational purpose.
- Protocol proofs or delegated credentials on routes that require them.
Client-supplied identifiers in request bodies, query parameters, or URLs are hints only. They must match the authenticated context before the request is allowed to proceed.
Enforcement by surface
Harbor
- Intents, evidence, capability verification, and settlement actions all resolve against the authenticated tenant.
- Evidence and capability tokens cannot be mixed across intents or tenants.
- Idempotency keys are scoped by tenant and operation.
Gateway
- Gateway is the public access layer for sessions, service-account exchange, admin workflows, and protocol verification.
- Where a route accepts a tenant header or body field, Gateway validates it against the authenticated token rather than trusting it directly.
Signal
- Signal artifacts, portfolio views, and review surfaces remain private to the authenticated tenant.
- Signal is not a public reputation feed or cross-tenant leaderboard.
Ledger and exports
- Ledger events carry tenant context so downstream verification and exports remain scoped correctly.
- Audit bundles and signed artifacts preserve the same tenant boundary as the live system.
SDKs and integrations
- Paybond Kit binds SDK sessions to the tenant returned by the Gateway.
- Integrations should keep one session per tenant and should not share a single client across tenants.
Console and operator surfaces
- Console sessions are bound to one workspace and role set.
- Operator workflows, searches, disputes, and exports all run inside that authenticated workspace context.
Credentials and claims
| Credential | Audience | Tenant carrier |
|---|---|---|
| Session JWT (cookie or Bearer) | Browser → Gateway | tid claim. Never reused across tenants. |
| Service-account API key | Kit / service account → Gateway | Gateway resolves the tenant through authenticated principal lookup and proxies hosted Harbor mutations with internally derived upstream credentials. |
| Signal indexer ledger JWT | Signal indexer → Harbor | tid claim from PAYBOND_TENANT_ID or the assignment row, signed with EdDSA kid when configured; x-tenant-id must match. |
| Support session JWT | Audited operator → Gateway | tid claim and audited support id. Short-lived. |
| Audit export download JWT | Browser → bundle stream | tid claim, aud = paybond-audit-export-download, and bundle job_id. Not exchangeable for any other call. |
x-tenant-id header | Harbor or Gateway routes that accept it | Must match the authenticated tenant context; mismatches are rejected. |
Integration guidelines
- Open one SDK session per tenant, environment, and credential set.
- Do not derive tenant scope from request bodies, query parameters, or URL guesses alone.
- Do not reuse a Harbor client or Paybond session across tenants.
- Do not expose Harbor or Signal calls directly from browser code without the normal authenticated server boundary.
- Do not log capability tokens, signing seeds, or other tenant-sensitive material.