Security & Trust

How airline data is isolated, encrypted, and kept out of model training — stated as verifiable properties, not promises.

This page describes the security posture of the WestIQ platform as it runs today. We state properties we can demonstrate — several of them you can verify yourself from the outside — and we say plainly what is on the roadmap rather than claiming it early.

Tenant isolation

Each airline’s data is isolated at every layer it touches:

  • Identity, fail-closed. Your API credential is bound server-side to your airline. A credential with no mapping is rejected (403 auth.unknown_client) — never resolved to a default tenant. No request carries an airline identifier, so cross-tenant access is not expressible in the API.
  • Search, two layers. Catalog visibility is pruned to your namespace plus the shared global namespace at the store, and a non-removable tenant predicate inside the ranker enforces the same rule a second time.
  • Storage, airline-first keys. Behavioral events are stored under keys that begin with the airline ({airlineId}#{sessionId}), so no cross-tenant scan shape exists — even by accident.
  • Encryption, per-airline keys. Airline data at rest is encrypted with per-airline KMS customer-managed keys; the relational catalog store additionally enforces Postgres row-level security.

You can verify the API-visible part of this yourself: the runnable isolation demo in your partner onboarding pack searches another tenant’s title by exact name and shows it cannot appear in your results.

Your data never trains models

Platform runtime roles are denied access to training-data stores by an IAM policy wall. This is not a policy statement about intentions — the wall is verified by an access check that must come back AccessDenied for the runtime roles, and that check passes today.

Encryption

  • In transit: TLS on all connections.
  • At rest: KMS encryption, with per-airline customer-managed keys on airline data.

Fail-closed authentication

  • Bearer tokens are validated against the identity provider: issuer, lifetime, and signature — and only access tokens are accepted.
  • Endpoints deny by default: an endpoint without an explicit policy is still gated by the same requirement, and unmatched routes return 401.
  • The one anonymous endpoint (GET /healthz) reports liveness only.

PII protection at ingress

The platform is built so passenger-typed text cannot leak into storage or to model providers:

  • Search: query text is PII-scrubbed before it is parsed and before any embedding call leaves the platform.
  • Events: exactly one free-text field exists in the whole contract (the search-query signal’s text); it is scrubbed before storage. Every other field is an id, enum, or metric by design — a value shaped like personal data there causes that event to be rejected, not stored. Fields the contract does not model are dropped before storage.
  • Events are anonymous. Signals are session-scoped with no persistent identity in the current release, and stored with a bounded retention TTL (90 days in the sandbox).

Monitoring & audit

CloudTrail (API-level audit of the cloud estate), GuardDuty (threat detection), and AWS WAF (managed core rule groups plus per-IP rate limiting) run on the platform’s ingress and account. Every API request carries a correlation ID that joins it to its audit trail — quote it in any report and we can reconstruct the request’s path.

Data protection & GDPR (PoC posture)

The current sandbox is a staging environment processing synthetic data only: the catalog is a synthetic demo-airline catalog, and no passenger PII is processed. Production onboarding — real catalogs, real passenger signals — adds a data-processing agreement and a data-flow review as part of the working session that precedes it.

Subprocessors

ProviderRole
AWSCloud hosting (compute, storage, networking, KMS)
OpenAIText embeddings for semantic search
AnthropicAI query parsing and curation (Model Gateway)
LangfuseLLM observability
FernDocumentation hosting (this site)

Compliance roadmap

SOC 2 Type II is targeted on our roadmap; it is not yet held. We do not claim certifications we do not have, and we do not publish uptime or SLA figures for the PoC phase — the properties above are stated because they are in place and demonstrable today.

Responsible disclosure

Found a vulnerability? Email security@westiq.ai with reproduction steps and, if it involved an API call, the X-Correlation-Id of the request. We acknowledge reports and triage them promptly; please give us reasonable time to remediate before public disclosure.