Security at YEAH!

Local-first by design

Eleven of the thirteen operational tools process their working data entirely in your browser, including PDF creation, CSV/JSON conversion, image processing, money calculations, dates, text, units, invoice drafts, percentages, URL inspection and QR generation. Those tool inputs are not sent to YEAH! servers.

The IP tool — special case

The "What Is My IP" tool fetches your public IP from a third-party API (api.ipify.org). This is inherent to its function — your browser cannot determine its own public IP without asking an external service. YEAH! does not persist your IP for analytics. See the IP methodology for details.

Runtime latency — special case

The Runtime Latency Test sends lightweight requests to the deployed YEAH! health function so it can measure browser-to-runtime round-trip time. It does not upload document contents or tool inputs.

No secrets in frontend code

API keys, credentials and tokens are never bundled into client-side code. The platform manages authentication and backend security.

Control-plane governance

YEAH! Utilities now runs as the native utility layer inside YEAH! OS. Control-plane health and invocation boundaries remain server-side; QR payload generation, document transforms and deterministic calculators stay local where technically possible. No service credential is exposed to browser code.

Fail-closed orchestration

The YEAH! backend exposes explicit health and allow-listed stateless invocation contracts for the native YEAH! OS runtime. External Knowledge, Business, Research and Trust modules remain fail-closed until their production origin, identity, transport, tenant context and capability verification gates pass. Public local-first utilities remain independently usable if an external module is unavailable.

Accounts, profiles and billing

Free utility pages remain public. Personal profiles, subscription state and usage records are user-scoped and protected by authenticated authorization rules. Billing mutations are server-side only. Stripe customer and subscription identifiers may be stored for reconciliation, while full payment-card data remains with the payment provider. Search engines do not receive user-specific account data.

ALTER personalization boundary

ALTER can receive an authenticated user's explicitly saved profile fields when personalization is enabled. Profile context is bounded and separated from the conversation transcript; usage metering stores aggregate counters rather than full prompt text. The profile can disable personalization without disabling the account.

Reporting a vulnerability

If you find a security issue, please report it responsibly. Contact details will be provided once the legal entity profile is configured.