Security & operational controls.

• Access control

  GCO uses role-based access controls. What a person can see and do depends on their role, and permissions are enforced on the server, not only hidden in the interface.

  • Separate roles for operators, supervisors, management, clients and sales users
  • Passwords are stored hashed, never in plain text
  • Sessions use short-lived signed tokens in HTTP-only, same-site cookies, and can be revoked on sign-out

• Client and tenant isolation

  Each client operation is kept separate from others. Client users are pinned to their own tenant on the server regardless of what a request asks for.

  • Tenant-scoped data access across conversations, messages and escalations
  • Client users see only client-facing information, never internal operator or supervisor notes
  • Cross-tenant access is covered by automated tests

• Transport security

  The public website and the platform are served over HTTPS, and plain HTTP requests are redirected to HTTPS.

  • Certificates issued and renewed automatically
  • Cookies for signed-in sessions are marked secure in production

• Auditability

  Sensitive actions on the platform are recorded with who did them and when, so operations can be reviewed.

  • Sign-ins and failed sign-ins, assignments, escalations and administrative changes are logged
  • Audit entries are designed not to contain secrets or the text of internal notes
  • Escalations keep a full timeline: who raised it, who handled it, each status change and the resolution

• Webhook security

  Messages arriving from a client's system are verified before they are accepted.

  • Inbound webhooks are verified with HMAC-SHA256 signatures using a separate secret per integration
  • Invalid signatures are rejected and nothing is stored
  • Duplicate deliveries are detected so a message is not processed twice

• Rate limiting

  Rate limits protect the platform and public forms against abuse and brute-force attempts.

  • Sign-in attempts, public forms and authenticated write actions are rate limited
  • Public contact and application forms also use a hidden spam trap and request-size limits

• Backups

  The production database is backed up every day.

  • Each backup is integrity-checked after it is created
  • A copy is stored offsite with a separate provider, and the upload is verified
  • Failures are surfaced rather than silently ignored

• Monitoring

  The platform exposes health checks and keeps operational records so problems can be seen and investigated.

  • Health checks cover the application, database and queue layer
  • Structured application logs
  • Background jobs that repeatedly fail are retained for review rather than lost

• Operational data handling

  Operational data is handled on a need-to-know basis.

  • Server-side secrets are kept in server configuration and are not exposed to the browser
  • When AI-assisted drafting is used, conversation context is sent to a third-party AI service to produce a draft; the AI credential is held only by the background worker, and a human operator reviews every reply before it is sent

Additional security and data-handling requirements can be reviewed during onboarding.

See how this fits into daily operations on the platform page, or contact us with questions.