Trust · Security & architecture

Security & Trust

Praxion is the governor of your Postgres that runs inside your own network. On-prem. Auditable. Nothing reaches in, no write path exists, and the only thing that crosses the boundary is anonymized metadata.

Last updated: September 2026 · Praxion Engineering

01Where the agent runs

The agent is a single process — a container or a signed native binary for Windows, macOS or Linux — that you run on a host you control, not ours. It opens outbound connections only, so nothing can reach in: there is no inbound port, no public hostname and no VPN. It installs nothing on your database and asks for no inbound access.

It reads pg_stat_statements from your read-only replica, and never the primary. It has no credentials for the primary at all. Deploying it takes the same four settings: AGENT_ID, LICENSE_KEY, CONTROL_PLANE_URL and PG_REPLICA_DSN. See the Quickstart for the full walkthrough.

No write path
The agent only observes, and only against a read-only replica. Suggestions are raised with the DDL attached; your DBA reviews them.
Least privilege
The only Postgres privilege it needs is reading pg_stat_statements from a replica. There is no write credential anywhere.
Detection of silence
An agent counts as running only if it reported in the last 90 seconds — a stopped process or a blocked outbound connection reads as exactly that.
You hold the off switch
Nothing on the dashboard can start or stop the agent. You start and stop it on the host where it runs.

02What leaves your network — and what never does

What crosses the boundary is an anonymized query fingerprint, its timings (p50/p95/p99) and the catalog metadata the schema map is drawn from.

What never crosses is any row value — and neither do the host name or the database name: both are fingerprinted on arrival and the originals are discarded. Credentials never leave either. Your database never exposes itself to the control plane, and the control plane never touches your database.

Private by architecture — not by policy. The agent is fed, not queried: no client payload reaches a storage table unvalidated, so a compromised agent cannot inject data into another tenant.

03Two transport tiers

Enterprise connects the agent over AWS PrivateLink (or Azure Private Link), provisioned against your AWS account on request, so traffic stays inside the private network. It is not self-serve: we provision a VPC endpoint service against your account first, and only then does a private DNS name exist for the agent's CONTROL_PLANE_URL. No public internet, no IP allowlists.

Starter and Growth reach the same platform API over HTTPS/TLS. The agent authenticates and connects outwards — no VPN, and your database is never exposed.

Either way, your table data never leaves your network. PrivateLink is what a PCI- or HIPAA-type review tends to ask for; the guarantee about your rows is the same on every plan.

04Credentials and revocation

AGENT_ID and LICENSE_KEY are minted in the panel and the key is shown once — Praxion cannot display it to you again. Each database you register is attached to an agent, and the Agents screen shows what each one is able to do.

You can revoke an agent's credentials from that screen at any time: its next request is refused. Revoking cannot be undone, and it does not stop the process — you stop that where it runs. Multiple agents are supported, one per host or replica.

05The audit log

The audit log is append-only and hash-chained: each event anchors its SHA to the previous one, so any out-of-order insert invalidates the chain and triggers an alert. It is available on Enterprise, together with unlimited dashboard users.

Every change you make lands in the log, and so does every query generated by Text-to-SQL — recorded as an event, in order.

06Tenant isolation in the control plane

The control plane runs on Supabase Postgres with ENABLE + FORCE ROW LEVEL SECURITY across 9 tables — semantic, billing and CI — enforced by migration 0008. The agent-fed surfaces stay application-filtered on purpose.

Identity maps 1:1: each Clerk Organization is one Praxion workspace, with RBAC via role_mappings and no shared "default workspace". The API edge applies per-workspace rate limits that answer with 429 and a Retry-After the agent respects, and validates every payload before it reaches storage.

07Human approval, always

Praxion never applies anything to your database. Each suggestion carries a predicted saving and a confidence score, so a 35% estimate never reads like a certainty. You review the DDL and either copy it into a pull request or apply it through the API — with mandatory human approval before any change is applied, on every plan including the trial.

Observing your queries is never what you pay for: continuous query-log analysis is included from the moment the agent is connected.

08Text-to-SQL guardrails

Natural-language querying is guardrailed four ways, so raw generated SQL never runs unsupervised:

  • The SQL is printed before anything runs — you read it before your database does.
  • Every business term resolves through your glossary rather than the model's assumptions, so "active customer" means what your company says it means.
  • The indexes a query wants to use are validated against the real schema.
  • Every generated query is recorded as an event in the audit log.

Related reading

Quickstart — Connect Your First Postgres Database → Optimizations — Where Praxion's Suggestions Come From → Monitoring On-Prem Postgres Without a SaaS Agent → Text-to-SQL with Guardrails →

Reviewing Praxion for your organization?

We will walk your security team through the agent, the transport tiers and the audit log, and answer a questionnaire.

Talk to sales → All contact options →