Security monitoring
The tool watching your database is a path into it
Anything monitoring Postgres holds a credential, opens a connection and carries data outward. That makes the security question about the monitoring itself, as much as about what it detects.
Two questions that get answered as one
Security monitoring for Postgres is usually discussed as detection: who logged in, which roles hold what, which settings drifted away from the agreed shape, what happened during the window somebody is now asking about. That is a real question and most estates answer it badly, because the evidence is spread across nodes and nobody diffs roles between a leader and its followers on an ordinary week.
But a security reviewer looking at a monitoring tool is asking something else first, and it is the harder question. You are proposing to put a credential into production, open a connection to every database in the estate, and move data out of them continuously. Whatever the tool detects, it has also enlarged the attack surface by exactly the size of itself. A review that skips that part is not a review.
The two questions are related in a way that is worth noticing. A tool that cannot tell you precisely what privileges it holds and what it carried out of your database is also a tool whose posture findings you have no particular reason to believe. Specificity about itself is the evidence for everything else it says.
Four questions your reviewer will ask
Put them to anything you are already running as well. Each should have an answer specific enough to disagree with.
Ask what role it holds
The thing watching a database should not be able to alter one. A named read-only grant your own DBA writes and can read back is a different proposition from a superuser and a promise.
Ask what leaves, and when
Counters and catalog metadata are one category. The values inside a statement are another, and they are where the customer records are. Whether those are stripped, where they are stripped, and whether that is the default all matter.
Ask who could edit the history
A record of who changed what is only evidence if the party being audited could not quietly revise it. Verifiable independently, or it is a log rather than an audit trail.
Ask how often posture is re-checked
A grant issued during an incident outlives the incident. A baseline agreed at onboarding is describing last quarter by this one. Checked once is a claim; checked on a schedule is a control.
Our answers, in the same order
The role first. One agent serves one tenant and is never shared between customers. It reaches a database through a read-only monitoring role, not a superuser, and on managed platforms it can authenticate through the cloud’s own identity service rather than holding a stored password at all. Its connection pool is small, capped and read-only, with short statement, lock and idle timeouts, so that the monitoring cannot become the incident. The agent’s own identity is a private key that stays on its host, and the certificate it presents is short-lived and renews itself.
Then what crosses the boundary. Counters, catalog metadata, execution plans and statement text go out; the rows in your tables never do. Literal values are stripped from statement text on the agent, before transmission rather than after arrival, and capturing parameters is off unless you turn it on. What does arrive is classified confidential, stored encrypted, kept out of the search index, and readable only by owners of your own tenant. Tenants are separated in storage by row-level security that is forced rather than advisory, and the support path that can cross that boundary writes its own use into the audit record. Security and trust is the full version, control by control.
Then the history. Every observation, decision and action lands in an append-only ledger, one per tenant, whose entries are chain-hashed and signed with keys that rotate, and whose periodic snapshots let an auditor prove a given entry belongs without being handed the entire log. Deletion requests are met by destroying the tenant key, so the chain stays intact while the content becomes unreadable. That is also the mechanism that makes an assistant safe to connect, because an agent meets the same gate and the same record a person does.
Then posture. Configuration, schema and security posture on each node are compared against the baseline agreed for that class of cluster, re-checked on a schedule rather than at onboarding, and a divergence is raised as a dated event. Because every node is read in its own right, a grant present on two nodes and missing on a third is a finding rather than an average. On compliance we will be precise: our control set is mapped to the SOC 2 trust services criteria and an independent audit is under way. We are not going to describe that as a certificate, and enterprise reviewers get the current readiness report and control matrix under NDA.
What a posture finding carries
Dated by the re-check that found it, scoped to the nodes it is actually on, and written down whether or not anybody acts on it.
posture drift against the agreed baseline for this class of cluster finding a login role now holds a broader grant than the baseline allows scope present on two nodes of the cluster, absent on the third context absent at the previous re-check · so the window is bounded export query text is confidential, encrypted, and not part of this report record the finding and anything done about it are signed into the ledger
Line three is the one that decides how long the remediation takes. A grant that exists on some nodes and not others is how a failover turns a tidy estate into an untidy one, and it is invisible to anything reading only the writer. The same per-node habit is what makes an estate-wide view worth having rather than an average of things that are not alike.
Things to check before you buy anything
Diff the roles and settings between a leader and its followers by hand once. Config drift between primary and standby has the method and the settings that matter most, and the exercise usually turns up at least one grant nobody remembers making. While you are there, check which accounts can connect from where, and whether the answer is the same on every node.
Do the same for whatever is in front of the database, because credentials terminate there rather than at Postgres in most architectures and the inventory of those is often worse — pooling covers finding them. None of this needs a vendor. It needs someone with a free afternoon and the willingness to write down what they find.
Send this page to the person who has to approve us.
A pilot uses a read-only role your DBA creates, strips literals before anything leaves the host, and records every decision in a ledger you can verify yourself.