What Is Database Activity Monitoring (DAM)? Monitoring Database Access and Protecting Sensitive Data

Database Activity Monitoring, in short DAM, is the data security approach that enables the accesses, queries, user activities and critical operations carried out on databases to be monitored, analyzed and where necessary evaluated as a security event. DAM, which can be expressed in Turkish as veritabanı aktivite izleme or veritabanı erişimlerinin izlenmesi, is an important security layer especially in database systems where critical and sensitive data is kept.

An organization may have encrypted the database. The user accesses may have been brought under control with IAM, PAM or RBAC. However, in order to see which queries an authorized user runs after entering the database, which tables they read, how many records they take outside or whether they access sensitive fields in an unusual way a different security layer is needed.

DAM comes into play exactly at this point.

The fundamental question of the modern Database Activity Monitoring approach is this:

"Who accessed the database, what did they do, which data did they read, how much data did they take out and was this behavior normal?"

For this reason DAM is not only collecting database logs. The real aim is to create meaningful security visibility by evaluating the database activities together with identity, data sensitivity, privilege level, query behavior and risk context.

What Is DAM?

Database Activity Monitoring is the security control that enables the activities taking place on the database to be monitored continuously or regularly.

With DAM in general these kinds of activities can be monitored:

User Login

Database Connection

SQL Query

Table Access

Column Access

Data Modification

Bulk Export

Privilege Change

Schema Change

Administrative Activity

Failed Access

operations such as these.

The aim is not only to answer the question "who logged in?".

The real aim is:

"What did they do after logging in?"

to answer this question.

Why Is Database Activity Monitoring Necessary?

Databases are generally the central repository of organizations' most critical information.

Customer information,

employee data,

financial records,

payment information,

commercial secrets,

identity information,

transaction records

are most of the time kept inside the database.

For this reason in the case of a database compromise the impact can be very high.

From the point of view of an attacker accessing the database can mean directly reaching the organization's most valuable data.

From the point of view of an authorized user, on the other hand, too much authorization can provide the possibility of access to a large amount of sensitive data.

For this reason database security must not be limited only to authentication and encryption.

What Is the Difference Between a Database Audit and DAM?

A Database Audit expresses activity records being kept over the native audit logs produced by the database.

DAM, on the other hand, tries to analyze these activities in a more central, behavioral and security-focused way.

A native database audit:

"User X carried out a SELECT on Table Y."

can say this.

DAM, on the other hand, can add these to it:

This table contains Restricted Data.

The user does not normally access this table.

The access took place at 03:00.

500,000 records were queried.

For this reason the event can be high-risk.

This context makes DAM more valuable.

Is Native Database Logging Sufficient?

Not always.

Native logging is important and necessary.

However, different database technologies produce different log formats.

In an organization:

Oracle

PostgreSQL

MSSQL

MySQL

MongoDB

different systems such as these can be present.

These logs being normalized centrally and analyzed with security context can be difficult.

DAM can provide central visibility in this heterogeneous environment.

Which Databases Does DAM Monitor?

The DAM approach can be applied in relational and some non-relational database environments.

For example:

Oracle

Microsoft SQL Server

PostgreSQL

MySQL

MariaDB

DB2

NoSQL databases

cloud databases

environments such as these can be taken into the monitoring scope.

The technical method can change according to the platform.

However, the security objective is the same:

Database activity visibility.

How Does DAM Work?

DAM can use different deployment methods.

For example:

Agent-Based Monitoring

Network-Based Monitoring

Proxy-Based Monitoring

Native Audit Log Collection

API-Based Monitoring

approaches such as these can be present.

Every method has visibility, performance and deployment trade-offs.

What Is Agent-Based DAM?

Agent-Based DAM monitors the activities using an agent on the database server or host.

This approach can provide strong visibility for encrypted local database traffic or host-level events.

Its advantage can be detailed activity monitoring.

However, it requires agent deployment and maintenance on the server.

What Is Network-Based DAM?

Network-Based DAM analyzes the database traffic over the network.

This approach can provide monitoring without installing an agent on the database server.

However, encrypted database traffic can limit the visibility.

For this reason in modern environments network-only monitoring may not always be sufficient.

What Is Proxy-Based DAM?

In the Proxy-Based DAM model the database connections are passed over a proxy.

The proxy can carry out activity inspection and policy enforcement.

This can provide strong control.

However, because it adds an inline component to the architecture availability and performance must be planned carefully.

Native Audit Log Collection

DAM platforms can collect the native audit logs of the database.

This provides a low-impact deployment.

However, the available information depends on the database configuration.

If the audit policy is not detailed enough the visibility can remain limited.

What Is SQL Activity Monitoring?

SQL Activity Monitoring expresses the SQL statements run on the database being monitored.

