Database Activity Monitoring with Agents

Security Intelligence Scout is a database audit agent that reads a database’s native audit trail, enriches the records with SQL analysis, and publishes them to ALTR for database activity monitoring. Scout is the polling-based counterpart to the ALTR sidecar: it polls each database’s own audit facility on a schedule rather than intercepting traffic inline.

Scout’s captured activity surfaces alongside sidecar-captured activity in database activity monitoring — the Activity Monitoring Dashboard and Query Log. See Sidecar Integration Overview for how the two capture paths relate. In shared views such as the Activity Monitoring Dashboard, sidecar-captured and Scout-captured records aren’t currently distinguished from each other.

How Scout Works

Setting up Scout has 2 parts, completed in order:

1. Register the agent and create scan tasks in ALTRNet. Register the agent with its public key on the Agents page, then create one or more scan tasks — each task binds the agent to one target repository and a schedule.
2. Deploy the agent container. Run the Scout container on your own infrastructure with the matching private key and identity configuration. How you run the container — Docker, Kubernetes, or another method — depends on your own infrastructure; this guide doesn’t prescribe one.

An RSA keypair binds the 2 parts together: ALTRNet stores only the public half, and the container holds the private half. Generate this key pair the same way as for the sidecar — see Sidecar Authentication for the requirements and a generation example. After registration, ALTRNet displays an Agent ID, ALTR Organization ID, and Data Plane URL — the identifiers the container needs to authenticate. ALTR never receives the private key. One agent can run multiple scan tasks, each against a different repository. If you run multiple container instances under the same agent identity for redundancy, only one instance leads and scans at a time.

Validated Databases

Of the engines below, 3 are read over a database connection; PostgreSQL is read from log files on disk.

Engine	Read model	Native audit source
Oracle	Database connection	Unified Audit Trail
SQL Server	Database connection	SQL Server Audit files
PostgreSQL	Filesystem (log files)	Server statement logging
MySQL	Database connection	The general query log

Each engine needs its native auditing enabled before Scout can read anything — for example, Oracle’s Unified Auditing, a SQL Server audit and audit specification, or PostgreSQL statement logging. A dedicated database login for Scout itself (a repository service user) also needs the minimum grants to read the audit trail: on Oracle, AUDIT_VIEWER (or SELECT ANY DICTIONARY, or a direct SELECT on the audit view); on SQL Server, VIEW SERVER STATE plus either CONTROL SERVER or the narrower ALTER ANY SERVER AUDIT; on MySQL, SELECT on the audit log table. PostgreSQL tasks read log files directly and don’t use a repository service user. This repository service user is a read-only credential for Scout itself — a distinct identity from the database user whose activity a Scout record captures.

Note

Of the 4 engines, only SQL Server’s native audit source reports how many rows a query accessed. For Oracle, PostgreSQL, and MySQL, activity views that depend on rows-accessed show 0 for Scout-captured records regardless of actual activity.

Registering an Agent and Creating Scan Tasks

To register a Scout agent:

1. Log in to ALTRNet through your identity provider (IdP).
2. Select Data Configuration > Agents in the navigation menu.
3. Click Register Agent.
4. Enter a name for the agent.
5. Select Security Intelligence Scout as the Agent Type.
6. Enter the agent’s public key.
7. Click Register Agent. ALTRNet displays the agent’s Agent ID, ALTR Organization ID, and Data Plane URL, which you’ll need to deploy the container.

To create a scan task:

1. From the agent’s detail view, click New Task.
2. Enter a name for the task.
3. Select the target repository.
4. Enter a cron schedule.
5. For Oracle, SQL Server, or MySQL in database-connection mode, select a repository service user. Oracle needs no further configuration — it reads its audit trail directly over the database connection. SQL Server’s default mode also connects directly, with an optional audit-file-location override.
6. For PostgreSQL, enter an audit-file location and select a format. Use CSV or JSON format — the wizard also offers a “Log” format option, but the agent doesn’t accept it and a task created with that option won’t scan successfully.
7. Click Create Task.

For MySQL, use database-connection mode. MySQL also supports a file-based mode for reading its audit log, but the task wizard doesn’t produce a working file-based task today — choosing that storage-location option, including the file path it collects, doesn’t configure the agent correctly.

Note

The task’s schedule includes a time zone selection, but it has no effect — the agent’s schedule contract has no time zone field, so the selected value is dropped and the cron expression runs against whatever clock the deployed container’s host uses. Author schedules assuming the container’s local time, and confirm that time zone with whoever deploys the container.

From the agent’s detail view, you can also add or rotate the registered public key without downtime.

User Roles

Setting up Scout spans 3 roles, which may be the same person but have distinct responsibilities:

• DBA — enables the database’s native audit facility and creates Scout’s repository service user with the required grants (not needed for PostgreSQL).
• Portal admin — registers the agent and creates scan tasks in ALTRNet’s Agents page.
• Operator — deploys the agent container and monitors it going forward.

All three roles are filled by your own staff — there’s no ALTR-operated step in this workflow.

Monitoring

Once a task is running, monitor it on the Agents page using 2 signals:

• An agent-level stoplight — Connected, Investigate, Unavailable, or Not Connected — based on how recently the agent instance last checked in.
• A per-task status — Active, Error, or Inactive — based on the task’s own scan telemetry.

A task missing one of its required database grants shows as Error, with the specific missing permission reported. Check this first if a task isn’t delivering audit records.