How agentless database monitoring actually works

“Agentless” is one of those words a product can claim without earning. For database monitoring it has a precise meaning, and the precision matters, because the alternative, an agent on every production database, is exactly the thing a change-control board will push back on. Here is what agentless monitoring actually does, and where its honest limits are.

What an agent really costs you

An in-database or on-host agent is new privileged software running next to your most sensitive data. Every version of it is something your risk function has to assess, patch, and defend, and it runs on a system that is already under change control. On a large regulated estate that is not a one-time cost; it is a standing liability that grows with the fleet.

The engine already keeps the record

The key insight is that you rarely need to add anything, because supported engines provide audit facilities or activity views. Availability and detail depend on the engine, edition, configuration, and installed extensions. Oracle has Unified Auditing, SQL Server has SQL Server Audit, PostgreSQL has pgaudit, MongoDB has its audit log, and the rest have their equivalents. An agentless collector reads that native trail through a dedicated, read-only account and correlates it centrally. Nothing is installed on the database, there is no in-line component in the query path to fail, and the monitoring adds no new privileged software to defend.

The read-only account is the whole trust model

Because the collector connects as an ordinary read-only principal, its blast radius is bounded by what that account can see. Properly scoped read-only permissions limit the account’s ability to change data or configuration. The collector, its credentials, and the database connection still need protection; read-only access does not eliminate vulnerabilities or exposure of sensitive audit records. For an examiner, “we read the engine’s own audit stream through a read-only account and never touch the database” is a far shorter conversation than justifying an agent fleet.

The honest limits

Agentless is not magic. It sees exactly what the engine is configured to log, so the engine’s native auditing has to be enabled and scoped correctly first. It reads the audit trail, not raw network packets, so it is not a substitute for network capture where you genuinely need wire-level detail. And it depends on the audit account staying read-only and protected. These are manageable constraints, but a vendor that pretends they do not exist is not being straight with you.

How Vyrell does it

Vyrell, our database activity monitoring platform, is agentless by design: a read-only audit account per target, with nothing installed on the production database, reading each engine’s native audit facility across ten engines and correlating it centrally. It scores accounts against their own statistical baselines, keeps the resulting trail tamper-evident, and forwards alerts to your stack by email, webhook, or SIEM. Because there is no agent to roll out, a typical deployment takes one to two days.