For example:

SELECT

INSERT

UPDATE

DELETE

ALTER

DROP

GRANT

REVOKE

statements such as these can be analyzed.

This query-level visibility is of critical value for database security.

Why Can a SELECT Query Be a Security Risk?

A SELECT can look like a read-only operation.

However, a large amount of sensitive data can be taken outside.

For example:

SELECT * FROM CUSTOMERS

this query can return millions of customer records.

For this reason not only destructive actions such as DELETE or DROP but large SELECT operations must be monitored too.

What Is Bulk Data Export?

Bulk Data Export is a large amount of database records being taken outside at once or in a short time.

This can be legitimate.

For example a reporting process can pull a large dataset.

However, an attacker or a malicious insider can use bulk export too.

For this reason DAM:

Data Volume

User Identity

Time

Table Sensitivity

Historical Behavior

must evaluate this context.

Is a Large Query Always an Attack?

No.

A BI application can read 10 million records every night.

This can be normal.

If the same operation is carried out by a standard employee account at 03:00 at night it must be evaluated differently.

For this reason static thresholds are not sufficient on their own.

A behavioral baseline is required.

What Is Database Anomaly Detection?

Database Anomaly Detection tries to detect the behaviors outside the normal database activity patterns.

For example a user normally:

Finance tables

works on these.

One day:

HR Salary Table

runs a query on this.

This can be unusual access.

In a similar way login time, query volume and source location can be an anomaly signal too.

How Is User Behavior Analytics Used for the Database?

Behavior analytics can learn the normal access patterns of users.

For example:

User A normally queries 100–500 rows/day.

If one day they query 1.5 million rows the risk score can be raised.

This is the DAM + UEBA approach.

Sensitive Table Monitoring

Every table is not at the same risk level.

For example:

Public Product Catalog

and:

Customer Credit Card Table

must not have the same monitoring priority.

Data Classification provides critical context here.

For Restricted tables stricter alerting can be applied.

Sensitive Column Monitoring

The whole of the table may not be sensitive.

For example inside a customer table:

Name

Email

Identity Number

Credit Card

fields can be present.

Credit Card and Identity Number can carry higher sensitivity.

Column-level monitoring can evaluate this access separately.

DAM and Data Classification

Data Classification seriously increases the meaning of the DAM alerts.

For example:

User accessed Table X

provides information on its own.

However:

User accessed Restricted Customer Data

is much more meaningful.

For this reason DAM must be integrated with data classification context as much as possible.

DAM and Data Discovery

Data Discovery determines the sensitive tables and columns.

DAM, on the other hand, monitors who accesses this data.

These two layers together:

Where is sensitive data?

and:

Who is using it?

answer these questions.

Who Is the DBA?

The DBA, that is the Database Administrator, is the technical role responsible for the installation, performance, backup, access and maintenance processes of the databases.

The DBA generally has high permissions.

For this reason in terms of database security they must be evaluated as a privileged identity.

Why Are DBA Authorizations Risky?

The DBA can need broad access for the system to work.

However, these permissions can also provide access to sensitive data.

For example the DBA:

salary records

customer data

financial information

can see these.

Technical authorization and business authorization are not the same thing.

For this reason DBA activities must be monitored.

What Is Privileged DBA Monitoring?

Privileged DBA Monitoring is the activities carried out by highly authorized database administrators being monitored in a detailed way.

Especially these actions are important:

User Creation

Privilege Grant

Audit Disable

Table Export

Bulk SELECT

Schema Modification

Data Deletion

These events can be high-risk.

Can the DBA Disable the Audit?

If a DBA who holds broad privilege can make a change on the audit configuration the log visibility can be affected.

For this reason audit controls must be protected with the separation of duties principle as much as possible.

The database administrator and security monitoring administrator roles can be separated.

Why Is Separation of Duties Important in Database Security?

If a single user:

Database Administrator

Audit Administrator

Security Administrator

if they have these roles a big risk can be created.

The user can both carry out an activity and change the logs.

For this reason duties separation must be applied.

How Do DAM and PAM Work Together?

PAM controls the privileged access session.

DAM, on the other hand, monitors the SQL activity carried out inside the database.

For example:

PAM:

The DBA login session started.

DAM:

The DBA ran SELECT * FROM CUSTOMER.

This combined visibility provides strong accountability.

Are PAM Session Recording and DAM the Same Thing?

No.

PAM can carry out screen or terminal session recording.

DAM sees the database-level query activity.

PAM provides the user activity context.

DAM provides the data-level activity context.

For this reason they complement each other.

Just-in-Time DBA Access

DBA accounts do not have to carry permanent privileged access.

Over PAM:

On-Demand Access

Approval

Time-Limited Session

can be provided.

