Data Protection

Teela's data protection controls govern how data is classified, handled, stored, and disposed of across the platform. This page covers data classification, the customer data handling model, input validation, privacy compliance, and the application-level security controls that protect data in transit and at rest.

Data Classification

Teela classifies all data into three tiers, each with specific handling requirements:

Confidential

Data whose unauthorized disclosure would cause significant harm. This category includes:

• Database connection credentials (usernames, passwords, connection strings)
• Encryption keys and key material
• API secrets and authentication tokens
• Personally identifiable information (PII)
• Financial data

Handling requirements: Encrypted at rest with AES-256-GCM, encrypted in transit with TLS 1.2+, access restricted to authorized roles, logged access at the System Use Only tier. See Encryption for cryptographic details.

Internal

Data intended for internal use that is not classified as Confidential:

• Business plans and internal communications
• System architecture documentation
• Training data (DDL, SQL examples, documentation uploaded for query generation)
• Audit logs and monitoring data

Handling requirements: Access restricted to authenticated users with appropriate role and connection assignments. Not published externally. Encrypted in transit.

Public

Data intended for external consumption:

• Marketing materials and public website content
• Published documentation (including this site)
• Public API specifications

Handling requirements: No access restrictions. Integrity controls to prevent unauthorized modification.

Data Handling Model

Customer Data Stays in Customer Databases

Teela's fundamental data handling principle is that customer data is not copied to Teela's infrastructure. When a user runs a query:

1. Teela generates a SQL query based on the user's natural-language input and the connection's schema metadata.
2. The query is executed against the customer's database over an encrypted connection.
3. Results are returned to the user's browser.
4. Query results are not persisted on Teela's servers.

This model minimizes Teela's data footprint and ensures that customer data governance policies remain in effect at the source.

Read-Only Access

Teela connects to customer databases with read-only permissions. Teela cannot:

• Insert, update, or delete records in customer databases
• Modify schemas or database objects
• Execute stored procedures that alter data
• Grant or modify permissions in customer databases

Read-only access is enforced at the database credential level. The credentials provided by the customer should grant only SELECT permissions (or equivalent read access for the database platform).

File Upload Exception

When users connect file-based data sources (Google Sheets, Excel, CSV), Teela caches the file data locally in an isolated SQLite database:

• Each file upload is scoped to a specific connection_id and client_id.
• The SQLite database is isolated per connection; there is no cross-connection data access.
• File data is subject to the same multi-tenant isolation controls as all other data.
• Cached data is removed according to the organization's data retention policy.

Multi-Tenant Isolation

Teela is a multi-tenant platform. Tenant isolation is enforced at the application layer:

• Every data operation is scoped by client_id (organization) and connection_id (specific database connection).
• Application-layer queries include tenant-scoping conditions on every database access.
• Schema metadata and training data in the vector database are encrypted and partitioned per connection.
• There is no shared data space between tenants. A user in one organization cannot access or discover data belonging to another organization.

Input Validation and Query Safety

Server-Side Validation

All inputs to the Teela backend are validated using Pydantic models:

• Every API endpoint defines a strict schema for acceptable input.
• Type checking, length constraints, and format validation are enforced before processing.
• Invalid inputs are rejected with structured error responses. They do not reach business logic or database layers.

SQL Injection Protection

Teela uses parameterized queries for all database operations:

• User inputs are never concatenated into SQL strings.
• Query parameters are bound through the database driver's parameterization mechanism.
• This applies to both Teela's internal MySQL database and queries executed against customer databases.

File Upload Validation

File uploads are validated before processing:

Control	Implementation
Extension whitelist	Only approved file extensions are accepted (e.g., .csv, .xlsx, .xls)
MIME type checking	File MIME types are verified against expected types for the declared extension
Size limits	Maximum file size is enforced at the application layer

Files that fail validation are rejected and not stored.

XSS Protection

Cross-site scripting (XSS) is mitigated through multiple controls:

