Trust & Security

Platform Security at BibaMoney / Tvijo AIOS

Last updated 28 Jul 2026 · Privacy · Terms · Trading Risk

Plain-English summary: we are non-custodial by design. We never hold your funds, never ask for withdrawal access, and never store exchange secrets in plaintext. The public website is read-only. Everything below describes controls that actually exist in the running system — not aspirations.

1. Non-custodial architecture

No custody of funds. Your assets stay on your exchange account. We operate no wallets, take no deposits, and have no withdrawal capability.
Trade-only / read-only API keys. Connected exchange keys are used strictly for reading balances and placing trades you authorize. Keys with withdrawal permission are not required and should never be created for us.
We never ask for seed phrases, private keys, or card numbers. Any message asking for these is not from us.

2. Exchange key vault — encryption at rest

API keys are sealed with AES-256-GCM authenticated encryption before touching the database. A fresh random nonce is generated for every seal; tampered ciphertext fails authentication instead of decrypting to garbage.
The vault is fail-closed: if the operator encryption secret is not provisioned, key storage is disabled entirely — the system refuses to store keys rather than store them unprotected.
Secrets are never returned to the browser (only a masked hint), never rendered in HTML, and never written to logs.
Rotating the operator secret re-keys the vault.

3. Read-only public surface

The public website's request path runs against a read-only database role with no write or table-creation privileges. A compromise of a public page cannot mutate trading or account data through that path.
Application services bind to localhost only and are reachable solely through the TLS reverse proxy — no internal service ports are exposed to the internet.

4. Browser-side hardening

Content-Security-Policy on every response; inline scripts are disallowed by policy — JavaScript ships only as external files.
X-Frame-Options: DENY (no clickjacking), X-Content-Type-Options: nosniff, and a strict Referrer-Policy.
All traffic is served over HTTPS behind a CDN/WAF edge.

5. Authentication & access control

Sign-in is via OAuth (Google / Microsoft) — we never see or store your password.
Admin and operator surfaces use separate authentication and role-based access control, isolated from user-facing routes.
Live-trading access is gated behind manual operator approval per account — off by default, and it fails closed (denied) until explicitly enabled.

6. Fail-closed by default

Across the platform, safety-relevant switches default to off/deny: key storage without an encryption secret, live trading without approval, automated messaging without explicit consent, and automated AI spend without a daily budget cap all refuse to operate rather than degrade silently. Compliance-relevant records (risk consent, declared country) are kept in minimised, append-only form — see the Privacy Policy.

7. What we don't claim

No system is unhackable, and we won't pretend otherwise. We do not currently claim formal certifications (e.g. SOC 2 / ISO 27001). What we do claim is a design where the blast radius of any single failure is deliberately small: no funds to steal, no plaintext secrets to read, no write path from the public surface.

8. Responsible disclosure

Found a vulnerability? Please report it via the security contact form with steps to reproduce. Do not access other users' data or disrupt the service while testing. We acknowledge good-faith reports and will not pursue action against researchers acting in good faith within these rules.

Looking for market threat feeds (token risk checks, sanctions screening, scam alerts)? See Security Alerts.