Trust center: what is in place, and what is not.

The product is a web container, an API container, a scheduler job and one PostgreSQL database. Nothing else stores customer data

The API and scheduler run as a non-root user with a read-only root filesystem and no-new-privileges in the supplied compose file; the web container is unprivileged nginx. The container rehearsal checks each of these

On Azure Container Apps and on AWS Fargate the supplied templates do not set a read-only root filesystem (the platforms do not offer the tmpfs mount the API needs in the same way). The containers still run as a non-root user

Only the web container is reachable from outside. The API, its metrics endpoint and the database are reachable only inside the deployment's network. The rehearsal checks that no other port is published and that /metrics is not served outside

The web container limits /public/v1 per client address and for all clients together, answers CORS for listed sites only, refuses writes from other origins, and can switch the public routes off without touching the product API. 35 checks run against a live nginx

Every page carries a Content-Security-Policy (default-src 'self', no framing, no plug-ins), HSTS, nosniff, a no-referrer policy and a permissions policy

The Azure kit can place the database, Key Vault and registry behind private endpoints and give the application no public address at all (internal ingress)

The Azure kit can put Azure Front Door with a managed rule set in front of the application, and the origin then refuses requests that did not come through it. The AWS module attaches an AWS WAF web ACL

A multi-tenant service operated by Kelynto. Designed, and rehearsed on a local machine with stand-in base images. No hosted service is running

One region per deployment. A second region is used only for geo-redundant database backups when that option is on

Tested in Chromium only. Firefox, Safari, Edge and mobile widths were not tested

No assessment against WCAG and no testing with assistive technology has been done

The data contract asks for weekly aggregates by store and category. There is no field for shoppers, baskets, payments or employees

Uploaded files are size-limited, streamed to a temporary file, parsed as tabular data and never executed. A file with too many bad rows is rejected whole

Application logs are structured lines with a request id. Request bodies, sales figures, visitor messages and email addresses of leads are not logged. The web container's access log omits query strings and referrers, and the API's own access log is switched off

Every place the backend opens a network connection is listed with what is sent, the default and the setting that disables it. The list was made by reading the code, not by observing traffic

The software contains no telemetry, licence check or update check addressed to Kelynto

A tool in the API image shows, checks and switches off every outbound signal source and the external language model for a workspace, and writes the change to the audit log. Executed in the external database rehearsal

DR_OUTBOUND_SIGNALS=false forbids every weather, alert, event and road-work lookup for every workspace, whatever its settings say: no adapter is built. A workspace admin cannot change it; the settings screen shows the sources as locked and kelynto onboard-check reports it. Executed in tests with spy adapters; not observed on a network

Card-like numbers, credentials, email addresses and phone numbers are removed from assistant messages before they are stored or sent anywhere. The client address is kept only as a keyed hash that changes every day

The web app and the public routes load no third-party script and set no analytics cookie. The Content-Security-Policy allows scripts from the application's own origin only

The region is chosen at deployment. No contractual residency commitment exists for a hosted service, because none is running. In a Customer Environment the customer chooses the region

Not written yet. It is on the policy list

Kelynto holds no password and no password hash. Sign-in is by a customer's identity provider or by an emailed single-use link or code

Signature, issuer, audience and expiry are checked against the keys of the provider registered for that tenant. Only asymmetric algorithms are accepted. A token from an unregistered issuer is refused

No request header or unsigned value selects a tenant. An issuer can be registered to one tenant only

With the customer's own identity provider, MFA and conditional access are enforced there and Kelynto accepts only that provider's tokens for the workspace

A script creates the two Entra app registrations (API and single-page app), the app roles and the optional claims, and prints the values the deployment needs. Its commands are checked against the installed Azure CLI and its logic was rehearsed against a stand-in; it has not run against a real directory

Single-use, ten-minute links (256-bit token, carried in the URL fragment, redeemed by POST) and six-digit codes bound to the browser that asked, with attempts counted atomically. Off by default

Built-in sessions are rows in the database. Refresh tokens rotate on every use and reuse ends the session. Access tokens live ten minutes and are checked against the session on every request, so revoking takes effect at once

The built-in issuer signs with ES256 keys it creates, rotates every 30 days by default and stores encrypted with a key derived from a deployment secret. Production refuses to start without that secret

The refresh cookie is HttpOnly, SameSite=Strict, Secure on https and scoped to the sign-in routes. Routes that act on it accept only the application's own origin and JSON bodies

The built-in sign-in has one factor: control of the mailbox. A workspace can require single sign-on instead

