Security & Trust
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
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.