DAM, on the other hand, can monitor the query activities throughout this session.

This is the Zero Standing Privilege approach.

Database Service Account Monitoring

Not only humans access the database.

Applications and services use service accounts too.

These accounts can have large data access.

Query behavior different from normal can be a compromise indicator.

DAM must monitor machine identities too.

Why Is an Application Account Risky?

If the application database credential is compromised the attacker can reach the data the application can access.

This account is generally continuously active and because of automation a high query volume can look normal.

For this reason the baseline is of critical importance.

Shared Database Account

If more than one person uses the same database account accountability is lost.

For example:

dbaadmin

if 5 different DBAs use this account it is difficult to understand which person ran which query.

For this reason individual identities or PAM-based checkout must be used.

Database Login Monitoring

Database login events are among the fundamental security signals.

For example:

Failed Logins

New Source IP

Unusual Login Time

New Application

patterns such as these can be monitored.

However, login monitoring is not sufficient on its own.

Post-login behavior must be analyzed too.

Failed Database Login

A large number of failed logins can be a credential attack indicator.

However, a misconfigured application can create the same pattern too.

For this reason context is important.

DAM and SIEM correlation can support this distinction.

Database Brute Force

An attacker can apply brute-force or password spraying on database credentials.

Repeated failed authentication must be detected.

A firewall or database access control can block this source.

Why Is Direct Database Access Risky?

Business users must access the data over the application as much as possible.

Direct SQL access can provide broad visibility.

For this reason direct database access must be limited only to the necessary technical users.

Production Database Access

Production databases carry especially high risk.

If developers or analysts access production directly sensitive data exposure can increase.

Where possible:

Read Replica

Masked Data

Test Environment

can be used.

Must Production Data Be Used in the Test Environment?

Real production data must not be copied into test environments uncontrolled.

A test environment generally has a lower security level.

Static Data Masking or synthetic data can be preferred.

DAM can monitor sensitive data usage in test environments too.

Database Data Masking

DAM and masking are different controls.

DAM monitors the activity.

Masking limits the user seeing the sensitive value.

For example a standard support user:

****1234

sees this.

The DBA can see the full value.

This provides role-based exposure reduction.

Dynamic Data Masking

Dynamic masking masks the sensitive fields in the query result according to the authorization level of the user.

This is important for database access security.

DAM can monitor which user accesses masked or full data.

The Relationship Between Database Encryption and DAM

Database encryption provides protection against a storage compromise.

DAM, on the other hand, monitors the active database usage.

Even if the database is encrypted an authorized query returns plaintext data.

For this reason DAM is the complement of encryption.

Does TDE Take the Place of DAM?

No.

Transparent Data Encryption protects the data files.

However, when the user runs a normal SQL query the database engine decrypts the data.

DAM monitors this query.

These two controls are aimed at different threat scenarios.

What Is a Database Firewall?

A Database Firewall can apply a security policy on SQL traffic.

Certain queries or source connections can be blocked.

While DAM carries out monitoring a database firewall can provide enforcement.

Some architectures can offer these capabilities together.

SQL Injection and DAM

SQL Injection can cause malicious database queries to be run over the application.

DAM can help to detect unusual query patterns.

For example while the application normally uses a certain query structure suddenly an unusual UNION or metadata query can run.

However, the main layers of SQL Injection prevention are secure coding, parameterized queries and application security.

DAM provides a detection layer.

Database Enumeration

After an attacker accesses the database they can try to gather information about the schemas, tables and columns.

System metadata queries can be unusual for a normal user.

DAM can detect enumeration behavior.

Schema Change Monitoring

On the database schema:

CREATE

ALTER

DROP

commands such as these can be high-impact.

These changes must be monitored within the scope of configuration management.

An unexpected schema change can be a malicious activity indicator.

Why Is DROP TABLE a Critical Event?

DROP TABLE can create a serious effect in terms of data availability and integrity.

For this reason in the production environment a high severity alert can be produced.

However, it can be an approved maintenance event.

Change management context can enrich the alert.

Privilege Escalation Monitoring

Inside the database a user can try to increase their own privileges.

For example GRANT DBA or an equivalent privilege.

This is a high-risk activity.

DAM must monitor privilege changes.

New User Creation

New database user creation must be monitored in terms of security.

Attackers can create an account for persistence purposes.

New users can be correlated with approved change records.

Audit Configuration Changes

Audit logging being disabled or its scope being reduced is a critical security event.

This can be a tamper attempt indicator.

DAM must try to detect these changes.

Log Tampering

An attacker can try to change the logs in order to delete their tracks.

For this reason the logs must be sent to a centralized and tamper-resistant environment as much as possible.

The SIEM is important here.

DAM and the SIEM

DAM produces database activity telemetry.

