Security

Every table holding business data carries the organization it belongs to, and Postgres itself enforces that a query can only reach rows for the organization making it. That check does not depend on application code remembering to filter.

It is covered by tests that attempt the crossing deliberately: one organization trying to read and write another’s data, and being refused.

Not once at sign-in, and never in the browser. Membership, role, branch scope, whether your organization owns the application, whether it is installed, whether it is switched on at that branch, and whether it is configured — all re-read on every request.

• Revoking access takes effect on the next click, not the next sign-in.
• The session token carries identity only. No permission is stored in it, so a tampered token grants nothing.
• What the interface shows is a convenience. The refusal happens on the server whether or not a screen was involved.

A person can only give away access they already have themselves. The rule runs inside the same database transaction as the change, so it cannot be skipped by a screen that forgot it and cannot be raced by two administrators editing at once.

This is what stops an administrator quietly building a role more powerful than their own.

Who did what, and when — written in the same transaction as the change itself. A change that fails and rolls back leaves no entry, and a change that succeeds cannot lose one, so the trail and the data cannot disagree.

Passwords are stored only as cryptographic hashes, by Supabase Auth. Nobody at CleverHive can read your password.

When buying becomes possible, card details will go directly to Razorpay and will never reach CleverHive’s servers.

CleverHive holds no security certifications. There is no SOC 2 report, no ISO 27001, no independent penetration test and no compliance programme. Saying otherwise on a page like this would be the most dangerous kind of untrue, because somebody might rely on it.

Two things are also worth naming honestly: leaked-password protection is available from our authentication provider and is not yet switched on, and there is no published incident-response process. Both are known and outstanding.

If you find a security problem, write to cleverhive.in@gmail.com. There is no bug bounty, and we would still rather hear from you.