What is database activity monitoring (DAM)?

Your database can log that a query ran. It usually can’t tell you which engineer, BI viewer or AI agent sent it, or whether the rows it returned should have left. Database activity monitoring (DAM) closes that gap.

What does database activity monitoring do?

Database activity monitoring (DAM) is a security control that keeps a record of every login, query and session on a database, tied to the identity behind it: who connected, what they ran, which columns came back and how many rows. Security teams use that record to alert on misuse, investigate incidents and show auditors who touched regulated data.

“Activity” covers more than reads. A DAM program watches logins and failed logins, reads of sensitive tables, writes and deletes, schema changes, permission grants and anything an administrator does.

Alerts can fire in real time when the monitor sees statements as they run, or later when it reads logs in batches. Analysts have also called the category database auditing and real-time protection, and a DAM tool that can block as well as record is sometimes called database activity monitoring and prevention, or DAMP (Wikipedia).

What DAM produces is an audit trail. NIST defines an audit trail as a chronological record that lets someone reconstruct the sequence of activities around a security-relevant event. For a database, that means answering months later which person read a customer table on a given afternoon, through which tool, and how many rows came back.

How does database activity monitoring work?

A DAM system needs a vantage point that sees statements on their way to the database. There are three common database activity monitoring architectures, and the choice decides what the record can contain. Most database activity monitoring tools are built on one of them, and some combine two.

Native database auditing

Most databases can log their own statements. PostgreSQL, for example, has the log_statement setting, and the pgAudit extension adds session and object audit logging on top. Native database auditing is cheap to turn on and sees everything the engine runs.

Its limits come from where it lives. The log names the database role, so ten engineers and a BI tool sharing one role look like one user. The people the log is meant to watch, the database admins, can change its settings or turn it off. And it only records: it can’t stop a query. The Postgres integration page compares pgAudit with logging at a proxy.

Agents on the database host

Some DAM products install an agent on the database server. The agent sees local connections as well as network ones, so an administrator logged in on the machine doesn’t slip past it. The cost is operational: the agent is software to deploy and patch on every host, it shares the database server’s resources, and it needs a host you are allowed to install software on.

Monitoring in the connection path

The third model watches traffic between clients and the database, either by capturing it from the network or by routing it through a proxy. A proxy that parses the database protocol sees each query and each result, and it knows which identity authenticated to it, which can be a person rather than a shared role. Because it sits in the path, it can also act: block a statement or mask a column before the data reaches the client.

Here’s the catch: an in-path monitor only sees the traffic routed through it. A connection that goes straight to the database skips it, so this model works when direct network access to the database is closed and the proxy is the only way in.

What does a DAM tool record?

A DAM record is only as good as the question it can answer later. That question is rarely “did a query run?” It’s “who read this customer’s data, through which tool, and how much of it?” A complete record has five parts:

• Identity. The person or agent who sent the query, not only the database role. When a BI tool or an application connects with one service account, the record also needs the end user behind it, and whether the identity is a human or a machine.
• Session context. When the connection opened and closed, the client IP and the client application, such as psql or a BI tool.
• The statement. The full query text, plus a normalized form or fingerprint, so that thousands of similar queries group into one pattern.
• The result. How many rows came back or changed, and which columns, ideally with a data classification label such as email address or card number.
• The decision. Whether a policy allowed, blocked, masked or rewrote the query. If the query was rewritten, the record should keep both versions: what the client sent and what reached the database.

That last point is easy to miss. Once a monitor can change queries, an audit log that keeps only one version can’t show an auditor both what was asked and what actually ran.

Is the DAM log sensitive data too?

Yes. Query text carries values: an email address in a WHERE clause, a card number in an INSERT. A DAM log that stores full queries becomes a second copy of the sensitive data it protects, readable by anyone who can read the logs. Good database audit logging lets you remove, truncate or encrypt fields before the log is stored or exported. Formal’s fine-grained Connector log controls describe one way to do it.

What are the main database activity monitoring use cases?

Each of these use cases reads the same record. What changes is who reads it, and when: an auditor once a quarter, an incident responder within hours, a security team continuously.

Compliance audits and access reviews

Auditors for frameworks that cover regulated data, such as PCI DSS for payment cards, HIPAA for health records and SOX for financial reporting, ask who accessed that data and whether the access matched policy. With DAM in place, the compliance answer is a search instead of a reconstruction project: all access to the tables in scope, by person, over the audit period.

Incident response and scoping

When something goes wrong, the first question from customers is scope: which records, which accounts, over what window. A DAM record answers it from data instead of estimates. When a vulnerability hit Metabase, teams that ran a proxy between the BI tool and its data sources could see which queries ran, by whom and when. Our write-up of the Metabase zero day walks through that case.

Privileged and insider misuse

DBAs, SREs and service accounts hold the broadest access and get the least supervision. They are also the accounts an attacker wants, so misuse can be an insider threat or a stolen credential. DAM records what they do with it: a SELECT across a whole customer table, a superuser grant, a schema change outside a change window. It complements privileged access management, which decides who holds that access in the first place.

Shared BI and application accounts

BI tools and applications usually connect with one service account, so the database sees a single user standing in for thousands of people. DAM that propagates the end user, for example through a query tag or a SQL comment the BI tool adds to each query, attributes each query to the viewer who triggered it. The Snowflake integration page shows how this works for Omni, Looker, Metabase and other BI tools.