The SIEM this:

EDR

IAM

PAM

Firewall

Cloud

can correlate it with these signals.

This provides attack chain visibility.

DAM + SIEM Example Scenario

For example:

The identity system detects a suspicious login.

↓

EDR gives an endpoint compromise alert.

↓

DAM sees a bulk SELECT on the customer table.

↓

DLP detects an external upload.

These events can look separate on their own.

SIEM correlation can evaluate them as the same data breach attempt.

DAM and the SOC

High-risk database alerts must be integrated into the SOC process.

However, all the queries must not be a SOC alert.

Risk-based use cases must be created.

For example:

Restricted Table

Privileged User

Bulk Export

Unusual Time

=

Critical Alert.

DAM Use Cases for the SOC

Example DAM SOC use cases:

Unusual DBA Access

Mass Sensitive Data Export

Failed Login Burst

Audit Disable Attempt

Privilege Escalation

New Database User

High-Risk Query

Access from Unknown Source

Restricted Table Access

After-Hours Data Extraction

can be these.

DAM Alert Fatigue

If every SELECT query creates an alert DAM becomes unusable.

For this reason:

Baselining

Whitelisting

Risk Scoring

Data Classification

Behavior Analytics

must be used.

The aim is not to collect logs but to produce high-value detection.

Database Activity Baselining

The profile of normal database behavior can be produced.

For example an application:

which tables does it access?

in which hours?

how much data does it pull?

which query types does it use?

Deviations outside this baseline can trigger an investigation.

The Difference Between a Static Rule and a Behavioral Rule

A static rule:

"If the DBA accesses the salary table, alert."

A behavioral rule:

"The user has not accessed the salary table at all in the last 90 days, today they read 500k records."

The second rule can be more contextual.

The best model can use the two together.

Database Risk Scoring

The risk score can be created over these factors:

User Privilege

Data Classification

Query Type

Data Volume

Time

Source

Historical Behavior

Device Risk

This is the contextual DAM model.

Data Volume Monitoring

Data volume is important for data exfiltration detection.

For example if the query result contains 10 million rows instead of 10 rows the risk can increase.

However, the thresholds must be determined according to the business process.

Result Set Monitoring

Certain DAM architectures can provide visibility about the query result size.

This is valuable for mass extraction detection.

For example while a user normally makes a small query they can suddenly receive a huge result set.

Sensitive Data Query Monitoring

If sensitive columns or tables are referenced inside the query text the risk score can be increased.

This is classification-aware query monitoring.

Database Access Governance

DAM can feed not only detection but the governance processes too.

For example a user has an access permission to a database but has not used it for 12 months.

This can be a revoke candidate during the access review.

Actual usage data can be used for entitlement optimization.

DAM and IGA

IGA manages the configured permissions.

DAM shows the actual usage.

This information together:

User has access

but:

Never uses access

can create this finding.

This provides Least Privilege optimization.

Unused Database Privileges

Unused privileges increase the attack surface.

For example a user has UPDATE permission but only uses SELECT.

Permission right-sizing can be carried out.

This is the continuous Least Privilege approach.

Database Role Review

Database roles can become broad over time.

For example a new privilege is added to a role and hundreds of users gain it automatically.

DAM can help to validate the role design with the actual activity.

DAM and DSPM

DSPM shows the sensitive data location and the exposure risk.

DAM shows the actual access activity.

DSPM:

"Restricted data is here."

DAM:

"This identity is reading this data."

This combination is very valuable in terms of Data Security.

DSPM + DAM Risk Scenario

For example DSPM:

Customer database contains Restricted PII.

In addition:

500 users have access.

DAM, on the other hand:

User X performed 2 million row export.

This combined risk is much more meaningful.

DAM and DLP

DAM sees that the data has been taken out of the database.

DLP sees where the data is sent over the endpoint or the network.

For example:

DAM:

Bulk export detected.

DLP:

File uploaded to personal cloud.

This provides end-to-end exfiltration visibility.

Database-to-Endpoint Data Flow

Sensitive data is most of the time exported from the database to the endpoint.

At this point DAM monitoring ends on the database side.

DLP continues the protection on the endpoint side.

For this reason a layered architecture is required.

DAM and Data Lineage

Data lineage can show to which downstream systems the data has been transferred from the database.

When DAM actual access and lineage are combined the data movement can be understood better.

This is important especially for analytics environments.

Cloud Database Monitoring

Cloud databases can use different visibility models from traditional on-prem databases.

Examples:

Managed SQL

Cloud Data Warehouse

Serverless Database

In these environments native logs, APIs and cloud telemetry are important.

The DAM architecture must support cloud-native monitoring capabilities.

The AWS, Azure and Google Cloud Database Security Logic

Regardless of the cloud provider the fundamental questions are the same:

