Security at Hunter

Hunter is multi-tenant, and the isolation between tenants is enforced by PostgreSQL rather than by application code being careful. Every table that holds customer data carries an organisation id and has row-level security enabled on it, with policies that resolve to one comparison: does this row’s organisation match the organisation on the current session?

The important part is where that organisation comes from. It is not a parameter, a header or a value the browser supplies. When you sign in, a Supabase access-token hook resolves your active membership and mints your organisation and role into the signed session token, and the database policies read the claim out of that token. The function that mints it can only be executed by the authentication service; it is revoked from every client-facing role. So the worst case for a compromised or malicious client is that it asks for data belonging to its own organisation, because that is the only organisation its token can name.

There is a second layer, and it exists because of the paths that cannot use your session at all. A Stripe webhook, a nightly job and a public quote link have no signed-in user, so they run with a privileged database connection that bypasses row-level security. Every one of those paths is entered through the same service functions as the rest of the app, and those functions filter by organisation explicitly regardless of which connection they are on. The duplication is the point: one mechanism protects against a query that forgot, the other protects against a context that has no session to check.

Hunter has four roles — owner, admin, office and technician — and they are checked in the service layer before a mutation runs, not by hiding a button in the interface. Reaching an office-only action by any other route hits the same refusal the screen was hiding.

Technicians are the role most worth describing, because their accounts are on phones that get lost. A technician account is read-mostly and writes only against its own work: their jobs, their chemical applications, their checklists, their timesheet. Requests for schedule or timesheet data are rewritten to their own records regardless of what was asked for, including when the request comes through the AI agent. Settings are closed to them apart from their own email signature, billing is closed entirely, and customer editing, archiving and call history are not available to them.

It is worth being precise about the layering rather than overselling it: tenant isolation is enforced in the database, and the role restrictions above are enforced in the service layer on top of it. Both run on every request, and the service layer is the only way into the data — but they are two mechanisms, not one, and a security page that blurs them is not being straight with you.

Hunter sends quotes, invoices, reports and booking pages to your customers as tokenised links: a long random string that opens exactly one record, with no account and no password. That is what makes them work — a customer standing at their front door will open an SMS link and will not create an account.

It also means the link is a bearer credential. Anyone holding it can see that record, so it deserves the same care as anything else you send a customer. Tokens are 192 bits of cryptographically random data and are scoped to both a record and a purpose, so an invoice token cannot be pointed at a quote. If a link ends up somewhere it shouldn’t, rotating it invalidates the old one immediately.

One honest detail: most portal links do not expire on a timer by default, which is the deliberate trade for a customer being able to open an invoice from an email three weeks old. Referral links are the exception and do carry an expiry.

Hunter’s agent has tools over your whole business, which makes the boundary on those tools the most consequential security control in the product. The boundary is drawn at the edge of your business: reading, analysing, drafting and preparing happen freely, and anything that reaches a customer or moves money stops and asks.

Approval means you see the artefact, not a description of it. For a message, that is the resolved recipient, the channel and the exact words, editable before you approve. The same gate sits in front of refunds, charging a card on file, issuing a credit note and committing a ledger import. Automated routines carry an explicit policy of which tools they may use, plus a dollar ceiling on money-bearing actions, and a routine that would exceed its ceiling turns into a proposal rather than acting.

On the model itself: the agent runs on Claude from Anthropic, and voice calls are carried by ElevenLabs. Both process data outside Australia, which the privacy policy discloses as an overseas transfer rather than leaving it implied. Where the providers’ own terms govern how they handle that data, we say so and point at their terms — we don’t restate a provider’s policy as though it were a control we built.

Sometimes the fastest way to fix something is to see it. Hunter’s support impersonation is built so that this is possible without anyone quietly acquiring standing access to your business.

A support person can only enter a workspace if they hold an explicit grant in a platform allowlist and carry an internal email address — the domain alone is necessary but not sufficient. The session is scoped through the same token mechanism as everything else, so every access rule that applies to a normal user applies to them; they gain no membership in your organisation and nothing persists when the session ends. It is capped at two hours so a forgotten session closes itself, a red banner is visible for the whole of it, and starting and ending it both write entries into your own activity log naming the person and the reason.

Hunter staff are also excluded from your team list and from your billable seat count, so a support visit never shows up on your invoice.

Hunter runs on Supabase (PostgreSQL, authentication and file storage) and Vercel. All traffic is served over HTTPS, and the database is a managed Postgres instance with the platform’s encryption and backups.

We will tell you the deployed hosting region in writing on request rather than asserting one on a marketing page, because the honest answer has two parts. Your operational data — customers, jobs, invoices, compliance records, documents — lives in the primary database. Separately, AI features send data to Anthropic and, for phone calls, ElevenLabs, both of which process outside Australia. Our privacy policy discloses that overseas processing under Australian Privacy Principle 8. If data residency is a procurement requirement for you, ask before you buy and we will answer it specifically.

Hunter is an early-stage product, and a security page is worth nothing if it is written to survive skimming rather than reading. So here is the list of things we are not, stated as plainly as the list of things we are.

None of these is a reason not to buy. Each is a reason to ask us where it stands before you do, and to hold us to the answer.

If you believe you have found a vulnerability in Hunter, email vish@usehunter.ai with enough detail to reproduce it. We will acknowledge you, tell you what we found, and tell you when it is fixed.

We do not run a paid bug bounty and we make no promises about payment. We do commit to not pursuing anyone who reports a genuine issue in good faith, who does not access or modify data belonging to another organisation, and who gives us a reasonable window to fix it before publishing. If you are a customer with a security question rather than a finding — a procurement questionnaire, a residency question, a question about a control on this page — the same address reaches us.