AI agents

Agents query databases at machine speed, often with credentials nobody has reviewed. They get their own section below.

DAM vs database monitoring: what is the difference?

“Database monitoring” usually means performance monitoring: is the database up, fast and healthy? DAM asks a security question: who did what with the data? The two often read the same query activity but look for different things.

Most teams need both. A performance tool tells you a query was slow; DAM tells you it was an export of the users table by an account that had never run it before.

DAM vs privileged access management: how do they fit together?

Privileged access management decides who gets into a database, when, and with which rights. DAM records what happens once they’re in. Access control without monitoring can’t prove it worked, and monitoring without access control can only watch.

The two are strongest at the same point in the connection path. When the access decision and the query record come from one place, they name the same identity: the person approved for production access is the person whose queries appear in the log, even when they connect through a BI tool or an agent.

That is how database access management in Formal PAM is built. Masking a sensitive column, one of the actions an in-path monitor can take, has its own page: data masking.

Database activity monitoring for AI agents and machine identities

AI agents are now database users. A coding agent debugging an issue, an analytics agent answering a question, an internal tool that gives a model database access: each one sends SQL, often more of it and faster than a person would. Its next query can also come from text it has just read, such as an instruction planted in a document or a web page (prompt injection).

The common setup makes agents almost impossible to monitor. The agent runs with a shared database password or a long-lived key in its environment, so the log shows a service account. Nobody can tell which agent ran a query, on whose behalf, or whether a person would ever have run it.

Database activity monitoring for agents rests on three changes:

• Each agent gets its own machine identity. It authenticates as itself, with a short-lived credential, instead of borrowing a shared account.
• The log records the person behind the agent. Every query carries both identities: the machine that sent it and the human who started the session. Policies and alerts can use either one.
• Agent activity stays separate from human activity. When each identity is typed as human or machine, you can baseline agents on their own, review them on their own and spot an agent doing something no person on the team does.

Cursor’s security team did this for its internal Cloud Agents. Each agent workflow gets its own Formal identity with narrow access, and Formal ties every action of that agent to the employee who launched the task, as the Cursor case study explains.

“We’ve limited the amount of data that those cloud agents can access and we’re able to tie that back to the specific user who is using that cloud agent, which is a feature that I’m only aware of Formal having.”

— Roy Xu, Software Engineer, Security @ Cursor

Database activity monitoring best practices

1. Start from the sensitive data. Classify which tables and columns hold personal, payment or health data, and monitor those first. A rollout that logs everything with the same weight buries the events that matter.
2. Name every identity. Replace shared database accounts with individual ones, and propagate the end user from BI tools and applications. A log full of app_user can’t support an investigation.
3. Keep the log out of reach of the people it watches. Store the record where the database admins whose activity it covers can’t edit or delete it.
4. Keep the query text, redact the values. Investigators need the statement; they rarely need the email address inside it. Remove or encrypt sensitive fields before the log is stored.
5. Send logs to your SIEM, with retention that matches your audits. Set retention from the framework you answer to, and archive long-term copies in storage you control.
6. Alert on a short list of behaviors. Bursts of failed logins, privileged statements outside change windows, unusually large result sets, and sensitive columns read by an identity for the first time. A long list of noisy alerts gets ignored.
7. Review on a schedule. Look at who accessed regulated data every month or quarter, not only after an incident.
8. Monitor agents like people. Give them their own identities, tie them to a human, and apply the same rules to their activity.
9. Test before you block. When the monitor can enforce, run each new rule in a log-only mode first and check what it would have stopped.

How does Formal approach database activity monitoring?

Formal takes the in-path approach. The Formal Connector is a protocol-aware reverse proxy between people, agents and machines and the databases they use, such as Postgres, MySQL, Snowflake, MongoDB and ClickHouse. The docs describe it as the proxy that provides visibility and control over data access. Each person or agent connects with their own identity, and every query that passes through the Connector is logged.

Each database query log carries the full query, execution time and rows affected, the Formal user and the end user behind a BI tool, the client IP and application, and any policy action (logs docs). It also keeps the query both as the client sent it and as it reached the database after any rewrite, a normalized query, a fingerprint for grouping similar queries, and the returned columns with their data classification label.

Every user is typed human or machine, which is what separates agent activity from human activity in the log.

Sessions group the queries of one connection for PostgreSQL, MySQL, MongoDB and other databases, and admins can end a session that is still open. Logs are searchable with Quickwit queries. This search from the sessions docs finds every query that touched a users table:

event_type:request AND (request.query.received:"FROM users" OR request.query.received:"JOIN users")

Rego policies act at that same point: they block, mask, filter or rewrite queries and results, so the monitor is also the enforcement point. Log schemas remove, truncate, encrypt or sanitize fields before Formal stores or exports a log, and log integrations forward logs to AWS S3, Google Cloud Storage, Azure Blob Storage, Datadog, Splunk or Panther. Connector logs stay available for as long as the account is active.

Two limits, stated plainly. Formal logs the traffic that goes through the Connector, so direct network paths to the database need to be closed for the record to be complete. And Formal’s AI risk scoring covers SSH and Kubernetes sessions, not database queries: database monitoring relies on the query log, policies and the alerts you build on them in your SIEM.

At Cursor, Formal handles 40M+ logs and 600K+ sessions per week across 10+ technologies. Database activity monitoring is part of Formal PAM, which keeps access control and the query record in the same Connector.