Who connected?

Which identity?

Which query?

Which data?

How much data?

Which network source?

Is there encryption?

Are the logs central?

Cloud-native database security must answer these questions.

Serverless Database Monitoring

Serverless databases can have the infrastructure layer managed by the provider.

Traditional host agent deployment may not be possible.

For this reason API, native audit and cloud telemetry based monitoring is required.

Data Warehouse Monitoring

Data warehouses can contain sensitive information in a very large volume.

Analytics users can have wide read access.

A mass query can be normal here.

For this reason behavior baselines must be created according to the user role and the workload.

Data Lakehouse and Database Activity

Modern analytics architectures can query a data lake or lakehouse over SQL interfaces.

These environments require DAM-like monitoring too.

The traditional database boundary is disappearing.

Big Data Access Monitoring

Large-scale analytics platforms can keep central copies of sensitive data.

User queries and export operations must be monitored.

Data Discovery and classification provide critical context here.

Database Secrets Security

Database credentials must not be kept as plaintext inside the source code or config files.

A secrets manager must be used.

DAM can detect unusual connection behavior but credential protection is a preventive control.

Passwordless Database Authentication

In modern environments database access:

certificate,

federated identity,

temporary token,

managed identity

can be done over these.

This can reduce the long-lived passwords risk.

The DAM identity mapping must be done correctly.

Database Identity Federation

When the enterprise identity system and database authentication are integrated accountability increases.

The user connects with an individual identity.

Shared DB credentials decrease.

This provides a strong foundation for IAM and DAM integration.

Service Account Password Rotation

Application database credentials must not stay unchanged for a long time.

Secrets management rotation can be applied.

However, application availability must not be affected.

Automation is important.

Database Connection Encryption

Besides DAM database activity data in transit protection is important too.

The connection between the application and the database must use TLS.

The internal network must not be trusted.

Why Is TLS Important in Database Security?

Unencrypted database traffic can expose credentials or sensitive data with network sniffing.

For this reason database protocols must be protected with TLS as much as possible.

However, encrypted traffic can affect network-based DAM visibility.

The architecture must be chosen accordingly.

Database Backup Monitoring

Database security is not limited only to the live database.

Backups contain a large amount of sensitive data.

Backup creation, restore and export activities must be monitored.

An unauthorized restore can create data exposure.

Why Is a Database Restore Risky?

A user can restore the production backup to a test server.

The test server can have a lower security level.

This can create data leakage.

Restore operations must be under approval and monitoring.

Snapshot Security

Cloud database snapshots contain sensitive data.

Snapshot public sharing or cross-account sharing is risky.

DSPM/CSPM can analyze the snapshot posture.

While DAM monitors the live activity snapshots must be taken into the governance scope separately.

Database Clone Risk

Modern cloud databases can create a clone quickly.

This provides developer productivity.

However, sensitive data copies can multiply quickly.

Clone creation must be controlled with governance and masking.

What Is a Shadow Database?

Database instances that are not in the Security Team's inventory can be thought of as a Shadow Database.

A developer can create a temporary database.

Sensitive production data can be copied.

Data Discovery must find these unknown repositories.

DAM can be effective only on known databases.

DAM and Shadow Data

When the data exported from the database turns into a file DAM visibility can be lost.

For this reason Shadow Data discovery and DLP are required.

The Data Security lifecycle must go beyond the database boundary.

DAM and Insider Threat

A malicious insider can be an authorized database user.

An authentication bypass is not required.

For this reason DAM provides important telemetry for insider risk.

For example:

Employee

Notice Period

Bulk Customer Export

After-Hours Activity

can be high-risk.

Departing Employee Database Activity

If an employee who is about to leave the job is carrying out unusual database access additional monitoring can be applied.

However, privacy and employment policies must be taken into account.

Risk controls must be under appropriate governance.

Contractor Database Access

External consultants can receive temporary database access.

This access:

Time-Bound

Approved

Least Privilege

Monitored

must be these.

DAM can provide high visibility for contractor activity.

Third-Party Application Access

If a third-party application establishes a direct connection to the database a supply chain risk is created.

A credential compromise can create data exposure over the provider.

Third-party connections must be in the inventory.

Database Query Allowlisting

In highly controlled environments applications can run only expected query patterns.

Unexpected SQL patterns can be alerted or blocked.

This can be applied with a database firewall or advanced DAM capabilities.

Must Query Blocking Be Carried Out?

Inline enforcement is risky.

A wrong positive can block a critical business query.

For this reason blocking must be used only for well-tested high-confidence rules.

Most use cases can start with monitoring + response.

The Performance Effect in DAM Deployment

Database monitoring can create a load on the performance.

Especially detailed auditing can be costly on high-volume systems.

