Security and data handling

What we do with your access, and what we do not.

Integration work means being handed keys to systems that run a business. This page says plainly how those keys are treated. It is written to be read before a project starts, not after something goes wrong.

Access

We ask for the narrowest credential that does the job: a scoped API key, a service account, or a user carrying only the permissions the integration needs. An owner or admin login is the last resort, not the default request.
Access is requested per system and per project, never as a blanket.
At handover, credentials issued for the build are rotated or revoked by you. We confirm in writing when our access is gone.

Credentials

Credentials never go into source control, a chat thread, or a shared document.
They live in the secret store of whatever runs the integration: platform environment variables, a managed secret manager, or the vault your stack already uses.
If a credential reaches us through an insecure channel, we say so and ask you to rotate it. This happens more often than people expect and is not a reason for embarrassment.

Your data

Work happens inside your systems wherever the platform allows it.
We do not take copies of production data for convenience. Where a real sample is genuinely needed to build against, we ask first, use the smallest set that works, and delete it when the build ships.
No client data is used to train, fine-tune, or evaluate any model. Not ours, not a vendor's.

In transit

Every integration endpoint is HTTPS. There is no plaintext fallback.
Webhook receivers verify signatures where the sending platform supports them, and reject unsigned traffic rather than trusting the payload because it arrived at the right URL.

Logging

Integrations log events, timings and failures, so a break is visible rather than silent. Silent failure is the single most common thing we get called in to fix.
Logs record identifiers and outcomes, not payload contents, wherever the payload would carry personal data.
Logs live in your infrastructure and belong to you.

AI systems and MCP servers

An MCP server we build exposes a specific set of tools, not general access to a database. The assistant can do the things it was given, and nothing else.
Write access is opt-in per tool. Read-only is the starting position.
Every call is logged: what was asked for, which tool answered, and when.

Handover

Every build ships with documentation covering what it does, what it touches, and how to switch it off.
You own the code and the accounts it runs on.
Nothing we build should depend on Kinobee continuing to exist. If it does, that is a defect.

Third parties

The stack is yours. We do not introduce a new service that touches your data without telling you first and explaining why it is needed.
This website uses Cal.com for scheduling and Google Fonts for typography. Nothing else, and no analytics or tracking.

If something goes wrong

There is one contact and no queue: jed@kinobee.io.
If we become aware of an incident affecting your systems or your data, you hear it from us directly and quickly, with what is known at the time and what is being done. You will not learn about it from a status page.

What this page is not

This is a small practice, not a certified vendor. There is no SOC 2 report, no ISO certification, and no compliance team behind this page.

If your procurement needs a signed data processing agreement, a completed security questionnaire, or evidence against a specific framework, raise it before the project starts. The answer will be a straight yes or no rather than a maybe, and a no costs you nothing at that stage.

Everything above describes how the work is actually done. If any of it turns out not to fit your situation, that is a conversation to have on the call, not a policy to discover afterwards.

Last reviewed 1 September 2026.