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. For a Snowflake Agent Repository, Running Security Intelligence Scout in Snowpark Container Services covers running the container inside the monitored account instead.

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, only PostgreSQL is read from log files on disk; the rest are read over a database connection.

Engine	Read model	Native audit source
Oracle	Database connection	Unified Audit Trail
SQL Server	Database connection	SQL Server Audit files
PostgreSQL	File system (log files)	Server statement logging
MySQL	Database connection	The general query log
Snowflake	Database connection	SNOWFLAKE.ACCOUNT_USAGE query and login history

Every engine except Snowflake 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.

Snowflake works differently from the other engines: its activity is already recorded in SNOWFLAKE.ACCOUNT_USAGE, so nothing needs enabling on the account, and Scout’s read is authorized by a Snowflake role holding IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE, which only ACCOUNTADMIN can grant. A Scout deployed outside the account reaches that role through a repository service user’s credential, as it does on the other engines. One deployed inside the account as a container service instead runs as the role that owns the service, which removes the Snowflake credential entirely – see Running Security Intelligence Scout in Snowpark Container Services.

Note

Of the engines, only SQL Server reports how many rows a query accessed. For Oracle, PostgreSQL, MySQL, and Snowflake, 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 Settings > 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 expression in Task Schedule (Cron Expression).
5. Set Audit Import Start Date – the earliest activity the task’s first scan reads. The wizard treats it as optional, but set it: a task created without one puts no lower bound on its first scan, and the value can’t be added later – correcting it means removing the task with Delete Task in its edit view and creating it again.
6. For Oracle, SQL Server, or MySQL in database-connection mode, select a 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.
7. For Snowflake, select a Service User unless the scout runs inside the account as a container service – that deployment authenticates with the token Snowflake mounts into the container and needs no credential here. Then select the Account Usage View the task reads – Query History (statements) or Login History (connections). A task reads one view, so create a second task for the other kind. The start date in step 5 matters most here: Snowflake retains account activity for 365 days, and a first scan with no lower bound reads all of it, which can outrun the scan’s own timeout and leave the task delivering nothing.
8. 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.
9. 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. PostgreSQL needs only the former – it reads log files directly and doesn’t use a repository service user. Snowflake has no audit facility to enable, and its grants go to a Snowflake role.
• 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.