Security

Inklate’s security model rests on three mechanisms built into the product: passwordless authentication, so there is no password to steal; social tokens encrypted at rest under a swappable key; and per-organization data isolation enforced by the database itself. This page describes what the code actually does, not compliance posture.

Passwordless authentication

Inklate never asks you to create or store a password. There are two ways in:

• Continue with Google — you authenticate on Google’s screen; Inklate receives an identity assertion, never a credential.
• Email code — Inklate emails a 6-digit one-time code that you type back in to sign in.

Because no password exists, there is nothing for Inklate to store, nothing to leak in a breach, and nothing for you to reuse across sites. Signing in later with the same email — by either method — returns you to the same account. Sessions are issued and validated server-side.

Your social passwords stay with the platform

Connecting a channel sends you to that network’s own OAuth consent screen — LinkedIn, X, Instagram, or Facebook. You authorize Inklate there, on the provider’s domain. Inklate never sees, handles, or stores your social account password; it only receives the OAuth access token the provider grants.

Social tokens are encrypted at rest

The OAuth tokens Inklate holds for your channels are sealed before they touch the database. Encryption runs through a dedicated crypto layer (@inklate/vault) with no other responsibilities:

• AES-256-GCM — tokens are sealed with authenticated encryption. A tampered or wrong-key payload fails to open rather than returning corrupt data.
• Swappable key provider — the encryption key comes from an injected KMS provider seam, so the key backing it can move from a local key to a cloud KMS without changing any call site or migrating stored data.
• Versioned wire format — sealed values carry a version prefix, leaving room to rotate keys or change the format without a data migration.

The same sealed-payload format protects other stored secrets such as webhook signing keys.

Per-organization isolation, enforced by the database

Every organization’s data — channels, posts, teammates, analytics — is scoped to that organization at the Postgres layer using Row-Level Security (RLS), not only in application code.

• Isolation lives below the application. A helper pins the caller’s organization ID for the duration of each transaction, and FORCE ROW LEVEL SECURITY policies read that value to scope every query. Even a bug in a service query cannot return another organization’s rows.
• One rule for humans and agents. Dashboard requests and agent tool calls pass through the same tenancy and permission checks, so authorization can’t drift between the two surfaces.
• Role-based permissions. Roles and access-control statements govern what each member can do within an organization; only owners and admins can act on billing.

What you control

• Sign out ends your session; signing in again is a fresh Google or email-code flow.
• Disconnect a channel from Social Profiles revokes Inklate’s stored token for it.
• API keys and Organization Keys let agents act on your behalf — scope them deliberately and revoke any you no longer use. See the guide below.