This Cybersecurity Policy describes the technical and organizational controls Vivytech has implemented to protect user data and maintain the security of the Clau platform. This policy is provided in connection with Alpaca Markets' OAuth due diligence requirements and is publicly available for transparency.
1. Data Classification
Vivytech classifies data into three tiers, each with corresponding handling requirements:
| Tier | Examples | Controls |
|---|---|---|
| Highly Sensitive | Alpaca OAuth tokens, Stripe credentials, JWT refresh tokens, passwords | Encrypted at rest (Fernet / AES-256); never logged; access restricted to backend service only |
| Sensitive | Full name, email, phone, bank balances, portfolio data, AI messages | Stored in PostgreSQL with access restricted to authenticated API calls; encrypted in transit (TLS); JWT access token required |
| Internal | Gamification points, notification preferences, AI message count, FCM tokens | Stored in PostgreSQL; authenticated API access required; not surfaced publicly |
2. Authentication and Access Control
User Authentication
- JWT-based authentication (RS256 or HS256) with short-lived access tokens and rotating refresh tokens
- Refresh tokens are single-use and rotated on each use; invalid tokens trigger immediate session clearance and require re-login
- Passwords are hashed using bcrypt (industry-standard adaptive hashing algorithm) before storage — plaintext passwords are never stored
- Failed login attempts are tracked per account; repeated failures trigger a time-based lockout
- Password reset is performed via a one-time OTP sent to the registered email address
API Access Control
- All API endpoints (except public auth endpoints) require a valid JWT access token
- Resource-level authorization: every endpoint verifies that the requesting user ID matches the resource owner (e.g., a user cannot access another user's subscription status)
- Privileged operations (admin features, dispatch endpoints) require additional secret key headers
- Rate limiting is enforced on all endpoints:
- 60 requests/minute for general read operations
- 30 requests/minute for write operations
- 10 requests/minute for sensitive operations (withdrawals, account changes)
- 5 requests/minute for high-risk endpoints
Infrastructure Access
- EC2 server access requires SSH key-based authentication — password SSH login is disabled
- The backend API is bound to localhost (127.0.0.1) and is only publicly accessible via nginx reverse proxy over HTTPS
- Database (PostgreSQL) is not publicly exposed; it is accessible only from the backend service on the same host
- Environment variables and secrets (API keys, DB credentials) are stored in a system-level configuration file (
/etc/clau/env.conf) with restricted file permissions, not in source code or version control
3. Encryption
In Transit
- All client-to-server communication is encrypted using HTTPS/TLS 1.2+ enforced at the nginx layer
- HTTP requests are redirected to HTTPS automatically; plain HTTP access is not permitted
- All third-party API calls (Stripe, Alpaca, Firebase, Google Gemini) are made over HTTPS
At Rest — Server Side
- Alpaca OAuth access tokens are encrypted using Fernet symmetric encryption (AES-128-CBC with HMAC-SHA256 for integrity) before being written to the database
- Passwords are stored as bcrypt hashes; the plaintext password is never persisted
- The Fernet encryption key is stored as an environment variable and never hardcoded
At Rest — Client Side (Android)
- JWT access and refresh tokens on the user's device are stored in Android EncryptedSharedPreferences using AES-256-GCM encryption backed by the Android Keystore
- Stripe Financial Connections session data is also stored in EncryptedSharedPreferences
- No sensitive financial data is written to plaintext local storage
4. Third-Party Vendor Security
| Vendor | Purpose | Security Posture |
|---|---|---|
| Amazon Web Services | Server infrastructure (EC2, networking) | SOC 2 Type II, ISO 27001, PCI DSS Level 1 certified. Vivytech manages OS-level security and access controls on top of AWS's shared responsibility model. |
| Stripe, Inc. | Payment processing, bank data aggregation | PCI DSS Level 1 Service Provider. Stripe handles all cardholder data; Vivytech never processes raw card numbers. |
| Alpaca Securities LLC | Brokerage / trading execution | FINRA-registered broker-dealer, SIPC member. OAuth 2.0 authorization with short-lived encrypted tokens. Tokens revocable by user at any time. |
| Google LLC (Firebase) | Push notifications | ISO 27001, SOC 2, SOC 3 certified. Only device FCM tokens are shared — no financial data. |
| Google LLC (Gemini AI) | AI inference | Enterprise API with data processing agreements available. User AI messages and financial context are transmitted over HTTPS and subject to Google's API data handling policies. |
| PostgreSQL | Primary data store | Self-managed on AWS EC2. Database not internet-exposed. Regular automated backups. |
5. Vulnerability Management
- Dependencies (Python packages, Android libraries) are tracked in version-pinned requirement files and reviewed on an ongoing basis
- Server operating system patches are applied regularly; security updates are prioritized
- Input validation is enforced on all user-supplied data at the API boundary (email format, phone format, password length, request schema validation via Pydantic)
- SQL injection is prevented by using SQLAlchemy ORM parameterized queries throughout the backend — raw SQL is not used
- API endpoints are protected against common OWASP threats including broken access control (per-resource user ID checks), excessive rate (rate limiting), and insecure storage (encrypted credentials)
- The Android app enforces ProGuard minification and resource shrinking on release builds to reduce attack surface
- Network security configuration on Android restricts cleartext HTTP traffic — all network calls must use HTTPS
6. Incident Response
Detection
- All API requests are logged with IP address, timestamp, and HTTP status code via the uvicorn/FastAPI logging stack
- Anomalous patterns (repeated 401 errors, unusual request volumes) are visible in server logs and monitored via systemd journal
- Failed login attempts are counted per account and trigger lockout thresholds
Response Plan
- Containment (0–4 hours): Identify the affected systems or accounts; revoke compromised tokens; block offending IPs at the nginx or firewall level
- Assessment (4–24 hours): Determine the scope of exposure; identify what data may have been accessed; preserve logs
- Notification (within 72 hours): Notify affected users by email; notify relevant authorities if required by applicable law; notify Alpaca Markets if their OAuth infrastructure or user tokens are involved
- Remediation: Patch the vulnerability; rotate any exposed credentials; conduct post-incident review
Data Backup and Recovery
- PostgreSQL database backups are performed regularly (daily automated snapshots)
- Backup data is stored on AWS infrastructure separate from the primary server
- Recovery procedures are tested periodically to verify backup integrity
7. Physical and Organizational Security
- Server infrastructure runs on AWS data centers with SOC 2 Type II physical security controls (badge access, surveillance, environmental controls)
- Vivytech has no on-premises server hardware; all infrastructure is cloud-based
- Access to production systems is limited to authorized personnel only
- Secrets (API keys, database passwords, encryption keys) are never committed to version control; the repository is private and managed on GitHub
- The
.gitignoreexplicitly excludeslocal.properties,.env, and other credential files
8. Contact for Security Issues
To report a security vulnerability or suspected data breach, please contact us immediately:
- Email: support@clau.app
- Subject line: SECURITY REPORT – [brief description]
- We commit to acknowledging security reports within 48 hours and providing a status update within 7 business days