# Pactuno security and access model

## Sign-in and roles

- End users sign in with an emailed one-time code; Pactuno does not create or store passwords.
- Customer Workspace and Global Admin use the same Hatchable identity system with different authorization checks.
- Every API declares its Hatchable access tier. The server must enforce Pactuno role, membership, and record scope in addition to the route gate.
- The admin UI checks the signed-in user's Global Admin entitlement; admin APIs verify that entitlement independently and apply MFA requirements before writes.
- Company Admin access is a tenant membership role assigned by Global Admin. Company Admin APIs check the role and tenant on every request; an ordinary company member cannot self-promote.
- Signup always grants Free to non-admin accounts. Only Global Admin plan updates can activate Silver, Gold, or Platinum; plan request payloads and browser state are not authorization.
- The public preview needs no identity and contains fictional static content only. The private demo route requires Hatchable email-code sign-in and creates fictional rows owned by that visitor; it never elevates their role.

## Data access

- Customer handlers scope queries to the signed-in account, company domain, workspace membership, or project membership.
- The Global Admin identity is denied customer project list/detail APIs. Project, Space, document, and analytics content remains in customer workspace routes and is governed by customer access checks.
- A client-supplied user ID, email domain, or project ID is never authorization proof.
- Tokenized Client Portal requests validate the token's project, expiry, and revocation state.
- Use parameterized SQL and return only fields needed by the view.

## Account access operations

Hatchable owns the sign-in identity table. Pactuno may be unable to permanently delete that identity. On denial, the admin flow suspends Pactuno access and preserves profile/plan records rather than partially deleting them. A suspended Pactuno account is not the same as a deleted Hatchable identity.

## Safe handling

Use fictional customers and metrics in public fixtures. Never publish account secrets, share tokens, one-time codes, private documents, or real customer data in the demo or public docs. Log only the identifiers needed to investigate a failure.

## Review checklist

For an auth change, review route access, in-handler checks, query scoping, denied-request behavior, and UI paths. Hiding a button is not authorization.