Security

Permissions enforced by the server, not by hidden buttons

Every staff member has a role — Owner, Manager, Head Instructor, Instructor, Assistant, Divemaster, or Pilot — and every action is checked against that role on the server. Hiding a button in the interface is never the only thing standing between a role and an action, so a staff member can't reach a function their role doesn't allow by guessing a link or calling the API directly.

• Role checks on every request, using one ranking shared by the app, the AI Copilot, and outside AI assistants
• Only an Owner can grant or change the Owner role
• Settings, staff management, and access tokens are restricted to managers

Revenue visible only to the roles you choose

Money is the most sensitive thing in most operations. A per-business setting decides which roles may see revenue, payments, and other money figures, and the same rule applies to reports, the dashboard, and anything the AI Copilot or a connected assistant is asked. Operational statistics — trips, participant numbers, utilisation — are kept separate and carry no money figures, so they can be shared with the whole team.

• One revenue-visibility rule applied across every screen and AI answer
• Money-free operational statistics for team-wide sharing

A record of who changed what

Changes made through RidgeHQ — by a person or by the AI Copilot — are written to an audit log that managers and instructors can review, filter, and open individually. When something on the schedule or a booking doesn't look right, you can see what changed and who changed it instead of asking around.

• Audit entries for changes made by staff and by the AI Copilot
• Each AI action records which AI provider and model carried it out
• Read and unread state per user, with a notification badge for new entries

AI that stays inside the same boundaries as your team

The AI Copilot works through the same functions as the rest of the app, with two separate gates on every action: the role of the person asking, and a risk level. Read-only questions run straight away; anything that changes data at medium or high risk shows you exactly what it will do and waits for your confirmation — an Owner is not exempt from confirming. Some scheduling actions can be undone within an hour. Bookings, cancellations, and refunds are high-risk actions that always require confirmation in the app and are never available to outside AI assistants at all.

• Role check and risk confirmation are independent — both must pass
• Confirmation required for every medium- and high-risk action
• Undo window of one hour on reversible scheduling actions

Outside AI assistants on revocable tokens

If you connect Claude, ChatGPT, or another assistant over MCP, it uses a personal access token you create in Settings. The token is shown once and stored only as a hash, carries a staff role no higher than Manager, can be limited further, and can be revoked at any time — its next request is refused. Requests are rate-limited, and the same confirmation step applies.

• Tokens stored hashed; the full token is shown only when it's created
• Token roles capped at Manager — never Owner
• Revocation takes effect on the very next request

Each business's data kept separate in the database

RidgeHQ is one system shared by many businesses, so separation is enforced by the database itself, not only by the application. Every business's records carry its own identifier, and row-level security in PostgreSQL means a query made on behalf of one business can't return another business's rows — even if the application code asking were wrong.

• Row-level security on business data tables, enforced in production
• Application connections use database roles that can't bypass it

Encrypted connections and controlled embedding

All traffic to RidgeHQ is served over HTTPS with TLS, with HTTP redirected to HTTPS and HSTS preload enabled. The admin app refuses to be framed by other sites, while your public booking widget can be embedded on your own website — and you can restrict that to an allow-list of your domains so it can't be framed elsewhere.

• HTTPS on every page and API call, HSTS preload
• Admin pages can't be embedded in other sites
• Per-business allow-list of websites permitted to embed your booking widget

What isn’t in place yet

RidgeHQ is an early-stage product, and we would rather tell you what’s missing than let you assume it. RidgeHQ doesn’t hold third-party security certifications such as SOC 2 or ISO 27001. If your business needs a specific control before you can adopt a new system, ask us — we’ll tell you plainly whether it exists.