Security & Trust

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 customer-managed encryption keys; the relational catalog store additionally enforces database row-level security.

You can verify the API-visible part of this yourself: the tenancy check in your partner onboarding pack shows the airline your credential resolves to.

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: 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. Without a token, unmatched routes return 401. With a valid token, an unmatched route returns an empty 404.
• The one anonymous endpoint (GET /healthz) reports liveness only.

PII protection at ingress

Search and event inputs are protected before storage or model processing. Optional name-based gender determination has the separate, explicit disclosure below.

• 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).

Optional gender determination

During session setup, a caller may request gender: "determine" and supply firstName and lastName. By sending them, the caller asserts it is authorized to submit the names for this purpose. The names are transit-only: never stored, never logged, and never present in audit records. The name is disclosed to our AI infrastructure provider for this determination, including its safety-screening endpoint. Both the safety screen and the determination can receive the name; neither runs for a call refused before determination or a member resolved as non-adult.

The platform processes names only for a member resolved as Adult from the caller-declared ageBand. The caller is responsible for an accurate ageBand: declaring a child as adult can cause that child’s name to be processed. Child, Tween and Unknown resolutions leave gender unspecified without processing names. An uncertain or unavailable determination also leaves gender unspecified. The confidence value is not stored or returned.

These statements describe the platform’s handling and disclosure. They do not assert the provider’s retention or training policies; applicable provider terms and data-processing arrangements require separate review during onboarding.

Monitoring & audit

API-level audit logging of the cloud estate, threat detection, and a web application firewall (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 sandbox processes no real passenger data. Its catalog is a demonstration catalog that West loads for the integration, and it carries no airline’s confidential content. 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

WestIQ processes airline data through a small set of subprocessor categories, each operating under a data-processing agreement:

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.