Encryption

Teela encrypts sensitive data at rest and in transit using industry-standard algorithms. This page documents the specific cryptographic controls, key management practices, and data exposure policies that protect credentials, metadata, and communications across the platform.

Encryption at Rest

Database Credentials

All database connection credentials stored by Teela are encrypted at rest using AES-256-GCM:

Parameter	Value
Algorithm	AES-256-GCM (Galois/Counter Mode)
Key size	256 bits
Nonce	96 bits, unique per encryption operation
Authentication tag	128 bits

AES-256-GCM provides both confidentiality and integrity. The 128-bit authentication tag ensures that any tampering with the ciphertext is detected before decryption proceeds.

Key Derivation

Encryption keys are derived using Argon2id, the recommended password-hashing and key-derivation function from the Password Hashing Competition:

Parameter	Value
Algorithm	Argon2id (hybrid of Argon2i and Argon2d)
Memory	64 MB
Iterations	3
Output	256-bit derived key

Argon2id is resistant to both side-channel attacks (via Argon2i passes) and GPU/ASIC brute-force attacks (via memory-hard computation). The 64 MB memory requirement ensures that parallel cracking attempts are prohibitively expensive.

Schema Metadata

Schema metadata (table structures, column definitions, relationships) is stored in a Qdrant vector database for natural-language query processing. This metadata is:

• Encrypted per connection using dedicated keys
• Scoped by client_id and connection_id to enforce multi-tenant isolation
• Inaccessible across connection or organization boundaries

Training Data

Training data used to improve Teela's query generation (DDL statements, example SQL queries, documentation) is:

• Encrypted per connection with connection-specific keys
• Stored separately from schema metadata
• Accessible only to users with appropriate role and connection assignments

For details on how connection-level access is enforced, see Access Control.

Encryption in Transit

TLS Configuration

All external communications are encrypted using TLS 1.2 or higher:

Control	Configuration
Minimum TLS version	1.2
Perfect forward secrecy	Enabled (ECDHE key exchange)
HTTPS enforcement	All endpoints
HSTS	Enabled
Certificate management	Azure-managed certificates with automated renewal

Perfect forward secrecy ensures that compromise of a long-term private key does not allow decryption of previously recorded traffic. Each session negotiates a unique ephemeral key.

Database Connection Encryption

Connections to customer databases are encrypted in transit:

• MySQL: SSL verification is enforced with configurable certificate options. Connections require valid server certificates.
• SQL Server: TLS encryption is enabled for all connections.
• PostgreSQL: SSL mode is enforced for all connections.

Internal Communications

• All communication between the frontend (Azure Static Web Apps) and backend (Azure App Service) traverses HTTPS.
• Backend-to-database communication (Teela's MySQL, Qdrant) uses encrypted connections.
• Third-party integrations (Sentry, Google OAuth, Intercom) communicate exclusively over HTTPS.

Key Management

Key Generation

• All cryptographic keys are generated using cryptographically secure random number generators (CSPRNGs) provided by the operating system or language runtime.
• Keys are never derived from predictable sources such as timestamps, sequential counters, or user-supplied data (except through Argon2id key derivation where applicable).

Key Storage

• Encryption keys are stored in environment variables and secure key management infrastructure on the hosting platform.
• Keys are never committed to source code repositories, written to logs, or included in API responses.
• Access to key material is restricted to the backend application service at runtime.

Key Rotation

Policy	Schedule
Routine rotation	Annual
Emergency rotation	Immediate upon suspected compromise
Rotation verification	Re-encryption of all affected data with verification
Backup	Pre-rotation backup of encrypted data

The key rotation process includes:

1. Generation of a new key using a CSPRNG.
2. Re-encryption of all data protected by the previous key.
3. Verification that all re-encrypted data decrypts correctly with the new key.
4. Secure deletion of the old key after a defined retention period.
5. Documentation of the rotation event in the audit log.

Key Recovery

• Backup copies of encryption keys are maintained in a secure, access-controlled location separate from the encrypted data.
• Key recovery procedures are documented and tested as part of the annual security review.

Approved and Prohibited Algorithms

Approved Algorithms

Purpose	Algorithm	Minimum Parameters
Symmetric encryption	AES-256-GCM	256-bit key
Key derivation	Argon2id	64 MB memory, 3 iterations
Asymmetric encryption	RSA	2048-bit key minimum
Digital signatures	ECDSA	256-bit curve minimum
Hashing	SHA-256	--
Password hashing	bcrypt	Cost factor 12+

Prohibited Algorithms

The following algorithms are prohibited for any security-relevant purpose in Teela:

Algorithm	Reason
DES / 3DES	Insufficient key length and block size
MD5	Collision vulnerabilities
SHA-1	Collision vulnerabilities
RC4	Statistical biases in output

Use of prohibited algorithms in any component is treated as a security finding and remediated immediately.

Tiered Data Exposure

Teela implements a three-tier data exposure model to control how sensitive values (particularly database credentials) are presented across different contexts:

Public View

• Audience: End users, non-administrative interfaces
• Exposure: Metadata only (connection name, database type, host). No credential values are displayed.
• Use case: Connection selection, query interface, dashboards

Admin Safe View

• Audience: Client Admins managing connections
• Exposure: Partially masked values using the format abc***xyz (first three and last three characters visible, remainder masked)
• Use case: Connection management, credential verification without full exposure

System Use Only

• Audience: Backend application service (no human-facing display)
• Exposure: Full decrypted values, used only at the moment of database connection
• Access logging: Every decryption event at this tier is logged with the requesting service context, timestamp, and connection identifier

This tiered model ensures that credentials are fully decrypted only when the system actively needs them to establish a database connection, and never displayed in plaintext to any user interface.

Certificate Management

SSL/TLS Certificates

• Web-facing certificates are managed through Azure's built-in certificate services with automated renewal.
• Certificate expiration is monitored, and renewals are initiated automatically before expiration.
• Custom domain certificates use a minimum RSA 2048-bit or ECDSA P-256 key.

Database SSL Certificates

• MySQL connections support configurable SSL certificate verification, including CA certificate pinning.
• Certificate options are stored alongside encrypted connection credentials and are scoped per connection.

For details on how encrypted data is classified and handled throughout its lifecycle, see Data Protection. For details on roles that control access to encrypted credentials, see Access Control.