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

Access Control

Identity and access control

GoSmarter uses Microsoft Entra External ID for all authentication. People sign in through GoSmarter’s own identity tenant. We don’t store passwords.

How people authenticate

  • Sign in via Microsoft Entra External ID: GoSmarter’s customer identity platform
  • Supported sign-in methods: organisational Entra ID account, personal Microsoft account, or email one-time passcode
  • When people use their Entra ID, any Multi Factor Authentication (MFA) and password policies from their home tenant apply
  • Session tokens are stored in the browser’s sessionStorage (cleared when the tab closes), not in localStorage or cookies

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 access is strictly controlled through Entra ID. This ensures strong tenant isolation on every API request.

The API gateway as the authentication control point

All API traffic passes through the Zuplo API gateway before reaching GoSmarter’s backend. The gateway is the single, centralised place where authentication is enforced — the backend API accepts requests only from the gateway.

  • JWT validation at the edge: Microsoft Entra ID 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 backend without a valid internal token are unconditionally rejected with 401, regardless of any other headers present.

This architecture means that authentication logic lives in one place (the gateway), is consistently applied to every request, and the backend cannot be bypassed or called directly from outside the platform.

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 Entra ID 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 Microsoft Entra External ID. Users can sign in with an organisational Entra ID account, personal Microsoft account, or email one-time passcode.
  • MFA support: Can be enforced by you
  • Tenant isolation enforced on every request: Company GUID validated against user group claims 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.