• DOMPurify sanitizes all user-generated content before rendering in the browser.
• The frontend is built with strict TypeScript, which reduces the risk of unsafe DOM manipulation.
• React's default escaping of JSX expressions provides an additional layer of output encoding.
• Content Security Policy (CSP) headers restrict the sources from which scripts can load.

Frontend Security

The Teela frontend (React on Azure Static Web Apps) implements the following security controls:

• No secrets in the browser. API keys, encryption keys, and database credentials are never transmitted to or stored in the frontend. All sensitive operations occur server-side.
• React StrictMode is enabled, which helps identify unsafe lifecycle methods and other potential issues during development.
• Strict TypeScript is enforced across the codebase, reducing classes of runtime errors that could lead to security vulnerabilities.
• Security headers are configured on both the backend API and the Static Web App:
  • Strict-Transport-Security (HSTS)
  • X-Content-Type-Options: nosniff
  • X-Frame-Options: DENY
  • Content-Security-Policy
  • Referrer-Policy

CORS Configuration

Cross-Origin Resource Sharing (CORS) is configured with an explicit whitelist of allowed origins. Requests from origins not on the whitelist are rejected. The CORS policy does not use wildcards in production.

Third-Party Integration Security

Google OAuth

• Google OAuth integration uses state parameter verification via Redis to prevent CSRF attacks during the OAuth flow.
• OAuth tokens are stored server-side and are not exposed to the frontend.

Intercom

• Intercom identity verification uses HS256 JWT signatures to ensure that user identity data sent to Intercom has not been tampered with.

Data Retention

Data retention periods are configurable per contract and aligned with each customer's compliance requirements:

• Query history retention is defined in the service agreement.
• Training data is retained as long as the connection is active unless the customer requests earlier deletion.
• File upload caches are subject to the same retention policy as other connection-scoped data.
• Upon contract termination, all customer-specific data (connection configurations, training data, cached files, schema metadata) is deleted within the agreed-upon timeframe.

Data Subject Rights (GDPR)

Teela supports the following data subject rights as defined by the General Data Protection Regulation:

Right	Implementation
Right of access	Data subjects can request a copy of all personal data Teela holds about them.
Right to rectification	Data subjects can request correction of inaccurate personal data.
Right to erasure	Data subjects can request deletion of their personal data ("right to be forgotten").
Right to data portability	Data subjects can request their personal data in a structured, machine-readable format.
Right to object	Data subjects can object to processing of their personal data for specific purposes.

Requests are processed within the timeframes required by GDPR (typically 30 days). To submit a data subject request, contact Teela's data protection team.

Data Breach Management

In the event of a data breach involving personal data:

1. Affected data subjects are identified and the scope of exposure is determined.
2. Regulatory authorities are notified within 72 hours as required by GDPR.
3. Affected individuals are notified without undue delay when the breach poses a high risk to their rights and freedoms.
4. Remediation actions are taken and documented.

Third-Party Data Processing

When Teela engages third-party services that process data on behalf of customers:

• Data Processing Agreements (DPAs) are executed with all sub-processors.
• Sub-processors are evaluated for security and compliance before engagement.
• Customers are notified of material changes to sub-processor arrangements.
• Sub-processors are subject to the same data protection requirements as Teela.

International Data Transfer

For transfers of personal data outside the European Economic Area (EEA):

• Transfers are conducted under appropriate safeguards (Standard Contractual Clauses or equivalent mechanisms).
• Data transfer impact assessments are performed where required.
• Customers are informed of the countries and mechanisms involved in any international data transfer.

Privacy by Design

Teela incorporates privacy considerations into the design of every feature:

• Data minimization: Teela collects and stores only the data necessary for its function.
• Purpose limitation: Data is used only for the purposes disclosed to the customer.
• Storage limitation: Data is retained only as long as necessary for its stated purpose.
• Default privacy: New features default to the most privacy-protective configuration.
• Transparency: Customers have visibility into what data Teela accesses and how it is processed.

For details on how data is encrypted throughout its lifecycle, see Encryption. For details on who can access what data, see Access Control.