For this reason:

Scope

Sampling

Audit Levels

Infrastructure Sizing

must be planned carefully.

Is Audit Everything the Correct Approach?

Logging everything with maximum detail can create storage and performance problems.

A risk-based audit can be healthier.

For example Restricted schemas can be monitored in more detail.

Public reference data can be at a lower logging level.

Log Retention

How long database activity logs will be kept must be determined with a policy.

Security investigation, compliance and operational requirements must be taken into account.

Because the logs can contain sensitive information they must be protected too.

Can DAM Logs Contain Sensitive Data?

Yes.

Personal data or credentials can be present inside the query text.

For this reason the logs:

Encryption

Access Control

Retention

must be protected with these.

The monitoring system must not be a new data leakage source.

DAM Platform Security

The DAM platform can keep very critical telemetry and in some cases sensitive query data.

For this reason DAM administrative access can be under PAM.

MFA, RBAC and audit must be applied.

Monitoring the Monitor

The configuration changes made on the DAM platform must also be logged.

Who changed a rule?

Who disabled an alert?

Who exported data?

This meta-monitoring provides accountability.

AI and Database Activity Monitoring

As AI applications and AI Agents start to carry out database access DAM is being forced to monitor a new identity class.

Now not only:

Human User

and:

Application Account

but:

AI Agent

can also run a database query.

AI Agent Database Access

An AI Agent can convert a natural language request into a SQL query.

For example a user:

"Bring me all the customers."

says this.

The agent can run a wide SELECT.

This can create an authorization and data leakage risk.

DAM must monitor agent queries separately.

The Text-to-SQL Risk

Generative AI Text-to-SQL capabilities make database access easier.

However, the model can produce a wrong or overly broad query.

For example instead of the necessary 10 records it can pull the entire table.

For this reason query validation and Least Privilege are important.

Database Least Privilege for an AI Agent

The database role of the AI Agent must be task-specific.

A reporting agent:

SELECT

can receive this permission.

However:

DROP

DELETE

GRANT

must not receive these permissions.

This is the Agentic Least Privilege approach.

AI Agent Query Guardrails

Guardrails can be applied on agent-generated queries.

For example:

No DELETE

No DROP

Row Limit

Restricted Table Deny

Human Approval for Bulk Query

controls such as these can be present.

DAM monitors the actual query activity after these guardrails.

The AI Agent Bulk Export Risk

An AI Agent because of automation can take out a very large data volume very quickly.

It can do an operation that would take a human user hours within seconds.

For this reason rate limits and data volume controls gain importance.

RAG and Database Monitoring

RAG systems can carry out retrieval not only over vector databases but over relational databases too.

Permission-aware retrieval must be applied.

DAM can log which data the model or the retrieval service accesses.

AI Query Attribution

If the AI system connects to the database with a service account which end-user's request triggered the query must be logged.

Otherwise all the activity appears under a single service account.

This attribution problem will be critical for the new generation of DAM.

Agent Identity + User Identity

The ideal log context can contain this information:

End User

AI Agent

Service Account

Database

Query

Data Classification

This chain provides accountability.

AI Data Exfiltration

An AI Agent can pull data from the database and send it to an external API.

DAM sees the database extraction.

DLP or API monitoring sees the outbound transfer.

For this reason AI Data Security requires multi-layer monitoring.

How Is a Database Activity Monitoring Project Started?

The first step is to create a database inventory.

Which databases are there?

Which of them are production?

Which of them contain sensitive data?

Who accesses them?

Which database technologies are used?

After this visibility the monitoring scope can be determined.

Starting from the Crown Jewel Databases

All the databases do not have to be taken into the DAM scope at the same time.

First:

Customer Databases

HR Databases

Financial Databases

Identity Stores

Payment Databases

crown jewel systems such as these can be taken.

This provides a risk-based rollout.

Creating a DAM Policy

For every database the important use cases must be determined.

For example:

Bulk Export

Privileged Activity

Sensitive Table Access

Failed Authentication

Privilege Escalation

Audit Disable

Schema Change

The rules are created accordingly.

Monitor Mode

DAM can work monitoring-only at the beginning.

The normal activity baseline is produced.

False positives are determined.

Afterwards high-confidence alerts are created.

If inline blocking is going to be used it must be passed to very controlled.

DAM Tuning

The database workload can change over time.

A new application can be added.

A new reporting job can be created.

For this reason DAM policies must be tuned continuously.

A static rule set can become ineffective over time.

DAM Incident Response

For a high-risk DAM event a playbook must be created.

For example:

Detect

↓

Validate Query

↓

Identify Identity

↓

Check PAM Session

↓

Check Endpoint / EDR

↓

Assess Data Volume

↓

Check DLP

↓

Contain Account

