Security architecture

How KesherSuite isolates tenants, protects data, and handles incidents. Last reviewed 2026-07.

This page describes the architecture and controls actually implemented in the product today, not a compliance claim. Where something is in progress rather than finished, it's labelled that way rather than implied. A SOC 2 Type I report and an external penetration test are both scheduled ahead of public launch (see "Independent assurance" below) — this page is the trust artifact that exists before those land.

Tenant isolation Live

Every deployment is one Postgres database shared by every customer (org), isolated two independent ways:

• Schema-per-org. Each org's own application tables (the records inside a customer's apps) live in that org's own dedicated Postgres schema, created and migrated independently. A query that forgets to filter by tenant can't accidentally reach another tenant's table — there isn't one to reach from inside the wrong schema.
• Row-Level Security on shared platform tables. Tables that by definition span every org (accounts, app configs, audit log, sessions) enforce Postgres Row-Level Security, keyed on the authenticated caller's own org — enforced by the database itself, not only application code.
• Both of the above sit underneath application-layer authorization checks on every request — defense in depth, never a substitute for them.
• Adversarial isolation test suites (cross-org read/write attempts, session/ticket probes, storage path isolation, cross-tenant tool/config lookups on the AI engine) run on every change and block deployment on failure.

Authentication & session security Live

• Passwords are hashed (never stored or logged in plaintext) and checked against a breach-password list at signup/change.
• Google and Microsoft sign-in (OpenID Connect) as alternatives to a password, which an organization can make mandatory for its members.
• TOTP-based two-factor authentication (self-enrolled or enforced org-wide), with one-time backup codes.
• Sessions are signed tokens with a server-side revocation record — real logout, "sign out everywhere," and immediate cutoff on password reset, role demotion, app-membership removal, or org suspension, not just client-side token deletion.
• Persistent account lockout after repeated failed logins; every authentication event (success, failure, lockout, admin override) is written to an append-only security log, kept for one year.
• Login and password-reset endpoints are rate-limited per IP and per email; CSRF double-submit tokens and standard browser security headers (HSTS, a real Content-Security-Policy, X-Frame-Options, nosniff) apply to every state-changing request.

Authorization model Live

Access is split into deliberately narrow tiers, each re-verified against the database on every request rather than trusted from a cached session claim:

• Platform operator (us) — cross-org by design, for operating the service itself; every use is audited, including a time-boxed "break glass" grant for supporting a specific customer that requires a logged reason and expires automatically.
• Org admin — full control within their own organization only.
• App owner — administrative control over one specific application, without organization-wide admin rights.
• Per-app, per-role permissions — configurable field- and record-level access for everyone else, enforced identically for interactive use, automations, and the embedded AI agent.

Data protection

• All traffic is served over TLS; plaintext HTTP is redirected. Live
• All customer data is encrypted at rest at the storage layer by the managed database and object storage this service runs on — every table, every column, every backup, with no configuration required of you. Live
• Fields a customer marks sensitive in their own app configuration get a second, application-level layer on top of that: envelope encryption with a per-organisation data key, wrapped by a key held in Google Cloud KMS that this service can use but never read. The ciphertext is what lands in the column, so a database dump or a read-only database credential yields ciphertext rather than values. Key use is logged by KMS independently of this application, and a data key wrapped under KMS is marked as such, so it cannot later be unwrapped by any other key source. Live
• What that second layer covers, stated plainly: text-shaped fields — free text, long text and structured JSON. That is where identifiers such as national insurance / social security numbers, bank details, passport and visa numbers live. It deliberately does not extend to numeric fields such as a salary or an account balance: encrypting a number makes it impossible to total, filter or report on, which would break the reports those figures exist for. Numeric data of this kind is protected by role-based field permissions, record scoping and the audit trail instead — see Access control above. Live
• Two-factor secrets are encrypted at rest before storage. Live
• Uploaded files are stored in cloud object storage behind short-lived, permission-checked signed URLs — this service never proxies file bytes, and every URL mint re-checks the caller's role and an upload size ceiling. Live
• Database credentials, webhook signing secrets, and third-party API keys are currently deployment environment variables; migration to a dedicated secrets manager with rotation schedules is in progress. In progress
• A performed (not merely planned) database point-in-time-recovery restore drill, with documented recovery time/point objectives, is scheduled ahead of public launch. Planned

Data lifecycle & customer control Live

• Self-service export of an organization's full configuration and data (every application, every record) as a portable archive.
• Irreversible hard-delete of an organization's data — every platform record tied to it and its entire database schema — carried out by our platform operators on request, confirmed by re-typing the organization's name, or automatically at the end of the lifecycle below.
• A time-based lifecycle (trial → active → past-due → grace period → automatic export → automatic deletion) that runs unattended, so an abandoned account doesn't linger indefinitely nor get deleted without warning or a recoverable export first.

Application & agent safety Live

• Every configuration change proposed by the embedded AI builder is staged and requires human approval before it takes effect on a live application — there is no path for the agent to write directly to a customer's live configuration.
• Automated actions that write data run through the same permission and validation rules as a human user, and higher-risk automated actions can require a human approval step before they execute, independent of the automation's own judgment.
• An arithmetic/formula evaluator used throughout the product runs on an allow-listed grammar (no arbitrary code execution, no attribute or object-graph access) rather than a general-purpose `eval`.
• Expensive query endpoints (formula evaluation, ad-hoc data queries, cross-entity reports) are rate-limited per organization in addition to a global result-size ceiling, so one tenant's usage can't degrade service for others.

Monitoring & incident response

• Structured, correlation-ID-tagged logging on every request, flowing into the cloud platform's centralized log analysis. Live
• Automated alerting on stalled scheduled jobs and abnormal per-organization usage spikes. Live
• Application error tracking (opt-in, pluggable). Live
• A public, real-time status page for service availability. Planned

Independent assurance

• SOC 2 Type I report. Planned — evidence collection (access reviews, change logs, authentication event trails) is already underway against controls already in production, ahead of the audit itself.
• Third-party penetration test, scheduled before public launch. Planned

Reporting a vulnerability

If you believe you've found a security issue, please report it privately rather than through a public issue tracker. We ask that you avoid accessing or modifying data that isn't your own while testing.