> ## Documentation Index
> Fetch the complete documentation index at: https://oxy.tech/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> How Airhouse authenticates users, enforces roles, encrypts connections, isolates databases, and protects your data.

This page summarizes the security controls in Airhouse and what you configure yourself when you deploy it.

## Authentication

* **SCRAM-SHA-256** for every wire-protocol connection, the same password mechanism modern PostgreSQL uses.
* **No plain-text passwords at rest.** Passwords for database users and minted credentials are stored as SCRAM verifiers.
* **Short-lived credentials.** [Service accounts](../guides/service-accounts) mint per-user credentials that expire after at most 24 hours and can be revoked individually. A service-account bearer can only mint for its own database, capped at its `max_role` and `max_ttl_secs`. Only a hash of the bearer is stored.
* **Admin API tokens.** The Admin API requires a bearer token on every request. Keep the admin token on your servers only.
* **Fail closed.** If Airhouse can't reach its user registry, it rejects logins (SQLSTATE `53300`) instead of letting them through. If it can't determine a session's role, it closes the connection instead of running with reduced privileges.

## Authorization

* **Roles on every statement.** `reader`, `writer`, and `admin` are checked before a statement reaches the query engine. See [Users, roles, and security](../guides/users-and-roles).
* **Schema-scoped writers.** Credentials can be limited to writing in named schemas. See [Schema-scoped writers](../guides/service-accounts#schema-scoped-writers).
* **Extension allowlist.** Users can only `INSTALL` or `LOAD` DuckDB extensions the operator allows.

## Encryption

* **In transit, clients:** enable TLS on the server with a certificate and key (`[tls]`, or `tls` in the Helm chart), and connect with `sslmode=require` or stricter. With the Helm chart, TLS passes through HAProxy to the data plane.
* **In transit, Postgres:** the Helm chart connects to the registry and catalog servers with `sslmode=require` by default.
* **In transit, object storage:** set `use_ssl` (`S3_USE_SSL`) to use HTTPS to your storage endpoint.
* **At rest:** Airhouse stores data in your object storage and Postgres. Use their encryption at rest, such as server-side encryption on the bucket and encrypted Postgres storage.

## Isolation

* **Between databases.** Each database has its own catalog, its own Postgres role, its own storage prefix, and its own users. See [Multi-tenancy](./architecture#multi-tenancy).
* **Between connections.** Each connection runs in its own DuckDB session, and per-user and per-database limits stop one workload from starving others.
* **Your infrastructure.** Airhouse runs in your environment. Your data doesn't leave your storage and Postgres. See [Where your data lives](./architecture#where-your-data-lives).

## Auditing

Airhouse records executed queries, including the user, duration, row count, and outcome, in an audit log. Each credential minted by a service account gets its own unique username, and Airhouse stores it with the `subject` your platform supplied and the issuing service account. Because the audit log records the username, you can trace each query back to one of your users.

## Your responsibilities when you deploy

* Replace every default password and token. Generate the admin token with `openssl rand -hex 32` and store it in a secret manager.
* Enable TLS for any client traffic that crosses a network you don't control.
* Keep port `8080` (Admin API) reachable only from trusted networks.
* Restrict access to the bucket and the Postgres servers to Airhouse and your administrators.
* Give each user the lowest role that works, and prefer short-lived credentials for applications.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.