After ten wrong codes for an address within seven days, messages to that address carry the link only (256-bit token), so no further code can be guessed. Wrong attempts against a request that could never succeed do not count, so the lock cannot be held by a third party. Found in review as B-4 and B-5, fixed and re-tested by execution on 3 October 2026

Written and tested with locally signed tokens. Never verified against the real providers: no app registration exists

Users are created from token claims at first sign-in, by invitation or by an admin. There is no SCIM endpoint

An operator registers a customer's provider at the command line (kelynto add-idp). There is no screen for it

Requests without credentials and refused credentials count against the caller's address. Sign-in mail is limited per address and per client and limited at the edge for all clients together. Every message the deployment sends (sign-in, the no-workspace notice, invitations, lead notifications) passes one gate that counts in the database and stops at a ceiling for 24 hours (DR_SIGNIN_MAIL_DAILY_CAP)

The operator reports in the web app are off unless addresses are listed. An operator is accepted only with a token of the shared provider whose email claim is verified by the token itself (email_verified, or xms_edov from one Entra directory). The check cannot be switched off, and the API refuses to start with operators named and a multi-directory Microsoft issuer

Four roles with fixed permission sets. Every route that reads or changes workspace data declares the permission it requires

With the customer's own provider, an app-roles claim is the source of the user's role, and removing the role there removes access on the next request

The last active admin cannot be demoted or deactivated, and the owner of a self-service workspace can be changed only by the owner

An invitation is for one address and one role, works once, expires, and can be accepted only by a session that proved control of that address

Fixed subject; the workspace's and the inviter's names appear once, framed as unverified, cleaned to plain characters and withheld when they hold an address or imitate Kelynto. Limits per inviter, per workspace and per recipient are counted in the database, invitations count against the deployment's daily mail ceiling, and under sign-up by approval a workspace invites only once approved

Only the workspace owner changes the list. It keeps the owner's and the acting admin's domains, the owner is never closed out by it, and a change that would close out current members names them and needs a confirmation. Changes and refused attempts are audited

In a workspace people sign in to by email, members join only by accepting an invitation: adding an address directly is refused. A membership a person did not create or accept is never opened for them automatically. An admin sees and can end only sessions that have that workspace open, and ending one bars it from that workspace without signing the person out elsewhere. Found in review as B-2, fixed and re-tested by execution on 3 October 2026

A visitor of a sample workspace can look through every persona, including admin, and can change nothing under the administration and organisation routes: no users, settings, invitations or sessions. Found in review as B-1 and B-3, fixed and re-tested by execution on 3 October 2026

No application role can read more than one workspace. Operator reports on leads are a separate path that never binds a tenant and is off unless operator addresses are configured

Command-line changes are audited under the container's service user, which shows that a change came from the command line, not which person made it. Who opened the shell is in the hosting platform's logs

No access review process exists. It is on the readiness list

The software gives Kelynto no account, key or network path into a customer's deployment. Any access for support is something the customer grants in its own cloud

Every ORM query from a tenant-bound session is filtered by tenant; a write for another tenant raises an error

Each tenant-owned table has FORCE ROW LEVEL SECURITY with a policy for reads and writes. A test fails when a tenant-owned table is added without one

A database transaction bound to no tenant sees zero tenant-owned rows and can insert, change or delete none

The supplied database bootstrap creates an unprivileged role without BYPASSRLS, and refuses to finish if the role could bypass row-level security. Executed against a server whose administrator is not a superuser

db_check.py reports whether the role can bypass row-level security, lists tenant tables without a forced policy and counts the rows visible without a tenant (must be zero). Post-deployment validation fails otherwise

Validation creates a synthetic tenant, loads invented data, produces a review, checks that another tenant binding cannot see it, deletes it and proves nothing is left

Accounts, sessions, sign-in requests and signing keys are visible only to statements that explicitly enter the accounts scope

The public routes open only sessions that are never bound to a tenant, and the database refuses the public tables to a tenant-bound session. The public write path can never read a lead back

By default one unprivileged role owns the tables and serves the API, so SQL injected as the application could alter a policy. A two-role layout (owner migrates, runtime role has data privileges only) is documented and exercised by the onboarding rehearsal and a test

A customer can have a deployment that serves only its tenant (DR_TENANCY_MODE=single), in its own cloud account

All tenants of a multi-tenant deployment share the database's encryption at rest. There is no per-tenant key

No third-party penetration test has been performed

The application is served over https only; HSTS is sent; plain HTTP is redirected. The single-VM rehearsal checks the redirect and the certificate path locally

