The security model, in detail.

Architecture

The platform is a set of FastAPI services communicating over an internal network, backed by PostgreSQL, Redis, and NATS. The Next.js dashboard is a strict consumer of the same APIs an external operator would call. There is no privileged dashboard path that bypasses authorization.

Network

• All public endpoints are TLS-only. HSTS is enabled.
• Internal service-to-service traffic runs over a private network; service identity is enforced.
• Webhook delivery uses signed payloads with a per-workspace secret.

Tenant isolation

Tenancy is a core invariant. Every authenticated request is bound to a tenant ID derived from the access token. The data layer enforces tenant scoping at the query builder; endpoints cannot accidentally read across tenants because the API for fetching anything requires a tenant predicate.

• Database queries are scoped via a SQLAlchemy session bound to the request tenant.
• Background jobs inherit the tenant of the originating request.
• Analytics aggregates are computed per-tenant; the cross-tenant leak found in our second-pass audit was sealed in v0.6.0 (see changelog).

Authentication

• Passwords are hashed with Argon2id using per-user salts.
• Two-factor via TOTP (Google Authenticator, Authy, 1Password). Backup codes are issued at enrollment and must be stored by the operator.
• Session tokens are short-lived JWTs paired with rotating refresh tokens; refresh rotation invalidates the prior token.
• API keys are hashed at rest and shown to the operator exactly once at creation.

Authorization and teams

Authorization is role-based with per-member overrides. The four roles (owner, admin, operator, viewer) are ranked, and every endpoint that mutates membership enforces the rule: a non-owner actor may only assign roles strictly below their own, and may not modify a member at or above their own rank.

• The role-rank guard appears on both POST /teams/{id}/members and PATCH /teams/{id}/members/{user}. Symmetry was the bug the v0.4.0 audit fixed.
• The owner cannot be removed via the remove endpoint; ownership must be transferred first.
• Per-member permission overrides cannot grant a capability above the actor's own rank.

Encryption

• In transit: TLS 1.2 or newer everywhere. Public endpoints serve a strict TLS configuration; old protocol versions are disabled.
• At rest: Telegram sessions and other secrets are sealed with per-tenant keys derived via HKDF from a sealed master key. The master key lives in the platform's secret store, not in the application.
• Key rotation: Per-tenant keys can be rotated without re-encrypting every record by re-wrapping with the new key.

Audit logging

Every privileged action is recorded in the audit log. Entries include actor, action verb, resource type and ID, structured metadata (old and new values), IP, user-agent, and timestamp (UTC). Logs are append-only at the storage layer.

• Member invites, role changes, removals.
• Workspace creation, deletion, ownership transfer.
• Sensitive automation runs.
• API key creation and revocation.
• Billing-affecting changes.

Operational security

• Production access is limited to a small group with hardware-backed two-factor. All access is auditable.
• No member of staff can read tenant secrets in cleartext; per-tenant key access is scoped and logged.
• Backups are encrypted, geographically separated, and integrity-checked.
• Releases are tagged and signed; the rollout pipeline supports immediate rollback.
• Dependencies are scanned continuously; high-severity advisories are patched within 7 days, criticals within 24 hours.

Abuse handling

The platform runs ban-risk scoring on automation activity and refuses to dispatch tasks that look like spam. Reports of abuse from third parties are routed through Trust and Safety; we cooperate with lawful requests but not with informal pressure to disclose.

Incident response

• An on-call engineer is paged for any user-impacting incident.
• We aim to publish a post-incident write-up on the blog for any incident affecting more than a single tenant.
• Security incidents are treated as P1 regardless of customer impact.

Responsible disclosure

Scope: the Service at telegramos.app and its public APIs.
Out of scope: social engineering of staff, denial-of-service, and findings on third-party services we depend on (report those to the third party).

Compliance and questionnaires

We sign DPAs and complete reasonable security questionnaires under NDA. See the Data Processing Addendum. For SOC 2 readiness, vendor reviews, and questionnaire requests, contact the contact page.

Guarantees