Security
Tenant isolation, authentication, encryption, and platform security controls
The platform implements security controls at multiple layers to protect tenant data, prevent unauthorized access, and ensure safe operation.
Three-layer tenant isolation
| Layer | Mechanism | What it prevents |
|---|---|---|
| Workspace boundary | All resources (accounts, proxies, bots, billing) are scoped to a workspace ID. Every query includes a WHERE workspace_id = ? clause enforced by the data access layer. | One workspace accessing another's data via API or UI. |
| Per-account runtime | Each account runs in its own OS process with its own session file, TLS fingerprint, MTProto connection, and auth key. Processes are sandboxed with cgroups. No connection multiplexing across accounts. | An account's Telegram session being hijacked or observed by another account on the same host. |
| Per-account proxy | Each account is pinned to a single dedicated proxy. Proxy credentials are never shared across accounts. IP rotation is per-account only. | Telegram linking accounts via shared IP addresses. |
| Tenant-to-tenant rental | The times_allocated counter is checked at allocation time. Only accounts with times_allocated = 0 are rented from the pool. After release, the account row is retired. | A second tenant receiving an account previously used by a different tenant. |
| Active-session enforcement | Every 6 hours, the platform checks each rented account against Telegram's list of active sessions. Unknown sessions trigger a notification with approve/terminate options. | Unauthorized access to a rented account through other means. |
| Hidden-peer redaction | Messages from Telegram's peer ID 777000 are redacted at ingestion time for rented accounts. The redaction happens at the storage layer before the message reaches the inbox. | A rental holder reading login codes for the underlying phone number. |
Authentication
Password requirements
| Requirement | Value |
|---|---|
| Minimum length | 8 characters |
| Character mix | Must include at least one uppercase letter and one number |
| Storage | bcrypt, work factor 12 |
| Maximum attempts (login) | 10 per minute per IP |
| Lockout duration | 15 minutes after exceeding max attempts |
Two-factor authentication (TOTP)
| Setting | Value |
|---|---|
| Algorithm | TOTP (RFC 6238), SHA-1, 30-second window |
| Backup codes | 8 codes, each valid once |
| 2FA attempt limit | 10 attempts per 15 minutes per IP |
| Lockout duration | 15 minutes after exceeding max attempts |
Brute-force protection
The platform implements IP-scoped rate limiting:
| Endpoint | Limit | Window |
|---|---|---|
| POST /auth/login | 10 requests | 1 minute per IP |
| POST /auth/2fa | 10 requests | 15 minutes per IP |
| POST /auth/register | 3 requests | 10 minutes per IP |
| POST /auth/forgot-password | 5 requests | 30 minutes per email |
| POST /auth/reset-password | 5 requests | 30 minutes per token |
When a rate limit is exceeded, the platform returns HTTP 429 with a Retry-After header indicating the number of seconds to wait. After 3 consecutive rate-limit events, the IP is blocked for 60 minutes.
Encryption
| Key hierarchy | Algorithm | Rotation |
|---|---|---|
| Root key | AES-256, generated in KMS | Annually |
| Workspace key | HKDF-SHA256 derived from root key + workspace ID | Annually |
| Account key | HKDF-SHA256 derived from workspace key + account ID | Quarterly |
| Session key | Ephemeral, generated per MTProto connection | Per connection |
| Database encryption key | AES-256 | Quarterly |
| Backup encryption key | AES-256 | Quarterly |
All encryption keys are managed through the platform's KMS infrastructure. Keys are stored separately from the data they protect, and access to keys is logged and audited.
Device-fingerprint matching
The platform maintains a device fingerprint for each account based on the session metadata Telegram provides (device model, system version, app version, system language, and IP geolocation).
| Situation | Action |
|---|---|
| Fingerprint unchanged | Normal operation |
| IP geolocation changes (new country) | Email notification, optional mid-session 2FA challenge |
| Device model or system version changes | Email notification, no disruption |
| Multiple simultaneous connections from different geos | Flagged for review, accounts with above 50 health score auto-kill the new session |
| Unknown session detected in active-session scan | Notification with approve/terminate options |
SSRF protections
All outbound requests that the platform makes on your behalf (webhook calls, proxy connectivity tests, avatar fetches) are subject to SSRF protections:
- Requests to private IP ranges (
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,127.0.0.0/8,169.254.0.0/16) are blocked at the network layer. - DNS resolution is verified. If a domain resolves to a private IP, the request is blocked.
- Redirects are followed but re-verified against private IP blocks at each redirect hop.
- Webhook URLs must use HTTPS (TLS 1.2+). HTTP webhooks are refused.
- Request timeout is 10 seconds total (including redirects).
Bot webhook verification
Signed outbound callbacks are not available yet. The platform does not currently sign requests it sends to your endpoints, so do not rely on a signature header to authenticate them. If you expose an endpoint to the platform, protect it with a secret path or an allowlist instead.