Security & guardrails (as implemented)

This page describes what the Hakunai web platform does today. It is not a certification. Enterprise marketing summaries live under Security; prefer this page for engineering reviews.

Authentication

Customer portal: Auth.js with credentials and magic-link providers. Sessions are signed tokens backed by database session rows so revocation works before token expiry.
Admin: Separate HttpOnly cookie, HMAC-signed, short lifetime. Admin APIs re-check the current user record, suspension state, and staff allow-list on every request.
Login redirects: Open redirects to external sites are blocked on sign-in flows.

Authorization & tenancy

Organisation access comes from membership in PostgreSQL — APIs must not trust client-supplied organisation IDs.
Server-side scope checks apply across portal, Talent, Contractor, integrations, and learning routes.

Transport & browser hardening

Shared CSP, anti-framing, MIME sniffing, referrer, permissions, and HSTS headers on HTTPS responses.
Sensitive API responses use Cache-Control: private, no-store.

Input, abuse, and errors

Public and authenticated mutation routes use bounded validation and rate limits. High-risk public routes use Postgres-backed buckets that fail closed (HTTP 503) when the database is unavailable; some portal and marketplace mutations still use per-process limits until fully migrated.

Secrets & integrations

Integration tokens are encrypted at rest using a server auth secret (see .env.example).
OAuth client credentials for integrations are kept out of version control on deployed servers.

AI / runtime guardrails (portal)

Marketplace checkout and deploy stay disabled unless foundation flags are explicitly enabled — flags never grant authorization by themselves.
Portal runtime tooling enforces approval policy; human approval queues apply where configured.

Billing safety

There is no live third-party payment provider wired for agent checkout in the default configuration. Billing surfaces in the portal are backend-oriented; do not document card processing as available unless your environment enables it.

For privacy processing categories, see Privacy and data handling.

This page describes what the Hakunai web platform does today. It is not a certification. Enterprise marketing summaries live under Security; prefer this page for engineering reviews.

Authentication

Customer portal: Auth.js with credentials and magic-link providers. Sessions are signed tokens backed by database session rows so revocation works before token expiry.
Admin: Separate HttpOnly cookie, HMAC-signed, short lifetime. Admin APIs re-check the current user record, suspension state, and staff allow-list on every request.
Login redirects: Open redirects to external sites are blocked on sign-in flows.

Authorization & tenancy

Organisation access comes from membership in PostgreSQL — APIs must not trust client-supplied organisation IDs.
Server-side scope checks apply across portal, Talent, Contractor, integrations, and learning routes.

Transport & browser hardening

Shared CSP, anti-framing, MIME sniffing, referrer, permissions, and HSTS headers on HTTPS responses.
Sensitive API responses use Cache-Control: private, no-store.

Input, abuse, and errors

Public and authenticated mutation routes use bounded validation and rate limits. High-risk public routes use Postgres-backed buckets that fail closed (HTTP 503) when the database is unavailable; some portal and marketplace mutations still use per-process limits until fully migrated.

Secrets & integrations

Integration tokens are encrypted at rest using a server auth secret (see .env.example).
OAuth client credentials for integrations are kept out of version control on deployed servers.

AI / runtime guardrails (portal)

Marketplace checkout and deploy stay disabled unless foundation flags are explicitly enabled — flags never grant authorization by themselves.
Portal runtime tooling enforces approval policy; human approval queues apply where configured.

Billing safety

There is no live third-party payment provider wired for agent checkout in the default configuration. Billing surfaces in the portal are backend-oriented; do not document card processing as available unless your environment enables it.

For privacy processing categories, see Privacy and data handling.