Skip to main content
Watch Taking a Sledgehammer to Bottlenecks 🎥 as Ruth & Steph show how AI actually fixes margins.

Access Control

Identity and access control

GoSmarter uses Clerk for all authentication. People sign in through GoSmarter’s own Clerk-managed identity instance. We don’t store passwords — Clerk manages credentials on our behalf.

How people authenticate

  • Sign in via Clerk: GoSmarter’s customer identity platform
  • Supported sign-in methods: email one-time code, email/password (12-character minimum, checked against known-breached passwords), passkeys, and social sign-in via Google, Microsoft, GitHub, and LinkedIn
  • Multi-Factor Authentication (MFA) is available via an authenticator app or backup codes, and can be enabled per user. It is not currently required at sign-in or sign-up
  • Session tokens are stored in an HTTP cookie by Clerk’s client SDK (SameSite=Lax), not in browser localStorage or sessionStorage — this is a deliberate change from the prior Entra-based sessionStorage approach

How we keep data from companies separate

Every API request is scoped to a specific company. The system enforces this at multiple levels:

  1. URL-level scoping: All customer API routes include a company identifier in the URL path
  2. User membership validation: The API validates that the authenticated user has been granted access to the target company
  3. Data query enforcement: All database queries are automatically filtered by the company identifier, ensuring users can only access data belonging to their company
  4. Request rejection: If a user attempts to access a company they don’t belong to, the API rejects the request with a 403 Forbidden response

This means a user in Company A cannot access Company B’s data, even if they have a valid authentication token.

Data is logically separated by company, and every request is validated against a dedicated company-membership record in our database. This ensures strong tenant isolation on every API request.

The API gateway as the authentication control point

All customer-facing API traffic passes through the Zuplo API gateway before reaching GoSmarter’s backend. The gateway is the centralised place where user and application authentication is enforced — the customer-facing backend accepts requests only from the gateway.

  • JWT validation at the edge: Clerk session tokens are validated by the gateway using RS256 and JWKS. Invalid, expired, or malformed tokens are rejected at the edge before any application code runs.
  • API key authentication: Programmatic and integration access uses gateway-managed API keys. Keys carry embedded identity metadata (user ID, group memberships, roles) so the backend receives the same authorisation context as a browser session.
  • Signed internal headers: Once a request is authenticated, the gateway injects X-User-Id, X-Groups, and X-Roles headers, plus a shared internal token (X-Internal-Token) that proves the request came through the gateway. The backend validates the internal token on every non-exempt request and trusts only these headers — it never parses JWTs directly.
  • No direct backend access: Requests that reach the customer-facing backend without a valid internal token are unconditionally rejected with 401, regardless of any other headers present.

This architecture means that authentication logic for customer and application traffic lives in one place (the gateway), is consistently applied to every such request, and the backend cannot be bypassed or called directly from outside the platform. A small, separate set of inbound endpoints — webhook callbacks from our identity and billing sub-processors (Clerk, Stripe) — sit outside the gateway by necessity, since those providers cannot present a gateway-issued token; these are authenticated independently using each provider’s own request-signing scheme rather than gateway headers.

API key management

API keys provide programmatic access to the GoSmarter API without an OAuth login flow. They are managed entirely through the GoSmarter API developer portal.

  • Creating keys: Users log in to the developer portal at https://api-docs.gosmarter.ai and create keys from Settings → API Keys. Each key is tied to the user account that created it.
  • Permissions: Keys carry the user’s group memberships and roles at the time the key was created. If permissions change — for example, a user is added to a new company — the key must be deleted and recreated to pick up the updated permissions. Rolling a key does not refresh permissions.
  • Rotation: Keys can be rolled (replace the key value while keeping the same consumer identity) via Settings → API Keys → Roll. Update any stored key values before the old one stops working.
  • Revocation: Keys are revoked immediately by deleting them from Settings → API Keys. Deletion takes effect instantly.
  • Storage requirements: Keys must be stored in environment variables or a dedicated secrets manager (e.g. Azure Key Vault, GitHub Actions secrets). They must never appear in source code, configuration files committed to version control, or logs.
  • Compromise response: If a key is accidentally exposed, delete it immediately from the portal and create a replacement. Notify your administrator.

How our systems talk to each other securely

Within our internal systems, every component has its own unique identity that it uses to connect to other components. Every component is given explicit permissions for what it can do for each component it needs to touch. This means we apply the principle of least privilege and reduce the risk of API keys or passwords being breached and making parts of the system accessible.

For details on how managed identity is used in AI services specifically, see AI Security.

Administrative access

  • Database: Administrative access uses Microsoft Entra ID (Azure infrastructure identity — separate from Clerk, which handles customer sign-in) security groups and is restricted to authorised team members only. No database credentials are stored in code or configuration.
  • CI/CD: Deployment pipelines use short-lived identity tokens. No long-lived deployment secrets are stored.

Key points for your security team

  • No GoSmarter passwords: Authentication is handled by Clerk. Supported sign-in methods: email one-time code, password, passkeys, and social sign-in via Google, Microsoft, GitHub, and LinkedIn.
  • MFA support: Available via authenticator app or backup codes, opt-in per user, not currently required at sign-in or sign-up
  • Tenant isolation enforced on every request: Company GUID validated against a dedicated company-membership record in our database on every API call
  • Managed identity throughout: No static API keys or connection strings in application code
  • RBAC least-privilege: Each service identity has only the permissions it needs
  • Short-lived deployment tokens: No long-lived deployment secrets are stored

Request evidence

Email us, contact us online, or book a compliance call.