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

# Security and encryption

> The current security model in MantrixFlow, including account controls, credential handling, and practical hardening guidance.

MantrixFlow security has two parts in day-to-day operations: securing user access to the workspace and securing the credentials used by pipelines.

## What the product exposes today

Open **Settings** from the left sidebar. The Settings page has five tabs:

* **Profile** — edit first name, last name, display name, and avatar URL
* **Organization** — update org name, slug, and description (Owner only)
* **Notifications** — email and alert preferences
* **Security** — review verified email, change password
* **Billing** — plan details, usage limits, and upgrade options

The top of the Settings page shows your account name, email, role badge (Owner/Admin), verification status, and profile completion percentage.

## Credential handling

Based on the current connection experience and supporting product copy:

* connection credentials are encrypted at rest using AES-256
* credentials are not returned in normal product responses or screens
* credentials are not meant to be written to logs
* connections should be tested before they are saved into production workflows

## Access model

* users authenticate with bearer-token based application access
* organization membership controls what resources a user can see
* roles determine whether a user can edit settings, manage members, or build pipelines

## Practical hardening checklist

* use dedicated service accounts for databases and SaaS sources
* grant minimum required privileges
* enable SSL for database connections where the form and provider support it
* for managed PostgreSQL providers, allow MantrixFlow's static IP as a `/32` on port `5432` instead of opening broad database access
* rotate credentials periodically
* keep the owner role limited to a very small set of users

## Real-world example

A finance team moving data from one PostgreSQL database into a reporting PostgreSQL database uses separate read-only and writer credentials, stores reporting output in a dedicated destination schema, and limits workspace ownership to one or two administrators while day-to-day operators work as admins or editors.

## What security is not solved by the platform alone

The platform cannot compensate for an over-privileged database user, shared passwords, or unreviewed production schedules. Good operational security still depends on how your team provisions and rotates source and destination access.