The AWS load balancer uses a TLS 1.2 and 1.3 policy; Azure ingress and Front Door are set to a minimum of TLS 1.2. Post-deployment validation checks that TLS below 1.2 is refused

The templates make the database server refuse unencrypted connections. The external-database rehearsal ran the application over TLS 1.3 against a server that accepts TLS only

Database storage, backups, secrets and logs are encrypted at rest by the managed services the templates create (Azure Database for PostgreSQL, Key Vault, Log Analytics; RDS with storage_encrypted, Secrets Manager, CloudWatch Logs)

The Azure kit can encrypt the database with a key in the customer's Key Vault (postgresCmkKeyUri); the AWS module uses the customer's KMS key for the database, secrets, logs and registry when kms_key_arn is given. Neither has been deployed

Passwords and keys are generated by the deploy scripts, stored in Key Vault or Secrets Manager and injected as references. Terraform state holds no secret value: the scripts put the values, the module creates only the containers for them

Parameter files hold identifiers only; the images contain no credential. The Azure preflight reports parameter files that still hold placeholder values

Private signing keys are stored encrypted with a key derived from a deployment secret; production refuses to start without one of at least 32 characters

Sign-in links, codes, refresh tokens and invitation tokens are stored only as hashes; the six-digit code's hash is keyed and bound to its request

Database dumps are encrypted with age before upload. The backup and restore drill ran locally with a directory in place of Blob Storage

Role-based access, soft delete for 90 days, optional purge protection and optional private endpoint only

Step-by-step rotation for every secret is in the runbook. No rotation has been performed on a live deployment

A previous secret is accepted for decrypting stored signing keys only, and a command re-encrypts them under the current secret. Covered by a test; never performed on a live deployment

Sales, plan and in-stock figures are not encrypted column by column; they rely on the database's encryption at rest and on access control

In the compose and VM layouts nginx reaches the API over plain HTTP on the private container network of one machine

Uploads, runs, commentary, publishing, labels, settings, user and role changes, and identity provider changes are recorded with actor, action, entity, request id and time

A settings change records the previous and the new value of each changed field

Operator commands write audit events with the actor cli:<operating-system user>. This shows the change came from the command line; it does not identify a person

Workspace admins read their audit log in the app and at GET /api/v1/admin/audit, filtered by action

Audit events are kept for audit_retention_days (default 2555, minimum 365) and never less than the data retention

The built-in sign-in records requests, failures, lockouts, sessions and workspace creation in an account trail kept 730 days

The Azure kit sends container and database diagnostics to a Log Analytics workspace, which can be one the customer already has. The AWS module writes to CloudWatch log groups with a retention the customer sets

Audit events are ordinary rows. The application's database role could change them. There is no hash chain or write-once store

Audit events can be read through the API. There is no push to a SIEM and no scheduled export

Reads are not audited; only changes are. Request logs record the route and the request id, not the user

The Azure kit sets backup retention (parameter, default in the production file) and optional geo-redundant backup on the PostgreSQL server

The AWS module sets backup_retention_period, deletion protection and a final snapshot on the RDS instance. Statically checked only

backup.sh dumps, encrypts and uploads; restore.sh restores into a fresh database and checks it. Both ran in the local rehearsal with a directory standing in for Blob Storage

Step-by-step restore for point-in-time, lost region and the VM, and a restore drill that does not touch production

The Azure and AWS restore procedures have never been executed: no cloud deployment exists. The VM restore ran locally

The upgrade scripts record the time before migrations run, so a point-in-time restore target is known, and refuse to roll the application back across a migration that is not backward compatible without an explicit downgrade

Design targets exist; none is committed in a contract and none has been measured on a cloud deployment

Reviews and findings export as CSV and documents from the app; the labelled dataset is exportable by the customer. There is no one-step export of everything

/healthz reports the version; /readyz checks the database. Container probes and the availability test use them

Request, error, latency, rate-limit and background-run metrics by route template, plus counters for assistant outcomes, leads, notifications, sign-in requests and verifications, sign-ups, sample workspaces and mail. Not reachable from outside

34 recording and alerting rules: error budget burn, latency, unhandled exceptions, stuck runs, and the public surface (sign-in outcomes, mail, sign-up, sample workspaces, the assistant, the daily ceilings). Checked with promtool; never loaded into a running Prometheus

Availability test, 5xx, restarts, database CPU, storage and liveness, scheduler failures and silence, error logs, and eleven log alerts for the public surface. Compiled and linted; the log queries have not run against a workspace

