← Blog3 min read

Anomaly Detection on Database Access

Most of the controls in PgBeam are rules you set in advance: this credential is read-only, allowed these tables, capped at this budget. They are the right foundation. But they only catch what you thought to forbid. They do not catch a credential doing something allowed that it has simply never done before.

That is what anomaly detection is for. Instead of a fixed rule, it watches each credential's behavior and flags when the behavior changes.

What "normal" looks like

Every credential develops a pattern. A reporting agent runs a few dozen queries an hour, all reads, all against the analytics schema, mostly during business hours. A support credential runs a steady trickle of lookups by ID. An ETL credential bursts on a schedule and is quiet otherwise.

PgBeam builds a baseline from this. Three signals matter most:

  • Volume: a sudden spike in queries per minute or rows read, well above the credential's normal range.
  • Timing: access at hours the credential is never active, the classic "3am query from a credential that only ever runs at 2pm."
  • Query shape: a structure the credential has never run before. A reporting agent that has only ever run SELECT against three tables suddenly issuing a query shape it has no history of.

When a credential drifts from its baseline on any of these, PgBeam surfaces an alert.

Why drift is the signal

The reason this works is that the interesting failures are usually changes, not absolutes. A credential that was scoped correctly and behaved normally for weeks, and then suddenly queries ten times as much at an unusual hour with a query shape it has never used, is telling you something. Maybe the agent was repurposed. Maybe it was compromised. Maybe a prompt injection redirected it. Maybe a human is using a service credential interactively. You do not need to know which in advance. You need to know that the pattern broke.

A fixed rule cannot express "alert me when this gets weird," because you do not know in advance what weird will look like. The baseline does, because it learned what normal looks like and weird is simply the departure from it.

Agents and humans

For agents, anomaly detection catches the failure modes that scoping cannot. An agent stays within its allowlist and its budget, but starts behaving differently: more volume, new shapes, off-hours activity. That drift is the early warning that the agent is doing something other than its job, even when every individual query is technically permitted.

For humans, the same drift detection is account-compromise detection. A human credential being used in a way it never was before, a new shape, a new time, a volume spike, is one of the most reliable early signals that the credential is no longer in the hands you issued it to.

What you do with an alert

An anomaly is a signal, not an automatic block, because the safe response depends on context. PgBeam surfaces the alert and routes it where you can act: into the dashboard, and out through webhooks and your SIEM so it lands next to the rest of your security signals. From there you decide: investigate, tighten the budget, or hit the kill-switch and cut the credential off while you look.

It is the layer that watches for the thing you did not write a rule for. Combined with the audit log that records every statement, you get both the alert that something changed and the full trail to understand what.

Try PgBeam or see the full feature set.

Give your agent Postgres it can't wreck

Connect a database, issue a credential, and watch the audit log fill up. No credit card. 14-day trial.