How your data is protected, and what we have not done yet.

Each of these is something in the software today, not something planned. They are the answers to the questions a vendor review actually asks.

Tenant isolation is enforced, not conventional

Every row belonging to a customer carries a company ID, and every query filters on it. That is checked mechanically rather than by review: the test suite refuses a new database read that does not scope to a tenant, so the isolation cannot quietly regress as the product grows.

Connected credentials are encrypted at rest

The access tokens for your Shopify or Amazon connection are stored with AES-256-GCM under a key held separately from the session-signing key. The two are required to differ at boot, so a single leaked secret cannot both forge logins and decrypt store credentials.

Passwords are hashed, never stored

We cannot see your password, and neither can anyone who reaches the database. Sessions are signed, HTTP-only, same-site cookies that expire on their own.

Roles limit what a person can do

Owner, manager and picker are distinct. A picker can scan and pick; they cannot change costs, export the catalogue, or invite anyone. Every privileged action checks the role on the server, not in the interface.

Everything important is written down

Stock movements, order changes, logins, invites, role changes and administrative actions are recorded in an audit trail with who did it and when. It is queryable by you, not just by us.

Abuse is rate limited

Login attempts, password resets, signups and the contact form are all rate limited, backed by shared state so the limits hold across every running instance rather than per process.

Backups are restored, not just taken

A backup nobody has restored is a guess. Ours are exercised by a drill that dumps, restores into a scratch database and compares row counts and checksums table by table — it fails loudly on any mismatch, because pg_restore exiting zero is not the test.

Your data does not train models

Requests go to a commercial AI provider that retains nothing beyond answering them and does not train on them. Most fulfilment photographs never leave at all — barcode reading, text recognition and quality scoring run on a service we host, and only a frame those cannot settle is escalated. Nothing is shared between tenants, and no model can reach your database.

The question we get asked first, and the one worth answering plainly. Every statement below is either enforced by the code or written into our agreement with the provider.

Your data is never used to train a model

Not ours, and not the provider's. We do not train, fine-tune or evaluate models on customer data, and our AI provider is under a commercial agreement that prohibits using API traffic for training.

Nothing is retained after the request

AI requests are processed and discarded. The provider does not keep the contents of a request beyond answering it, and we store the result — the extracted order lines, the matched SKU — not the conversation that produced it.

Only the request is sent, never your database

The AI sees the specific text of the task and the catalogue rows needed to complete it. It has no connection to your database, no ability to browse it, and no access to any other tenant's data.

Photographs are checked locally first, escalated rarely, and deleted after 30 days

Barcode decoding, text recognition and image-quality scoring all run on a computer-vision service hosted alongside your warehouse data — no photograph leaves for any of them, and they settle the large majority of parcels. Only a frame those cannot decide is escalated to our AI provider's vision model, which retains nothing. And whether it was escalated or not, the photograph itself is deleted 30 days after it was taken by a scheduled sweep; the evidence derived from it stays with the order.

Commercial APIs, not consumer services

Every AI feature runs against a paid commercial API under business terms. Nothing routes through a consumer chat product, where the data terms are entirely different.

AI is never the last word on your stock

Extracted orders are reviewed by a person before they become orders. Forecasts state figures this system computed rather than numbers a model invented. A wrong answer costs a correction, not a shipment.

In multi-tenant software, the failure that matters most is one customer seeing another's data. It is also the easiest to introduce: a single database query that forgets to filter by tenant, added in a hurry, reviewed by someone tired.

So we do not rely on review for it. Every tenant-owned table carries a company ID, and the test suite scans the codebase for database reads that do not scope to one — a new query that forgets it fails the build rather than shipping. The list of known exceptions is explicit and has to be justified to grow.

It is not a guarantee that we have made no mistakes. It is a guarantee that this particular mistake cannot be made quietly.

Text — a pasted order, a product name, a question — goes to our AI provider over their commercial API, under terms that prohibit training on it and retain nothing beyond answering the request. Most fulfilment photographs never leave at all: barcode reading, text recognition and quality scoring run on a service we host alongside your warehouse data, and only a frame those cannot settle is escalated to the provider's vision model. In no case is your data training data, and in no case is it shared between tenants.

Every AI feature is also an accelerator over a manual path that still works. If a model is unavailable, or you run out of credits, or you simply disagree with it, you can still receive, pick, pack and ship. Nothing critical to running a warehouse sits behind a model call — which is a security property as much as a reliability one.

Please tell us. Email support@kinetel.io, or use the contact form and pick “Security or privacy” — that routes straight through.

Include what you found, how to reproduce it, and how you would like to be credited.

What you can expect from us:

• An acknowledgement within two working days.
• An assessment, and our view of severity, within five.
• A fix or a plan for one, and we will tell you when it ships.
• Credit, if you want it.

We will not threaten or pursue anyone acting in good faith. Please give us a reasonable window to fix something before disclosing it publicly, do not access or modify data belonging to anyone else, and do not run tests that degrade the service for real warehouses.

We do not currently run a paid bug bounty. We would rather say so than imply one.

A security page that only lists strengths is not being read carefully enough. These are the things a thorough review will ask about and not find.

• No SOC 2 or ISO 27001 certification. These are meaningful audits and we have not done one. If your procurement process requires it, we are not the right vendor yet, and we would rather tell you now than during onboarding.
• No contractual uptime guarantee. We work to keep the service up and we tell you when something is wrong, but we do not publish an SLA we have not committed to measuring.
• No paid bug bounty. Reports are welcome and credited; there is no cash reward.
• Single-tenant deployment is a conversation, not a checkout. If you need your own isolated instance, that is available — ask us.

Most real-world compromises of an account like yours are not clever. They are a reused password, or a laptop someone left in a taxi.

• Give people the lowest role that lets them do their job. A picker does not need to be an owner.
• Remove people when they leave — you can do that yourself in settings, and it takes effect immediately.
• Use a unique password. We hash them, but we cannot help if the same one protects your email.
• Check the audit trail occasionally. It is there for you, not only for us.
• Treat API keys like passwords: they carry the scopes you gave them, and they can be revoked.

If there is a breach affecting your data, we will tell you what happened, what was affected, and what we have done about it — without waiting until we have a comfortable version of the story.

We will notify affected customers without undue delay and within 72 hours of becoming aware, and we will follow up with the detail once we have it. Where the law requires us to notify a regulator, we will.