Encryption
Tegendo.AI implements comprehensive encryption to protect your data throughout its lifecycle — in transit between services, at rest in storage, and during processing by AI models.
Encryption in transit
All data transmitted to, from, and within Tegendo.AI is encrypted using TLS 1.3, the latest version of the Transport Layer Security protocol.
External connections
| Connection | Protocol | Minimum version |
|---|
| Browser to Tegendo.AI | HTTPS (TLS 1.3) | TLS 1.2 |
| Tegendo.AI to AI providers | HTTPS (TLS 1.3) | TLS 1.2 |
| API clients to Tegendo.AI | HTTPS (TLS 1.3) | TLS 1.2 |
| WebSocket (streaming) | WSS (TLS 1.3) | TLS 1.2 |
Internal connections
All service-to-service communication within the Tegendo.AI infrastructure uses mutual TLS (mTLS). This ensures that both the client and server authenticate each other, preventing man-in-the-middle attacks within the internal network.
Certificate management
- TLS certificates are issued by AWS Certificate Manager (ACM)
- Certificates are automatically rotated before expiration
- Certificate pinning is not used to avoid operational issues, but HSTS headers are enforced
Encryption at rest
All data stored by Tegendo.AI is encrypted at rest using AES-256 encryption, the industry standard for protecting sensitive data.
Database encryption
| Component | Encryption method | Key management |
|---|
| PostgreSQL (Supabase) | AES-256-GCM | AWS KMS |
| Vector store (embeddings) | AES-256 | AWS KMS |
| File storage (S3) | AES-256 (SSE-S3) | AWS KMS |
| Redis cache | AES-256 | AWS KMS |
| Audit logs | AES-256 | AWS KMS |
Key management
Encryption keys are managed through AWS Key Management Service (KMS):
- Customer master keys (CMKs) are created and stored in AWS KMS hardware security modules (HSMs)
- Keys are never exported from the HSM in plaintext
- Key access is controlled by IAM policies with least-privilege permissions
- Key usage is logged in AWS CloudTrail for audit purposes
- Automatic key rotation occurs every 365 days
Application-level encryption
In addition to infrastructure encryption, certain sensitive fields receive an extra layer of application-level encryption before being stored:
- API keys — Hashed with bcrypt before storage; the plaintext is shown once at creation and never stored
- BYOK provider keys — Encrypted with a per-organization key derived from the organization’s KMS CMK
- SCIM bearer tokens — Hashed with bcrypt
- SSO certificates — Encrypted with the organization’s KMS CMK
Encryption of AI provider communication
When Tegendo.AI sends prompts to AI providers (Anthropic, OpenAI, Google), the data flow is:
- Your browser to Tegendo.AI — Encrypted via TLS 1.3
- Tegendo.AI processing — Data is processed in memory within the secure VPC; no intermediate storage of unencrypted prompts
- Tegendo.AI to AI provider — Encrypted via TLS 1.3 using the provider’s enterprise API
- AI provider response — Streamed back over TLS 1.3
- Storage — The conversation (prompt + response) is encrypted with AES-256 and stored in the database
At no point in this flow is unencrypted conversation data written to disk outside of the encrypted database. In-memory processing occurs within isolated containers that are destroyed after each request.
File upload encryption
Uploaded files follow a dedicated encryption pipeline:
- File is received over TLS 1.3
- File is scanned for malware using ClamAV
- File is encrypted with AES-256 and stored in S3 with server-side encryption
- A unique file reference (not the file itself) is stored in the database
- When retrieved, the file is decrypted in memory and served over TLS 1.3
File processing for RAG
When files are uploaded to an agent’s knowledge base:
- The file is decrypted in memory
- Text is extracted and chunked
- Each chunk is embedded via the configured embedding model
- Embeddings are stored in the vector database (encrypted at rest)
- The original file remains encrypted in S3
BYOK encryption
When organizations use Bring Your Own Key (BYOK) to provide their own AI provider API keys:
- The API key is encrypted with a per-organization KMS key before storage
- The encrypted key is stored in the database
- At runtime, the key is decrypted in memory, used for the API call, and discarded
- The plaintext key is never logged, cached, or written to disk
See the BYOK guide for setup instructions.
Cryptographic standards
| Purpose | Algorithm | Key size |
|---|
| Data at rest | AES-256-GCM | 256-bit |
| Data in transit | TLS 1.3 (ECDHE + AES-256-GCM) | 256-bit |
| Password hashing | bcrypt | Cost factor 12 |
| API key hashing | bcrypt | Cost factor 12 |
| Key derivation | HKDF-SHA256 | 256-bit |
| Digital signatures | ECDSA P-256 | 256-bit |
