Security Overview

How Users Are Verified

• •Firebase Authentication handles all user identity. SHIFT_ never stores raw passwords.
• •Every authenticated request carries a Firebase ID token — a signed JWT that expires after one hour. Every protected route verifies it cryptographically before any data is read.
• •Sign in with Apple and Google are supported natively; a native token is only accepted for the audiences Firebase knows.
• •Biometric sign-in on mobile unlocks stored credentials only after the device has confirmed the person.

Role-Based Access Control

• •Every account carries an explicit role: client, professional, organization, admin or super-admin. The role is read server-side on every request and cannot be changed from inside the app — the database rules refuse a role write from the account itself, and only a super-admin can promote an account.
• •Optional modes (professional, client, organization) are separate flags with their own gates, so a super-admin testing as a professional runs with exactly that role's tools.

Client Access Model (Invitation-Only)

Clients cannot self-register. Access comes through a professional: an invitation code or link, the professional's booking link or QR code, or a client's referral link. Invitation codes are single-use, tied to an email address, and expire.

Path 1 — Firestore Security Rules

When the web or mobile app reads the database directly, Google's servers enforce our rules; they cannot be bypassed from a browser or a device. Records are scoped to the people they belong to: a booking to its client and its professional, a message to the participants of its conversation, a review to the two parties it concerns (and to administrators), a notification to its recipient. The user list is never readable anonymously, and public directory data comes from a server-side projection that returns only what a directory needs — name, photo, sector, city — never contact details.

Path 2 — Authenticated Server Routes

Operations that need privileged access run on our servers. Every such route verifies the caller's token itself, takes the acting user from that token — never from the request body — and confirms that the caller is a party to the booking, conversation or payment before acting.

Money fields on a booking (paid, balance paid, invoiced amount) can only be written by the professional who is owed the money; a client can claim to have paid, never mark themselves paid. A completed booking cannot have its date, time or duration rewritten by anyone.

Every change to our database rules runs through an automated test suite that checks both directions: legitimate flows must keep working, and cross-user reads, privilege escalation and payment tampering must be refused. Each suite was first proven able to fail against the rules it replaced.

Transport Security

All traffic is TLS 1.2+ encrypted in transit. Firebase Hosting, Cloud Run and all API endpoints enforce HTTPS. Voice sessions use encrypted WebSocket connections.

API Authentication

Every protected request verifies the Firebase ID token before any handler runs — signature, issuer, audience and expiry against Google's public keys. A deleted account is refused even while its last token is technically valid. The acting user is always taken from the verified token, never from a user ID supplied in the request.

Notifications Identify Their Caller

The routes that send booking emails, texts and in-app alerts read the two parties from the booking record itself and log who asked: a party to the booking (by their token), an administrator, or one of our own services carrying a shared secret held in Secret Manager. Anything else is recorded and, once the rollout completes, refused.

Signed Sign-In Callbacks

Third-party connection flows (such as linking Google Calendar) carry a signed, short-lived state value, so an authorization can only complete for the account that started it.

Rate Limiting

The public Agent Connect server enforces rate limits: 500 requests per 15 minutes globally, 60 per minute per IP on tool endpoints. AI endpoints on the web platform are rate-limited across all server instances, with input-length limits.

Input Validation

The Python backend validates every request body with Pydantic. Firestore is queried through parameterised SDK calls — no raw query strings, so traditional injection attacks are structurally impossible.

CORS Restrictions

The messaging service accepts cross-origin requests only from shiftsyndicate.ca (and localhost during development). All other origins are rejected before reaching any handler.

Prompt Injection Defence

Every AI session starts with a server-side instruction the user cannot override or prepend to. Known injection patterns are caught in both chat and voice, and a persona refusal is never the only control: tool access is decided by the server, not by the model.

Role-Scoped Function Registry

The assistant can only call functions declared for the session's role. Before any function executes, the server checks the allow-list; a blocked call returns access-denied before any data query runs.

Uid-Bound Tool Dispatch

Every tool receives the authenticated user's identifier as a pre-bound parameter. Users cannot supply or override it.

Conversation Ownership

Every conversation is stored with the identities it belongs to. A mismatch returns HTTP 403 before any content is loaded.

Outside Assistants Are Read-Only

When SHIFT_ is used through an outside AI assistant (the MCP connector), every role except a verified super-admin gets a read-only toolbox: no messages, no settings changes, no outbound texts. Database questions are limited to an allow-list of analytics collections, and secrets, sessions and message bodies are redacted from every answer.

Agent Iteration Cap

The agentic loop is capped at five iterations per request, so a crafted prompt cannot drive an unbounded chain of tool calls.

Voice Session Authentication

The voice endpoint requires a valid Firebase ID token on connection and caps turns per connection. Unauthenticated connections are rejected before a session opens.

AI Credential Isolation

The AI model key exists only in Secret Manager. It is never sent to a browser or included in any response.

Public AI Restrictions

Unauthenticated visitors reach three functions only (directory search, FAQ, contact capture). They cannot read bookings, user records or financial data.

Secret & Credential Management

Production secrets (API keys, SMS credentials, Stripe keys, AI model keys, service-to-service secrets) live in Google Secret Manager and are mounted onto our services at runtime — never in source code or committed configuration. A pre-commit scanner blocks credential-shaped values from entering the repository, history is scanned for the same patterns, and any credential ever exposed is rotated at the provider.

Payment Security

SHIFT_ never handles raw payment card data. Card collection and processing are handled by Stripe, a PCI DSS Level 1 certified processor. The platform stores only Stripe customer and payment identifiers — never card numbers, security codes or bank account numbers. Tax is computed by Stripe from the professional's declared business address.

All compute runs on Google Cloud Run — fully managed, serverless containers, each instance in its own isolated sandbox. Container images are built by Cloud Build and stored in Artifact Registry, never pulled from public registries.

GCP certifications covering our infrastructure layer: SOC 1/2/3, ISO 27001, FedRAMP High, HIPAA, PCI DSS Level 1.

Project access is controlled through Google Cloud IAM; only the founding developers hold project-owner access. Services reach Firebase over Google's private network, not the public internet.

• •Cloud Run logs request metadata, error traces and application events to Google Cloud Logging with 30-day retention.
• •Firebase Authentication records sign-in, sign-out, token refresh and account changes.
• •Push-notification delivery receipts are collected and stale device tokens removed automatically.
• •Anomalous patterns (mass reads, failed-authentication spikes) surface in Cloud Monitoring.
• •Every deploy is verified against the live commit, and the public status page reports what is actually serving.
• •Security issues are triaged immediately. Affected users are notified under Canada's PIPEDA and Quebec's Law 25. Sessions can be revoked platform-wide within minutes.

Pre-Submission Security Pass (September 14, 2026)

• •Anonymous reads of every sensitive collection (users, bookings, messages, reviews, notifications, invoices, billing, device tokens, sessions, AI memory) refused — verified live.
• •Repository history scanned for credentials since the previous pass — clean; no key files tracked.
• •Service-to-service secret confirmed mounted from Secret Manager on every runtime.
• •Open dependency advisories at their floor — none with an available fix outstanding.