Lucien AI logoLucien AI
Postgres

Postgres security

This page explains how Lucien thinks about security for the Postgres integration.

If you want the broader picture beyond Postgres, see lucienai.io/security.

1. Connection prerequisites

Before Lucien can talk to your Postgres database securely, a few things must be true:

  • Your database accepts encrypted connections (TLS/SSL), or you’ve explicitly chosen to allow unencrypted access (not recommended for production apps).
  • You can provide a connection URL or host/port/db/user/password.
  • If your database provider requires it, you have the right TLS certificates ready (see below).

Lucien is designed to treat these details as secrets – but it can only protect what you give it. If in doubt, create a dedicated read‑only user with the minimum access needed (see Create a read‑only Postgres user) and use that account only for Lucien.

2. Why TLS / SSL certificates matter

When Lucien connects to your database over the internet, there are two main questions to answer:

  1. Is anyone listening in on this connection?
  2. Are we really talking to your database, not an impostor?

TLS/SSL solves these by:

  • Encrypting the connection between Lucien and your database so credentials and data aren’t sent in plain text.
  • Verifying the identity of the database server using certificates, so Lucien doesn’t accidentally connect to the wrong endpoint.

Many managed Postgres providers (DigitalOcean, RDS, Neon, Render, Supabase, etc.) either:

  • Enable TLS by default with their own certificates, or
  • Allow/require you to upload your own.

Lucien plugs into whatever your provider expects – it doesn’t invent a new security model.

3. Types of certificates you may see

Depending on your host and configuration, Lucien’s Connect Postgres form may ask for some combination of:

1) CA certificate ("root" or "server" certificate)

Used so Lucien can verify it’s talking to the right server.

  • Often named something like rds-combined-ca-bundle.pem, server-ca.pem, etc.
  • Typically downloaded from your cloud provider’s docs or console.

2) Client certificate

Used when your database expects the client (Lucien) to present a certificate as part of authentication (mutual TLS).

  • Think of this as a special ID badge for Lucien’s connection.
  • Usually provided as a .crt or .pem file.

3) Client key

The private key that goes with the client certificate.

  • Must be kept secret; you should treat it like a password.
  • Usually provided as a .key or .pem file.

Not every setup needs all three. For many hosted databases, a connection URL + CA certificate (or even just the URL) is enough. Your provider’s Postgres connection docs are the source of truth here.

4. Where to get the right TLS certificates

Lucien never generates Postgres certificates for you. You should only use certificates from trusted sources:

  • Your cloud provider (DigitalOcean, AWS RDS, GCP Cloud SQL, Azure, etc.) – usually via their docs or console.
  • Your database platform (Neon, Supabase, Render, Railway, etc.).
  • Your own engineering team, if you run Postgres yourself.

In general:

  • Follow the "Connect via psql / SSL" section of your provider’s docs.
  • Use the same certificates they show for connecting from other clients (CLI, BI tools).
  • Paste or upload the full file content, including the -----BEGIN / -----END lines.

If a certificate came from anywhere else (email attachment from a stranger, random blog), don’t use it.

5. How Lucien stores credentials and certificates

All of the following are treated as sensitive secrets:

  • Database host, port, name
  • Username and password
  • Connection URL
  • CA certificate
  • Client certificate
  • Client key

High‑level guarantees:

  • Encrypted at rest – credentials and certificates are stored using strong encryption.
  • Scoped use – they are only used to open a connection to your database when Lucien needs to run a read‑only query.
  • No sharing – they are not exposed to other customers, logs, or external tools.
  • Revocable – you can revoke access at any time by:
    • Disabling/removing the integration in Lucien, and/or
    • Rotating the database password / certificates or disabling the read‑only user.

For how this fits into Lucien’s broader security story (infrastructure, logging, data retention), refer to lucienai.io/security.

For most production setups, we recommend:

  1. Create a dedicated read‑only user for Lucien (no write permissions). See Create a read‑only Postgres user.
  2. Enable TLS between Lucien and your database; use your provider’s recommended CA certificate.
  3. If your provider supports it and your team is comfortable with it, consider mutual TLS (client cert + key) for an extra layer of identity assurance.
  4. Share the connection details with as few people as possible – ideally just whoever integrates Lucien.

This gives you a simple answer when someone asks:

"What access does Lucien have to our database?"

You can say:

  • It connects over encrypted TLS, using certificates from our provider.
  • It uses a locked‑down read‑only user with no write permissions.
  • Credentials and certificates are encrypted at rest and revocable at any time.

7. If you’re unsure

If at any point you’re not sure which certificates or settings are appropriate:

  • Don’t guess – especially not in production.
  • Ask your technical co‑founder, infra/DevOps person, or whoever set up your database.
  • Share this page, the Connect Postgres guide, and your provider’s own "Connect to Postgres" docs.

Create a read-only Postgres user

How to create a locked-down database user for Lucien, so it can never mutate your data.

On this page

1. Connection prerequisites2. Why TLS / SSL certificates matter3. Types of certificates you may see1) CA certificate ("root" or "server" certificate)2) Client certificate3) Client key4. Where to get the right TLS certificates5. How Lucien stores credentials and certificates6. Recommended connection pattern7. If you’re unsure