Security

01How we think about it

Inkwell holds the things you can least afford to lose: your unfinished work, your clients' details, your journal. We would rather be boring and careful than clever.

No system is perfectly secure, and anyone who tells you otherwise is selling something. What we can promise is that security is a design constraint here rather than a feature we bolted on: the database refuses to hand a request rows it doesn't own, our staff cannot casually read your notebook, and we tell you the truth when something goes wrong.

The other half of taking your data seriously is letting you leave with it. You can export everything yourself, any time, without asking us.

02Encryption

• In transit — TLS 1.2 or better on every connection, including between our own services. HTTP is redirected to HTTPS.
• At rest — AES-256 on the database and on file storage.
• Journal entries — twice — the most personal thing in Inkwell gets a second, application-layer lock: entries are encrypted inside the database before they are written, with a key held in a separate vault — not in the schema, not in our application code, never in your browser. A leaked table dump would show ciphertext, not your words. The journal is also never sent to the AI assistant.
• Passwords — stored only as salted hashes, computed by our identity provider. Nobody at Inkwell can read your password, and we could not tell you what it is if you asked.
• Payment cards — never touch our servers. Our payment provider collects and stores them; we only ever see the last four digits and the card brand.

03How your data stays yours

Most breaches of multi-tenant software are not dramatic. They are one workspace quietly reading another's rows because a query forgot a WHERE clause. We defend against that in the database itself, not in application code.

Row-level security

Every table carries a Postgres row-level security policy. A query issued with your session can only ever reach rows belonging to a workspace you are a member of. If a bug in our application code forgot to filter by workspace, the database would still return nothing. The check is not something a developer can accidentally skip.

Column-level privileges on billing state

Row-level security is exactly that — row-level. It cannot stop someone from writing a column they are otherwise allowed to update. So the columns that decide what you have paid for are stripped of write privileges entirely: only our billing webhook, authenticated by a signature from our payment provider, can change your plan. A user cannot grant themselves a paid subscription, even with a valid session and a hand-crafted request.

Webhooks are authenticated, not trusted

Inbound webhooks are verified with an HMAC signature over the exact bytes received, with a timestamp check to reject replays and a constant-time comparison to resist timing attacks. An unsigned or altered payload is rejected before it reaches the database. Each event is processed exactly once.

04Who can see your notebook

By default: nobody but you and the people you invite.

• Staff access is least-privilege and off by default.
• It is granted for a specific support request, only with your permission, and it is time-boxed.
• Every privileged action is written to an audit log we cannot edit.
• We do not read your content to train models. We do not sell it. See our Privacy Policy.

Administrative accounts require multi-factor authentication. Production credentials are held in a secret store, never in source control, and are rotated when someone leaves.

05Infrastructure and backups

• Hosted on managed infrastructure in the EU and the US, with the safeguards described in international transfers.
• Backups are encrypted, taken continuously, and restore-tested — an untested backup is a rumour, not a backup.
• Dependencies are scanned automatically; security patches are applied on a schedule and out of band when severity demands.
• Deploys are immutable and can be rolled back. Nobody edits production by hand.

06When something goes wrong

We would rather tell you early and be slightly wrong than tell you late and be certain.

• If a breach affects personal data, we notify the relevant supervisory authority within 72 hours.
• Where the risk to you is high, we tell you directly, without undue delay, in plain language: what happened, what data was involved, and what we are doing about it.
• We publish a post-mortem for incidents that affected customer data.

Service availability — as opposed to security — is reported on our status page.

07Responsible disclosure

If you find a vulnerability, tell us before you tell anyone else, and we will treat you well.

What we ask

• Report it to thekodevs@gmail.com with enough detail to reproduce it.
• Give us reasonable time to fix it before publishing.
• Use only accounts you own. Do not access, modify, or delete anyone else's data.
• No denial-of-service, no social engineering of our staff or customers, no physical attacks.

What we promise

• We acknowledge within 2 business days and keep you updated until it is closed.
• We will not pursue legal action against research conducted in good faith under these rules.
• We will credit you when we ship the fix, if you would like us to.

08Your half of the job

Most account compromises are not sophisticated. A few minutes of care removes most of the risk:

• Use a long, unique password, ideally from a password manager.
• Turn on two-factor authentication in Settings → Account.
• Sign in with Google or GitHub if you already secure those accounts well.
• Remove collaborators and client portals when a project ends.
• Tell us immediately at thekodevs@gmail.com if you think someone else has access to your account.

09Contact

Security reports, questions, and requests for our security documentation: