Security & multi-tenancy

Multi-tenancy isn't a setting in PartnerOS; it's the architecture. Role-based permissions gate every action, partner data is scoped server-side on every query, and any credential a partner brings — SMTP passwords, API keys, OAuth tokens — is encrypted at rest with AES-256-GCM and never logged.

app.partneros.com/settings/access
Settings /Access control
N
RolesMembersAudit log
Roledealscommissionspayoutsdocumentscxkeys
operator
internal · all partners
partner_admin
scoped to own org
partner_user
scoped to own org
read_only
view within org
enforced server-side on every query · external actors pinned to their org
The problem

Multi-tenant leaks are one forgotten WHERE clause away

In most systems, isolation is a filter someone remembers to add in the UI. Miss it once and one partner sees another's deals, payouts, or customers. Bolted-on RBAC and plaintext partner credentials make it worse.

How it works

The flow, end to end

01

Authenticate

A request carries an actor — user or machine — with a role, org, and account type.

02

Authorize

The route's permission guard runs before the handler; no permission, no entry.

03

Scope

The service scopes every partner query to the actor's org; operators may scope explicitly.

04

Protect

Any stored credential is encrypted; any external host must be verified to resolve.

Capabilities

What's in the box

Role-based access

Every route is guarded by a permission; the UI gates nav and actions on the same permission set.

Server-side scoping

Partner queries are scoped to the caller's org in the data layer — not trusted from the client.

Ownership assertions

Cross-tenant access throws by construction; a partner can never reach another's resource.

Encrypted BYO credentials

Partner-supplied secrets are AES-256-GCM encrypted at rest, masked on return, never logged.

Verified-domain isolation

Custom-domain resolution and CORS both require a verified host.

Isolation by construction

The safe path is the only path

Scoping and ownership checks live in shared helpers every service calls, so isolation isn't a thing you remember — it's the default. External callers are pinned to their own org; operators get explicit, audited cross-partner reach.

  • One scoping helper, called on every partner-scoped read
  • Ownership assertion throws on any cross-tenant access
  • Secrets encrypted at rest, masked on return, absent from logs
app.partneros.com/settings/access
Settings /Access control
N
RolesMembersAudit log
Roledealscommissionspayoutsdocumentscxkeys
operator
internal · all partners
partner_admin
scoped to own org
partner_user
scoped to own org
read_only
view within org
enforced server-side on every query · external actors pinned to their org
Bring your own credentials

Partner secrets that are usable in memory and opaque everywhere else

When a partner brings an SMTP password, API key, or OAuth token, PartnerOS encrypts it with AES-256-GCM at rest, decrypts it only in-process at the moment of use, masks it on every read, and keeps it out of logs entirely. The plaintext never lingers beyond the instant it's needed.

  • AES-256-GCM encryption for every stored credential
  • Masked on return; never rendered or logged in plaintext
  • Decrypted only in-process, at the moment of use
app.partneros.com/settings/access
Settings /Access control
N
RolesMembersAudit log
Roledealscommissionspayoutsdocumentscxkeys
operator
internal · all partners
partner_admin
scoped to own org
partner_user
scoped to own org
read_only
view within org
enforced server-side on every query · external actors pinned to their org
AES-256
GCM for every stored credential
0
trust placed in client-supplied scope
1
scoping helper on every partner-scoped read
100%
of routes behind a permission guard

Ready to run your partner program in one place?

Book a walkthrough and see recruitment, PRM, automation, payouts, CX, and dashboards working together — on one platform.