Load balancer 5xx, unhealthy targets, database CPU, storage and connections, scheduler failures. Statically checked only

New conversations, visitor messages, leads, browser events and model calls each have a ceiling per UTC day for the whole deployment, counted in the database. A refusal is counted in dr_public_daily_cap_total{kind} and logged; the alert rules of the three kits watch it, and an operator command shows the day's counts

One script checks health, version, schema at head, the fail-closed isolation probe, sign-in discovery, the public surface's state, headers and transport, and runs a synthetic tenant that cleans up after itself. Executed locally against the compose stack with an external database (33 checks)

The built-in sign-in counts requests, verifications, sign-ups, sample workspace visits and mail by outcome, with closed label sets and no address in any label. On Azure, where nothing scrapes the counters, the alerts read log events and the web container's access log instead

No rotation exists. Alerts go to one mailbox

None

No dedicated intrusion detection. The web application firewall option and platform logs are what exists

Severity levels, first actions, containment steps for suspected exposure of data, and a communication template

A tenant can be deactivated, an identity provider disabled, a person's sessions ended, signing keys rotated and the public surface closed at the edge, each with one command or one setting

Every response carries a request id that appears in the log line and on audit events written by that request

Scripts roll the application back to the previous revision and refuse to cross a migration that is not backward compatible unless told to downgrade. Their logic was rehearsed against stand-ins for the cloud command lines, not against a cloud

No customer contract or data processing agreement exists yet, so no notification period is committed

The procedure has not been rehearsed

One person, business hours, best effort

A security.txt that names security@kelynto.com as the contact is in the site build of 3 October 2026 and is published when that build is uploaded. The policy text is written and is not on the site yet. The mailbox has to be created before the build is published

The software runs in the customer's account and Kelynto holds none of the customer's data

Each service the software can contact, what it receives and how it is switched off is listed, from a reading of every network call in the code

The event source, road-work feeds, external language model, mail and the website assistant are off until configured. Weather lookups are the exception: on by default

A register exists as a working document with the companies a hosted service would use. No company is engaged, no data processing terms are signed

No notice process and no subscription list exist

The commentary uses the template writer and the assistant is off unless a deployment and, for commentary, the workspace admin switch a provider on

The provider receives the week's facts document and nothing else

A draft with a figure or claim that is not in the facts is discarded and the template text is used

It answers from the knowledge base only and its routes cannot open a tenant session

In llm mode an answer that cites an entry it was not given, exceeds the length cap, or states a claim outside the approved entries is replaced by the approved text

In llm mode a sentence is kept only when one sentence of the retrieved entries holds most of its content words, its numbers and the same negation, and its status label and availability claims agree with the entry's status. Unbacked sentences are removed; a link or address the deployment did not approve, or a request for a password, code, payment or contact detail, discards the answer. Lexical: it compares words, not meaning

DR_ASSISTANT_MODE is unset (off) in every deployment file; llm has to be asked for, needs a provider key and cannot be combined with DR_EXTERNAL_LLM=false. Tested with a fake provider only

Each model answer's outcome (passed, trimmed, blocked, provider error) is stored with the message, with the reasons and never the discarded text, and counted in dr_assistant_guard_total{outcome}

Card-like numbers, credentials, email addresses and phone numbers are removed first; the visitor's text is wrapped as data with a per-request marker

A daily ceiling for the whole deployment, counted in the database so that every API replica shares one number and a restart does not reset it. After it the assistant answers from approved text

With Azure OpenAI as the provider, the deployment can be pointed at the customer's own Azure OpenAI resource. Not exercised against a real resource

No code path sends customer data anywhere for training, and Kelynto holds no customer data

No provider is engaged and no terms have been reviewed or signed

Settings of a sample workspace, including the external writer and the outbound signal sources, cannot be changed by its visitors. Found in review as B-3, fixed and re-tested by execution on 3 October 2026

Whatever the settings of a sample workspace say, the commentary writer returns the template writer and the signal refresh asks no source: the check is in the writer and in the adapters, before any provider or adapter is built

DR_EXTERNAL_LLM=false makes every commentary use the template writer and stops every model call for every workspace, whatever its settings say and whether or not a provider key is present. The settings screen shows the writer as locked. The website assistant cannot run in llm mode with it

The scheduler deletes each workspace's data older than its retention once a day and writes an audit event with the counts

One script deletes a tenant and every row it owns in one transaction, verifies that nothing is left and rolls back if something is. Used and checked by the synthetic tenant check

Conversations, events and leads are purged after their periods; one person's lead and conversation can be removed on request

