paybondpaybond
Sign in

Use case

Tenant isolation that’s built in, not bolted on.

When agent commerce goes multi-tenant, isolation is the invariant that protects everything else. Paybond treats cross-tenant access as a severity-zero defect and enforces explicit tenant scope—derived from authenticated credentials—across every read, write, and export.

Start now>Platform overviewSign in to console

Isolation is an invariant, not a best effort.

Every product surface carries explicit tenant scope derived from authenticated credentials—so the guarantees don’t degrade as you scale.

  • Explicit scope everywhere

    Every mutation, export, and console view stays explicitly scoped to authenticated tenant and operator context.

  • No browser-provided tenant IDs

    Tenant identity is derived from authenticated credentials, not arbitrary client parameters—reducing confused-deputy risk.

  • Isolation across product surfaces

    Harbor settlement, ledger provenance, Signal rollups, and Kit sessions share the same tenant scoping discipline.

  • Audit-friendly by design

    Append-only signed provenance and attributable operator actions make isolation failures easier to detect and prevent.

How tenant isolation is enforced

Derive tenant scope from credentials and enforce it across handlers, exports, and operator workflows.

  1. Step 1

    Derive tenant from credentials

    Authentication establishes tenant identity; the system derives scope from credentials instead of trusting user input.

  2. Step 2

    Enforce scope in every handler

    APIs and internal handlers require explicit tenant context for reads/writes, preventing implicit cross-tenant access.

  3. Step 3

    Record attributable actions

    Operator actions and evidence submissions are tied to explicit identity and recorded in signed provenance.

  4. Step 4

    Scope exports and receipts

    Compliance bundles and partner-facing receipts are generated from tenant-scoped canonical history.

  5. Step 5

    Treat violations as incidents

    Cross-tenant access is treated as severity-zero: defended at boundaries, tested, and monitored.

Isolation is a product feature.

Paybond’s operator tooling and settlement flows assume multi-tenancy from the start. The default path keeps tenant boundaries explicit so you can safely expose receipts, exports, and operational surfaces.

Guarantees

  • Tenant scope is derived from authenticated credentials at every boundary.
  • Cross-tenant access is treated as a severity-zero defect.
  • Exports and receipts are generated from tenant-scoped canonical provenance.
Sign in to console

Where it fits

Tenant boundaries matter most when workflows cross teams, tools, and external stakeholders.

  • Enterprise fleets

    Run multiple teams and workloads on shared infrastructure without cross-tenant bleed into evidence or exports.

  • Platforms and marketplaces

    Operate many buyers/sellers/operators with strict isolation in settlement, disputes, and compliance packets.

  • Regulated environments

    Keep controls and audit posture intact with explicit scoping and attributable provenance.

Tenant isolation FAQ

Questions about boundaries, auth-derived scope, and exports.

What does “severity-zero” mean?

Cross-tenant data access is treated as the highest-severity defect: it triggers incident response, blocks releases, and is defended with explicit checks throughout the stack.

Does this require a specific auth model?

No, but the invariant is consistent: tenant scope must be derived from authenticated credentials, not user-supplied identifiers. The platform docs describe the supported patterns.

How does this apply to exports and receipts?

Exports and receipts are generated from tenant-scoped canonical history. The same scoping rules apply as for console views and API reads.

How do operators stay isolated from each other?

Operator identity is explicit and attributable in provenance. Operator actions are scoped to the authenticated tenant context and recorded for auditability.