Your Database Credentials: What We See vs What We Don't

You're giving us access to your database. Here's exactly what happens to your credentials, where they're stored, and what we can't see even if we wanted to.

securityprivacycredentialsencryptiontrust

You’re About to Give Us Database Access

That’s a big deal. We know it. Database credentials security matters.

Your database contains customer data, financial records, business intelligence. Handing over credentials requires trust. Trust requires transparency.

Here’s exactly what happens when you connect your database to LILA, and why we built database credentials security into every layer.

What Happens to Your Credentials

When you enter database credentials (host, port, username, password), here’s the sequence:

  1. Credentials encrypted immediately. Before anything else. AES-256 encryption using a key derived from your project.

  2. Encrypted credentials stored. The encrypted blob goes to our database. The actual password never exists in plain text after you submit it.

  3. Decryption only at query time. When you ask a question, we decrypt credentials in memory, establish a connection, run the query, and discard the connection.

  4. No logging of credentials. Connection strings never appear in logs, error messages, or debugging output.

What We Can See

Our team can see:

  • That you have a project connected to a database
  • The database type (PostgreSQL, MySQL)
  • Connection success/failure status
  • Query counts and usage statistics

What We Cannot See

Our team cannot see, even with full system access:

  • Your database password
  • The actual content of your queries (optionally logged at your choice)
  • Your data (we never store query results)
  • Your schema details beyond what the AI needs

The encryption key is derived per-project. A database breach would yield encrypted blobs, not usable credentials.

The Technical Details

Encryption: AES-256-GCM with unique initialization vectors per encryption operation.

Key Derivation: PBKDF2 with project-specific salts. Even identical passwords encrypt to different ciphertexts.

Storage: Encrypted credentials in PostgreSQL with additional field-level encryption.

In Transit: TLS 1.3 for all connections. Certificate pinning available for enterprise.

What About Our Employees?

No LILA employee can view your database password. Here’s why:

  1. Encryption happens before storage
  2. Decryption keys aren’t accessible to humans
  3. Production database access is audited and restricted
  4. No debugging tools expose credential data

Could a malicious engineer theoretically modify the system to capture credentials? In theory, yes. That’s why we:

  • Require code review for all changes
  • Maintain audit logs for all production access
  • Use automated security scanning
  • Conduct regular security assessments

We recommend connecting with a read-only database user:

CREATE USER lila_readonly WITH PASSWORD 'your_password';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO lila_readonly;

Benefits:

  • Even if everything else fails, no data can be modified
  • Limits blast radius of any theoretical breach
  • Satisfies security team requirements

LILA works perfectly with read-only access for query functionality.

Where Your Data Goes

When you query your database without SQL, here’s the flow:

  1. Your question → LILA servers
  2. LILA generates SQL → Sent to your database
  3. Your database returns results → Streamed through LILA
  4. Results displayed in your browser

We process results to format them. We don’t store them. When the connection closes, the data is gone.

Audit and Compliance

For enterprise customers who need documentation:

  • SOC 2 Type II compliance in progress
  • Data processing agreements available
  • Custom data retention policies configurable
  • Audit log exports available

The Trust Question

Should you trust us? We’ve designed database credentials security that doesn’t require you to:

  • Encryption means a breach doesn’t expose credentials
  • Read-only access means we can’t damage data
  • No storage means we don’t accumulate risk over time

Trust isn’t just about our intentions. It’s about architecture that limits damage even when things go wrong. That’s why we built LILA this way from day one.

Questions We Get

“Can you see my customer data?” No. We see the structure (column names), not the contents.

“What if your servers are breached?” Attackers get encrypted credentials they can’t decrypt. No usable access to your database.

“Do you backup my credentials?” Yes, encrypted. Backups are AES-256 encrypted at rest.

“Can I rotate credentials?” Yes. Update in your LILA dashboard anytime. Old credentials immediately invalid.

Still have security questions? Contact our security team