Expired sign-in requests, ended sessions, old account events, retired keys, abandoned empty workspaces and expired sample workspaces are removed by the scheduler pass

Scripts remove a Customer Environment deployment, list what will be deleted first and require the name to be typed. Rehearsed against stand-ins for the cloud command lines

Backups cannot be edited. Deleted data remains in them until the backup retention (7 to 35 days) has passed

A person can end sessions; there is no screen to delete the account itself. An operator can disable it

The defaults above are implemented; the policy document and the agreement that commits to them are not written

Parameterised templates for subscription, resource group, region, an existing virtual network, private endpoints for PostgreSQL, Key Vault and the registry, private or public ingress, WAF, customer-managed key, managed identity, diagnostics, backups and probes. Compiled, linted and rehearsed against a stand-in; never deployed

A script checks tools, sign-in, permissions, resource providers, quotas, name availability, the parameter file and the network before anything is created

The same validation script runs on every platform: health, version, migrations at head, the fail-closed isolation probe, sign-in discovery and a synthetic tenant that cleans up. Executed locally

Migrations follow an expand and contract policy recorded in a registry; the upgrade scripts refuse an upgrade or rollback that would cross a migration that is not backward compatible without the documented steps

On Azure the containers read secrets and pull images with a managed identity; on AWS with task roles. No access key is stored

The deployment needs no licence server, no update channel and no Kelynto account. Images are built from the repository in the customer's own registry

Docker Compose with an overlay for an existing PostgreSQL server. Executed locally end to end

Two settings forbid every signal lookup (DR_OUTBOUND_SIGNALS=false) and every language model call (DR_EXTERNAL_LLM=false) for every workspace, whatever its settings say. The private Azure parameter file and the AWS example set both; the settings screen shows them as locked and the onboarding check reports them. Executed in tests; not observed on a network

A Terraform module with the same shape as the Azure kit. Checked statically only; never initialised, planned or applied

None exists. No template in this repository has been applied to a cloud

A mapping of components to services is written. No templates

No chart or manifest is supplied

None. The honest path is a script in Cloud Shell or the compiled template in the portal, with manual steps before and after

Not supported as a tested configuration. The application must reach the customer's identity provider, and building images needs package registries

The API image installs exactly the versions in a lock file (exact versions; package hashes are not checked); the web build uses the package lock

pip-audit on the lock file and npm audit on runtime packages reported no known vulnerability on 2 October 2026. A point-in-time result

A workflow audits dependencies and scans both images on pull requests and weekly. It is linted and has never run: the repository is not hosted

Dependabot is configured for all four ecosystems. Not operating until the repository is hosted

A bill of materials of the API image was produced by hand once (141 packages). It is not produced or published per release

No commitment exists. Proposed targets are in the readiness list

None performed. A scope is written

Drafted. Not published. A security.txt that names security@kelynto.com as the contact is in the site build of 3 October 2026; that mailbox has to be created before the build is published

Base images are named by tag, so a rebuild can pick up a changed image

Bicep is linted, the Terraform module is scanned with checkov (288 checks passed, 13 skipped with a written reason each) and the Dockerfiles with hadolint. Run by hand

A backend suite on PostgreSQL covers tenant isolation, sign-in, authorisation, rate limits and retention; a test fails if a tenant table lacks a forced policy

The images are built from the real Dockerfiles and the stack is exercised end to end locally, with stand-in base images on machines that cannot pull

A STRIDE threat model per component with mitigations, file references and residual risks

The public API, built-in sign-in, workspaces, invitations and sample workspaces were reviewed on 3 October 2026. Two High and four Medium findings were filed. The two High and three of the Medium ones were fixed by their owner the same day and re-tested by the reviewer by execution. The remaining Medium and three Low findings, on the assistant side, were fixed in release 2.3.0 and tested by their author; the reviewer has not re-tested those

Ruff, the TypeScript compiler and ESLint for code; shellcheck, hadolint, the Bicep linter, checkov, actionlint and zizmor for deployment code. Run by hand; results recorded

A script fails when a control marked Implemented names a file that does not exist, or when the published register differs from these pages

Workflows for tests, builds, scans and rehearsals are written and pass actionlint and zizmor. They have never run

Every third-party action in the workflows is pinned to a commit hash

The deployment workflow uses federated credentials (no stored cloud secret) and an approval gate for production. Written, never run

There is no second person and no branch protection

Not written

Images are not signed and no provenance attestation is produced

Migrations carry a compatibility record and deployments have a validation record; there is no formal change approval process