Why AI Agents Are Making Database Activity Monitoring Critical Again

Database security and AI security are converging. Neither can function effectively in isolation. A modern solution requires combining execution‑level truth from DAM with intent, actor, and task context from AI‑aware security platforms.  

Agents change how databases are used 

Database security has historically been built on two key assumptions: 

• Human DBAs and operators execute most administrative actions 
• Workloads have clear temporal boundaries (sessions, jobs, change windows) 

These assumptions held because monitoring who did what was usually enough to explain why the action was taken. Database Activity Monitoring (DAM) became the cornerstone of the database security stack. More sophisticated enterprises went one step further, incorporating workflows to tie actions against a database to a user (monitored by DAM) with change request tickets filed against those users.  

DAM defined how teams think of identity, which is often the cornerstone of security policy management. In traditional enterprises, identity resolution was largely local and sufficient. A database user or service account could usually be traced directly to a human operator, a team, or a well-defined automation. When intent was unclear, it could usually be recovered out-of-band by asking the operator or correlating the action with a change request. 

In the agentic era, identity is no longer flat or proximal. DBAs are increasingly replaced by agentic harnesses and autonomous service operators acting on behalf of enterprise users, and temporal boundaries become ambiguous, with database actions being enveloped inside agentic workflows that are themselves long-lived, event-driven, and recursive. Database actions are executed through layers of delegated identities — originating from a human prompter, mediated by applications or agents, executed via MCP servers, and finally mapped onto database roles. Each hop attenuates accountability and strips away context unless it is explicitly carried forward. 

The outcome? Agents dramatically shifts the security model for databases, which are based on user identity, access modalities, and intent. 

Standalone DAM is no longer sufficient 

Traditional DAM products needed to answer one question: “What happened in the database?”  

While superficially simple, answering this question proved complex, requiring the audit of a highly critical, sprawling, and performance-sensitive component of an enterprise’s tech stack. DAM tools were built to observe and stitch together artifacts like SQL statements, connection properties, and metadata to provide a meaningful context for security teams, while ensuring there was no performance or deployment overhead for the database and infrastructure teams to worry about. 

But in an agentic system, figuring out what happened is not the hardest problem to solve.  

In an agentic system, the client issuing the command itself has no intrinsic understanding or context for why an action is being taken, whether the side effects are intended and if the results are acceptable. In such a setup, a conventional DAM produces accurate but context‑free reporting. This creates the dangerous illusion of perfect visibility without interpretability. 

Moreover, when DBAs do the work, we trust them from a performance lens and verify them from a security lens — exactly what DAM is all about. When it is an AI agent, we cannot blindly trust it. AI agents are not accountable to anyone. You can’t fire them. They can be confused. They can hallucinate. Therefore, it’s not enough to just “put a camera” and warn them. They don’t care. In the human world, DAM is for the most part a “deterrent control” — don’t do anything bad because we’re watching you.  

This hands-off trust mentality must be replaced in an agentic world with real controls. Partly because agents cannot be fired and have no accountability and, more importantly, because agents can still do a lot of damage if given the keys to the kingdom.  

Identity collapse compounds the problem. From the database perspective, vastly different actions (initiated by different users, applications, or agent workflows) can appear indistinguishable when they are executed through the same delegated roles or service accounts. DAM faithfully records the execution identity, but that identity is often no longer the authority that made the decision. Therefore DAM must evolve into higher-value controls as well as controls that live in the agentic guardrails layer. 

Signals are moving upstream, but the truth remains downstream 

The agentic era shifts security questions from “What ran?” to “Should this have happened, in this context?” 

Having recognized the limitations, much of the industry is shifting security upstream into the agentic layer. Moreover, the controls must shift from RBAC to Intent-Based Access Control (IBAC). It’s no longer a question of, “Is what was done allowed?” but rather “Is what was done justified and correct?” 

We want AI agents to be autonomous — we want to reap these benefits, but we also want to ensure we don’t get burned. 

AI security platforms now reason for prompts, agents plan and use runtime guardrails to prevent undesirable, and sometimes unintended, consequences of using LLMs. While always necessary, this is often not sufficient with databases. Databases operate with their own query languages, RBAC, and execution logic, thereby creating a structural tension between upstream layers that understand intent but not execution, and downstream systems that execute but do not understand intent.  

In parallel, identity information is also moving upstream. The database no longer sees the user who requested the action, but rather it sees the agent or tool delegated to act on the user’s behalf. Resolving who is responsible, therefore, requires stitching together multiple identities across the agent layer, tooling infrastructure, and database execution context. 

Why prompt-layer guardrails can’t catch database side effects 

Consider a developer building a new app tasking an agent with a directive to “Apply a schema migration to support feature X.” 

At the agent layer, the task appears narrow (a handful of DDLs are involved) and legitimate. However, in the database, the migration may touch shared tables that the agent can access due to its overall responsibilities. Additionally, the agent may be subtly overeager to perform certain tasks, like dropping an index to make the migration run faster.

It may even make an honest mistake, like creating new roles and grants that persist after the task ends and become backdoors into the database. Reasoning these problems at the prompt layer is extremely difficult because it entails not only the commands and grammar, but also the target state. The database remains the final execution boundary. It is the only place where one can observe what actually ran, what data and identities were affected, and what state persisted after the task is completed. 

These challenges are more benign when AI services operate on files, such as documents, source code, knowledge bases, etc. In these domains, AI risk often takes the form of exposure, corruption and leakage. Databases are different. Actions mutate authoritative, system‑of‑record state, side effects are often durable and impact system behavior, and mistakes are persistent and compounding. 

The agent layer understands intent but not effect. The database understands effect but not intent. Neither alone can safely govern the system. 

The only viable option: combining DAM and AI Security 

An effective security solution closes the loop between intent and execution by combining two complementary capabilities: 

• Execution truth, provided by DAM 
• What commands ran 
• What objects, identities, and privileges were affected 
• An immutable record of reality 
• Context and intent, provided by AI security  
• Actor classification (human, agent, pipeline) 
• Task intent 
• Expected scope and boundaries 

Together, they enable real security inspection:  

• Did execution match intent? 
• Did effects exceed task scope? 
• Did transient intent lead to a durable state? 

In the schema migration scenario, the AI security layer captures the request's intent and the user's identity, passing them along to the DAM layer as the request flows to the database. The DAM service can then detect if the tables being modified are in scope for the user or if persistent grants have been made. 

TL;DR

Monitoring without context is running blind, and context without control is toothless. In the agentic world, database security must reason across intent and execution. 

Curious how your security stack measures up? See Varonis Next-Generation DAM in action.