Role-based access controls

Give each operator the permissions their work requires.

Relpin resolves organization membership, platform permissions, workspace access, and app-defined capabilities on the server. Internal tools can expose precise actions without treating a browser claim as authorization.

Start building Inspect the access model
data · audit PROD
Data audit append-only
  1. UPDATE assignments 26.06.2026 · 14:02:11
    allocation_percent: 40 → 55 m.alvarez@acme-inc.io
  2. INSERT time_entries 26.06.2026 · 13:47:36
    logged_hours: ∅ → 6.5 j.kim@acme-inc.io
  3. UPDATE projects 26.06.2026 · 11:20:58
    status: planned → active p.nwosu@acme-inc.io

tenant roles hold SELECT + INSERT only · captured by AFTER triggers

The access problem

A private app is not enough when every signed-in user can perform every action.

Internal tools often start with one broad admin role. As more teams use them, read access, operational decisions, schema changes, and production actions need separate boundaries that remain understandable during review.

Access boundaries

Permissions stay explicit from the organization to the app action.

Relpin combines a central platform permission catalog with workspace checks and app-owned permissions.

01

Organization-scoped roles

Membership roles are resolved against the organization before protected platform operations proceed.

02

Cataloged permissions

Platform permission keys are declared centrally and verified in the codebase, keeping protected actions reviewable instead of relying on scattered strings.

03

App-defined capabilities

Apps can declare their own permissions and enforce them against the verified session supplied at the trusted runtime boundary.

Enforcement path

Resolve scope on the server, then fail closed.

The browser can request an action. It cannot define the organization, workspace, role, or permissions that authorize it.

  1. 01

    Verify the session

    Relpin resolves the authenticated user and organization membership before protected application or platform work begins.

  2. 02

    Check platform and workspace scope

    The server evaluates the required organization permission and confirms workspace access for the requested operation.

  3. 03

    Enforce the app capability

    Published app code receives a verified session and can reject actions when the required app permission is absent.

Access evidence
Organization membership roles
Central platform permission catalog
Workspace access checks
Verified app session capabilities
Access questions

How Relpin keeps authorization boundaries reviewable.

Does Relpin trust role headers sent by the browser?

No. The dispatch boundary strips untrusted Relpin headers and stamps verified user, organization, role, permission, and environment context before app code runs.

Can an app define permissions beyond platform roles?

Yes. App-defined permissions remain owned by the app definition and can be enforced by TypeScript or Python code against the verified session.

Is this a replacement for an enterprise identity provider?

No. Relpin consumes authenticated identity and applies authorization within its organization, workspace, platform, and app boundaries. Enterprise identity integrations remain a separate concern.

Least privilege by design

Build internal actions that explain who may run them.

Keep identity, platform permissions, workspace scope, and app capabilities on one governed server-side path.

Create a Relpin account Discuss your access model
Open beta · No SLA