↓

Preserve Logs

↓

Investigate Data Exposure

This provides a coordinated response.

Bulk Export Incident Playbook

For example DAM detected a 2 million customer record export.

The Security Team can ask these questions:

Is this user authorized?

Is this workload normal?

Where was the export file written?

Did DLP see an external transfer?

Is there a PAM session approval?

Is there an identity risk signal?

These questions separate a true incident from a legitimate business operation.

DAM KPIs

The Database Security programme must be measurable.

Example KPIs:

Databases Under Monitoring

Sensitive Databases Covered

Privileged Accounts Monitored

Bulk Export Alerts

Restricted Table Access Alerts

Failed Login Events

Privilege Escalation Attempts

Audit Configuration Changes

High-Risk Query Count

Unusual After-Hours Access

Database Activity Alerts Investigated

False Positive Rate

Mean Time to Investigate

Unused Database Privileges

Shared Database Accounts

Unknown Database Identities

AI Agent Database Activity

metrics such as these can be these.

DAM Coverage KPI

What percentage of the critical databases is under monitoring?

This is a fundamental maturity indicator.

For example if only 10 of 50 critical databases are within the DAM scope there is a visibility gap.

Privileged Monitoring Coverage

How much of the DBA and service privileged identities is being monitored?

This must be measured separately.

Even if the critical databases are monitored if there is no privileged user attribution the visibility can remain incomplete.

False Positive Rate

If DAM produces too many false positives analyst trust decreases.

For this reason rule tuning is an important KPI.

The aim is not minimum alerts but maximum useful signal.

Mean Time to Investigate

How quickly are database security events investigated?

If a mass data extraction event stays open for hours the damage can increase.

SOC integration can reduce this time.

The Most Frequently Made Mistakes in Database Activity Monitoring

The most common mistake is seeing DAM only as an audit log collection project. The real value appears with behavior, data sensitivity and identity context.

The second mistake is monitoring only DBA accounts. Application accounts, service accounts and standard users can carry out sensitive data extraction too.

The third mistake is evaluating all the queries at the same risk level.

The fourth mistake is not establishing integration with Data Classification.

The fifth mistake is isolating DAM from DLP, PAM, SIEM and DSPM.

The sixth mistake is continuing to use shared database accounts.

The seventh mistake is leaving cloud databases outside the traditional monitoring scope.

The eighth mistake is losing the database access of AI Agents and Text-to-SQL applications inside normal service account traffic.

The ninth mistake is not protecting the logs themselves sufficiently.

DAM Checklist

• Is a corporate database inventory present?
• Have the critical databases been determined?
• Have the databases containing sensitive data been classified?
• Is Database Activity Monitoring being applied?
• Is native audit logging active?
• Is SQL activity being monitored?
• Are SELECT queries being evaluated risk-based?
• Is bulk data export being detected?
• Are sensitive tables being monitored?
• Are sensitive columns being monitored?
• Are DBA activities being monitored in detail?
• Are privileged database users in the inventory?
• Have shared database accounts been reduced?
• Are service accounts being monitored?
• Are application accounts under a baseline?
• Are failed database logins being monitored?
• Are privilege escalation alerts present?
• Are user creation events being monitored?
• Are GRANT/REVOKE activities being monitored?
• Are schema changes being monitored?
• Do high-risk queries such as DROP and DELETE produce an alert?
• Are audit disable attempts being detected?
• Are there log tampering controls?
• Are the DAM logs centralized?
• Are the DAM logs encrypted?
• Is PAM integration present?
• Is JIT DBA access being used?
• Is there SIEM integration?
• Are the SOC use cases defined?
• Is DLP integration present?
• Is DSPM providing sensitive data context?
• Is IGA using the unused access findings?
• Is database encryption being applied?
• Is TLS being used for database connections?
• Has production database access been limited?
• Is test data masking being applied?
• Are the database backups being protected?
• Are snapshot and clone creation being monitored?
• Are cloud databases in scope?
• Are serverless databases being monitored?
• Are data warehouses in scope?
• Is the database activity of AI Agents being monitored?
• Are there guardrails for Text-to-SQL use cases?
• Is the AI Agent using a unique identity?
• Is end-user to AI-agent attribution being kept?
• Is there a limit for bulk AI queries?
• Is a DAM Incident Response playbook present?
• Are the DAM KPIs being followed regularly?

DAM Maturity Model

Level 1 – Basic Database Logging: Native logs are kept in a limited way. There is no central security analysis.

Level 2 – Central Database Monitoring: Critical databases are taken into the central DAM or SIEM scope. DBA and high-risk SQL activity are monitored.

Level 3 – Data-Aware DAM: Integration is established with Data Classification, PAM, DLP and IGA. Sensitive table and column access is evaluated risk-based.

