How access is enforced.

Every table carries row level security, so what you can reach is decided by the database on each query rather than by which buttons we drew. Hiding a control is a courtesy. Refusing the query is the control.

On the tables where it matters we go further and grant access column by column, so a person can change the fields that are theirs to change and nothing else. A mentor can accept a request; they cannot rewrite who the request came from.

Program and organization administrators can see who is taking part, who has been matched, who is waiting, and whether conversations are happening. They cannot read:

• Messages between two members.
• Preparation notes written before a conversation.
• Meeting notes imported from Granola, shared or not.
• Answers to the questions we ask after a conversation.

This is not a setting left switched off. Those tables grant administrators nothing, so there is no configuration that would turn it on.

If you connect a calendar, or connect Granola to bring in your own notes, the token or key is stored in a table that no browser session can reach: it has row level security enabled, no policies, and no privileges granted to any signed-in role. Only our server can read it, and it is never sent to your browser or ours.

Those values rely on our hosting provider’s encryption at rest rather than a second layer of our own. We have written down how we would add one, and we would rather say that plainly than imply a stronger posture than we have. You can disconnect at any time, which deletes the stored value.

• Hosting and the database are managed by Vercel and Supabase. Data is encrypted in transit and at rest.
• Schema changes are version controlled and reviewed, and they are applied by an automated pipeline rather than by hand.
• Authentication, including password storage and reset, is handled by Supabase. We never see a password.
• Access to production systems is limited to Mentable’s founders.

Mentable is a young product with a small team, and an honest list is more useful to your reviewer than a confident one:

• No SOC 2 report, and no audit under way.
• No single sign on. Members sign in with an email address and a password.
• No customer managed encryption keys.
• No formal bug bounty. If you find something, email us and we will act on it.
• No independent penetration test yet.

If any of these would block you, tell us. It is useful to know which one comes first.