Security overview, for your review.
Kelynto is early: built and tested so far on synthetic data, with nothing hosted yet. A reviewer needs three things from a vendor at this stage, and this page gives them: the short version, every known limit stated plainly, and the way to get the full review pack.
The short version
- No customers and nothing hosted yet. No retailer's data has been processed in production, so there is no operating history to report.
- No SOC 2 report, no ISO 27001 certificate, no other attestation, and no third-party penetration test.
- Sign-in is yours. OpenID Connect through your identity provider. No passwords are stored. Four roles, checked on every API route. A sign-in by emailed link and one-time code is also built, for workspaces without single sign-on; it is off unless a deployment switches it on, and a workspace can require single sign-on instead.
- Tenants are kept apart twice, in the application and with PostgreSQL row-level security that fails closed.
- Every change made through the application is audited.
- AI writing is optional and off by default. When on, the model sees only the week's aggregated facts.
- It can run inside your own Azure subscription. That path is written and has not yet been run on live infrastructure. Two deployment settings can forbid every outbound signal lookup and every language model call for every workspace.
Each of these, with its status label, is in the Trust center. Where it runs and what crosses the boundary is on the Enterprise deployment page.
What data does it handle?
Weekly totals by store and category. Kelynto does not need or store customer, shopper, payment or employee HR data.
| Data | Sensitivity |
|---|---|
| Weekly sales and plan by store and category | Confidential business data. Totals only: no transactions, baskets or SKUs required. |
| In-stock rates and promotions | Confidential business data. |
| Store list with coordinates | Low. |
| User email, display name and role | Personal data (business contact), supplied by your identity provider, or typed at sign-in where email sign-in is on. |
| Commentary, cause labels and weekly pulse answers | Confidential. |
What is not in place yet?
Stated plainly, so there are no surprises in review. Each item is a limit of the software or its deployment templates as they stand today.
- No SOC 2 report and no third-party penetration test.
- Nothing has run on live cloud infrastructure. The Azure templates compile and lint; the container stack was rehearsed on a development machine.
- Sign-in has not been exercised against a live identity provider. It was proven against a mock provider.
- Identity providers are registered by a Kelynto operator. There is no self-service screen for your admin.
- Sign-in routing shows whether an email domain is registered. It never shows whether an account exists.
- Accounts are matched by email. The email claim must come from an attribute your users cannot edit themselves. The token's subject is stored but not checked afterwards.
- Tokens from your identity provider are not checked for revocation. Each token is verified on every request, but one already issued stays usable until it expires. Keep access token lifetimes to an hour or less.
- With single sign-on, refresh tokens are held in the browser tab's session storage, like the access token. Rotation and reuse detection are settings of your identity provider.
- Email sign-in is as strong as the mailbox. Whoever can read a person's mail can sign in as them, and Kelynto adds no second factor of its own. Mail delivery was tested against a local test server only, never a real mail service.
- The email-verified claim is not checked for workspace users. On a shared provider that lets people sign up with an address they do not own, restrict who can receive the tenant claim.
- The application's database role owns its tables. It cannot bypass row-level security, but SQL running as the application could alter a policy. A stricter two-role layout has been rehearsed and is not the default in the templates yet.
- The tenant binding is a session setting. Row-level security guards against a forgotten filter. It does not contain an attacker who can already run arbitrary SQL as the application.
- The list of tenants is not under row-level security. It holds names and settings, no sales data.
- Record ids are sequential across tenants. A tenant cannot read another tenant's records, but it could estimate overall volume from its own ids.
- The audit log is not tamper-proof. The application only adds audit rows, but an administrator with direct database access could alter them.
- Read access is not audited, and command-line changes are recorded under an operating-system user, not a named person.
- Rate limits are counted per API process, not shared across replicas (the daily ceilings on the public site's stored rows are counted in the database). A refused token is counted after it has been checked. Keep volumetric protection at your ingress or web application firewall.
- A slow signing-key endpoint delays that customer's requests. Keys are fetched one provider at a time, for up to 5 seconds and at most once every 30 seconds.
- A run interrupted by a restart is not resumed. It is marked failed after a timeout and has to be started again.
- The retention purge deletes rows, not backups. Backups keep them until the backup retention has passed.
- The number check covers numbers and currency symbols only. It does not check direction words such as above or below, names, or fractions written as words.
- Currency is a label, not a conversion. Amounts are printed in the tenant's currency exactly as uploaded.
- No user provisioning through SCIM. Users come from your identity provider's role claims or are added by an admin.
- Uploaded files are not virus-scanned. They are parsed as CSV or Excel and discarded.
- Large Excel files are expensive to read. A workbook that declares an unreasonable unpacked size is refused before it is parsed, but large files should be sent as CSV.
- Feed and signing-key addresses are checked before fetching, not pinned. Egress filtering at your network is still recommended.
- No egress firewall in the Azure templates; that stays your network's control. Private endpoints for the database, the key vault and the registry exist only in the private shape of the kit, which has not been deployed. A customer-managed key can be used for the database and its backups only.
- No measured recovery times and no round-the-clock operations cover. Recovery figures are targets. Alerts are emails to a mailbox.
- The incident response plan has never been exercised.
The review pack
A written pack for security, IT and privacy teams is sent on request. It answers from the code and the deployment templates, and says "not yet" where that is the answer.
- A filled-in questionnaire in the style of CAIQ Lite and SIG Lite.
- Architecture and data flows, with diagrams.
- Subprocessors for each hosting option. None is engaged today, because nothing is deployed.
- The incident response plan, backup and restore, and recovery targets.
- A shared responsibility matrix for the managed and the customer-hosted models.
Have your own questionnaire? Send it. Where an answer is not known, we will say so in writing instead of guessing.
Questions about contract documents, data processing terms and pricing are answered under Commercial on the Answers page.
Ask for the review pack, or send a security questionnaire.
Email marc@kelynto.com Trust center Deployment models