Level 4 – Behavioral Database Security: User, service account and workload baselines are created. Anomaly detection and risk scoring are applied. Cloud databases are monitored comprehensively.

Level 5 – Adaptive Database Data Security: Human, machine and AI Agent database activities are evaluated with real-time identity, data sensitivity, behavior and endpoint risk context. Access, query and exfiltration controls are managed inside a common security architecture.

This transformation:

Database Logging

↓

Database Monitoring

↓

Data-Aware Monitoring

↓

Behavioral DAM

↓

Adaptive Database Security

proceeds in this way.

Frequently Asked Questions

What is DAM?

DAM is the abbreviation of the expression Database Activity Monitoring and is the database security approach that enables the user, application and SQL activities carried out on databases to be monitored.

What is Database Activity Monitoring?

Database Activity Monitoring is activities such as database login, SQL query, table access, bulk export, privilege change and administrative operations being monitored for security purposes.

What does DAM do?

DAM makes visible which user accesses which database, which queries they run, which sensitive data they access and whether there is unusual data extraction behavior.

What is the difference between a Database Audit and DAM?

A Database Audit produces the native database logs. DAM analyzes these logs and activity telemetry with security context, behavior analytics and data sensitivity.

What is DBA Monitoring?

DBA Monitoring is the login, SQL query, configuration and data access activities of highly authorized Database Administrator accounts being monitored.

What is SQL Activity Monitoring?

SQL Activity Monitoring is SQL statements such as SELECT, INSERT, UPDATE, DELETE, ALTER, DROP and similar being monitored and analyzed in terms of database security.

What is Bulk Data Export?

Bulk Data Export is a large amount of database records being taken outside in a short time. It can be legitimate business use or a data exfiltration indicator.

What is the difference between DAM and PAM?

PAM manages the privileged session and account access. DAM monitors the query and data access activities carried out inside the database.

What is the difference between DAM and DLP?

DAM sees the access and extraction activity inside the database. DLP controls where the extracted data is carried over e-mail, USB, web or cloud.

What is the difference between DAM and DSPM?

DSPM analyzes where the sensitive data is located and which exposure risks it carries. DAM, on the other hand, monitors the real database access activity carried out on this data.

Must DAM and SIEM be used together?

Yes. DAM provides database telemetry, the SIEM can correlate this telemetry with other security signals such as identity, EDR, firewall, PAM and DLP.

Does DAM detect insider threat?

DAM can support insider threat detection by making visible the unusual sensitive data access and bulk extraction behaviors carried out by authorized users.

Does database encryption take the place of DAM?

No. Encryption protects the data on the storage. When an authorized query is run the data is decrypted. DAM monitors this active usage.

Must AI Agent database accesses be monitored?

Yes. Because AI Agents can query a large amount of data automatically a unique identity, Least Privilege, query guardrails and DAM monitoring must be applied.

Does Text-to-SQL create a security risk?

It can create one. SQL queries produced by AI can create wider data access than expected or dangerous database operations. Authorization, query validation and monitoring are necessary.

Conclusion: Giving Access to the Database and Knowing What Is Done in the Database Are Not the Same Thing

One of the most important misconceptions of modern database security is thinking that when correct authentication and authorization are applied the database is completely safe.

The user can be authorized.

The DBA can be authorized.

The application account can be authorized.

The AI Agent can be authorized.

However, every operation the authorized identity does is not automatically safe.

For this reason database security must separate these two questions from each other:

"Can this person or system access the database?"

and:

"What do they do after accessing?"

IAM, RBAC and PAM manage the first question.

DAM provides visibility for the second question.

This visibility becomes more valuable when it is combined with Data Classification.

Because:

User accessed table

and:

Privileged user exported 2 million records from Restricted Customer Data

are not the same security information.

The real value of modern DAM is this context.

For this reason a strong Database Security Architecture:

Data Discovery

Data Classification

Database Encryption

IAM / PAM

Database Activity Monitoring

DLP

DSPM

SIEM / SOC

relies on these layers working together.

In the future the importance of this architecture will increase even more.

Because not only humans or classic applications will access the databases.

AI Agents will produce SQL queries from natural language commands, RAG systems will carry out retrieval from databases and automation engines will carry out operations on a very large amount of data.

For this reason the new generation of DAM must be able to answer this question:

"Which human, application, service account or AI Agent accessed which sensitive data, with which query, in what amount, with which purpose and inside which risk context?"

And the most important sentence of this chapter:

Database Activity Monitoring is the fundamental monitoring layer of modern Data Security that makes visible not only who can access the database; but which identity, whether human, application or AI Agent, accesses which sensitive tables and fields, which SQL operations they carry out and unusual data extraction behaviors in a real-time security context.