Security

All data stored in our PostgreSQL database is encrypted using AES-256 encryption. This includes trading data, account configurations, user credentials, and audit logs. Database backups are also encrypted before being stored.

• Database encryption — AES-256 at the storage layer via encrypted volumes
• Password storage — User passwords are hashed using bcrypt with per-user salts, never stored in plaintext
• API key storage — MT5 agent API keys are bcrypt-hashed at rest with an in-memory validation cache
• Refresh tokens — Stored as SHA-256 hashes, not raw tokens

Archomata uses a dual authentication system. User sessions are managed through JWT tokens, while MT5 bridge agents authenticate using API keys. These are separate systems with distinct security properties.

• JWT access tokens — Short-lived (15 minutes), signed with HS256, containing user ID, org ID, and platform role
• Refresh tokens — httpOnly cookies with 7-day expiry, rotated on each use to detect token theft
• SSO integration — Google and Azure AD via OAuth2 (authlib), with automatic provider linking when email matches an existing account
• Agent API keys — Bcrypt-hashed, transmitted via X-API-Key header over TLS
• Email verification — Required for new accounts, with time-limited verification tokens
• Password reset — Secure token-based flow with configurable expiry

Access to platform resources is controlled through a layered permission system. Users are assigned roles either directly or through groups, and permissions are resolved as the union of all assigned roles.

• Platform roles — Two levels: user and platform_administrator, controlling access to platform-wide features
• Organisation roles — member or administrator, controlling access to organisation settings and user management
• System roles — 7 predefined roles (Viewer, Trader, Strategist, Developer, Operations, Risk Manager, Administrator) with fine-grained resource:action permissions
• Group-based inheritance — Roles are assigned to groups, and users inherit permissions from all groups they belong to
• Dependency injection — FastAPI dependencies (require_write, require_org_admin, require_permission) enforce authorization at the route level

Cross-Site Request Forgery protection is implemented as middleware in the FastAPI application. This prevents attackers from tricking authenticated users into making unintended requests through malicious websites.

• Origin validation — All state-changing requests are validated against allowed origins
• Cookie security — Refresh tokens use httpOnly, Secure, and SameSite attributes to prevent client-side access and cross-site transmission
• CORS policy — Configured to allow only the frontend origin, blocking unauthorized cross-origin requests

Rate limiting protects the platform from brute-force attacks and abuse. It is applied using an in-memory sliding window algorithm on sensitive endpoints.

• Login endpoints — Rate limited to prevent credential brute-forcing, with configurable thresholds
• Bridge endpoints — Rate limited to prevent abuse from compromised agents, with separate limits from user-facing routes
• Request timeouts — Middleware enforces request timeout limits to prevent resource exhaustion
• Sliding window — Limits are tracked per-IP using a sliding window, preventing burst attacks while allowing legitimate traffic

Every significant action on the platform is recorded in a structured audit log. This provides a complete trail of who did what, when, and from where.

• Comprehensive coverage — All CRUD operations, authentication events, role changes, and administrative actions are logged
• Structured data — Each log entry includes user ID, organisation ID, action type, and a JSONB details payload
• Filterable interface — Audit logs are searchable and filterable in both the org-level and platform-level dashboards
• Immutable records — Audit log entries are append-only and cannot be modified or deleted through the application

Archomata is a multi-tenant platform where each organisation's data is logically isolated. This isolation is enforced at the database query level, ensuring that no tenant can access another tenant's data.

• Organisation-scoped queries — All data tables include an org_id foreign key, and every query filters by the authenticated user's organisation
• JWT-embedded org context — The organisation ID is embedded in the JWT token to avoid per-request lookups and prevent org spoofing
• Org switching — When a user switches organisations, a new JWT is issued with the updated org context
• Org disabling — Platform administrators can disable organisations, which immediately revokes all member sessions