Security

Tenant isolation is enforced by Postgres, not by us

Every table that holds your data carries an org_id, and every one has row-level security enabled and deny-by-default. A read is only ever satisfied if the caller is a member of that row’s organization. This is checked by the database on every query.

The distinction matters. Most products filter by a team id somewhere in application code — one missing WHEREclause and another customer’s data comes back. Here, if our application code is wrong, the database still returns nothing.

create policy hosts_select on public.hosts
  for select using (public.is_org_member(org_id));

We test it, we don’t assume it

We create two organizations, put a row in each, and read as each user. User A sees only A’s row. User B sees only B’s. An anonymous caller sees zero rows. That test runs against the real database, not a mock.

Agent keys can only write into their own organization

The ingest endpoint takes an agent key, hashes it with SHA-256, and compares in constant time. The organization is then read from the key record — never from the request body. A request that claims a different org_idis ignored, not honoured. We verified this by sending one: every row landed in the caller’s own organization, and none in the forged one.

Only a hash of each key is stored. A key is displayed once, at creation, and can never be retrieved again. Revoking one takes effect immediately.

Authentication

Email and password or a magic link, handled by Supabase Auth. Passwords are never stored by us. Sessions are httpOnly cookies, refreshed at the edge on every request.

What we have not done

We are pre-launch, and it would be dishonest to imply otherwise. We do not hold SOC 2 or ISO 27001. We have not had a third-party penetration test. The public design-partner form has basic anti-abuse controls but not yet a durable, edge-enforced rate limit. We have no bug bounty programme yet.

If you find a security problem, email security@knoxed.ai. We will reply.