Datastores

Datastores is the inventory: every bucket, table, database, and cluster Argus has found, what is inside it, and how dangerous that combination is. It has three tabs - Datastores, Classification, and Analytics - which are the same population viewed three ways: one row per resource, one row per set of findings, and one chart per distribution.

The concepts behind the numbers live in Discovery & scanning, Classification, and Risk engine. This page is about the screen.

Getting datastores into the inventory

Discover Datastores in the page header picks a connected account, shows which resource types it will look for, and dispatches the discovery job. A progress banner tracks it and the table fills in as results land. You can also run discovery from a row action on Cloud Accounts, or let the account’s schedule do it.

If a previously known datastore is missing from the latest discovery run, a dismissible notice appears above the tabs naming the affected datastores. Dismissing it is per-datastore and sticks across reloads, but a resource that disappears again re-surfaces the notice, so a second deletion is never silently swallowed.

Tab 1: Datastores

The inventory table, and where most of the work happens.

Summary cards

Total Datastores, Scanned, Sensitive Data, High Risk, and Total Size. All five describe the filtered set, not the whole tenant, so they recalculate as you narrow the table. That is what makes them useful: filter to one account and one region and the cards answer for that slice.

Filters

Search matches the datastore name. The filter chips cover Type, Status, Provider, Region, and Risk Level, all multi-select and stacking. Export writes the current filtered set to CSV with name, type, account, region, size, risk level and score, whether sensitive data was found, last scan, and status.

Two Status options behave differently from the rest, because they control visibility rather than just filtering:

Hidden - hidden datastores are excluded from the default view. Pick this option to see them.
Not Found - a datastore that disappeared shows greyed in the default view during its grace window and then drops out. Pick this option to see all of them regardless of age.

Both hidden and not-found rows render at reduced opacity so you can never mistake one for a live resource. Where a datastore is both hidden and not found, Not Found wins: a deleted resource is described as deleted.

Columns

Column	Notes
Datastore	Name, type icon, and inline Sensitive / Public badges. Azure resources also show their resource group.
Type	S3 bucket, RDS instance, DynamoDB table, Redshift cluster, Azure Blob container, and so on.
Provider, Region, Account	Where it lives.
Size, Objects	As reported at discovery.
Risk Level	Band badge plus the score out of 100. Reads Not scanned until a scan has completed, rather than showing a misleading zero.
Categories	The sensitive-data categories detected inside it.
Status	The lifecycle state, live: a row flips to Scanning and back on its own while a scan runs.
Last Scan	Relative time, or Never.

Statuses are shared across the product and collected in Discovery & scanning.

Row actions

The inline button is the primary action for that row’s state:

Scan on a normal datastore, with live progress in place.
A key icon on a datastore in Needs Credentials, which opens the credential dialog. Database engines cannot be scanned until they have connection details.

The kebab holds the rest: Open in AWS Console (or Azure Portal), Force re-scan, and Hide datastore. A hidden row offers only Unhide. A not-found row offers nothing at all: the resource is gone, so every action would be a no-op.

Bulk actions

Select rows to get a bulk bar with Scan selected, Force re-scan, Hide selected, and Unhide selected. Hide and Unhide only appear when the selection actually contains rows in that state. Not-found rows cannot be selected.

What hiding does

Hiding is how you tell Argus a datastore is not worth governing: a known-good infrastructure bucket, a decommissioned resource, an accepted risk. It is a real posture decision, so it is deliberately more than a view filter. A hidden datastore is:

filtered out of the default view,
skipped by auto-scan,
excluded from compliance, risk, and report metrics,
and has its active alerts suppressed.

A reason is required, recorded against the datastore, and shown in the detail drawer alongside who hid it and when. Unhiding reverses all of it: the datastore returns to the default view, resumes scanning, and its suppressed alerts reactivate.

What force re-scan does

A normal scan of an object store is incremental: it re-checks new and changed objects and trusts its cache for the rest. Force re-scan bypasses that cache and re-reads every object. Use it when you have reason to believe the cache is stale, for example after restoring objects in place or changing something that would not alter an object’s modified time.

It costs real time and money, so the bulk version asks for confirmation and tells you how many of the selected datastores it will actually affect. Only S3 buckets and Azure Blob containers have an incremental cache; anything else in the selection simply scans normally.

Tab 2: Classification

The findings view: what sensitive data was actually detected, and how confident Argus is.

Category tiles run across the top, one per detected category. Each shows the number of findings, how many datastores contain them, and a bar for the share of those findings that are high confidence. Tiles are toggles: click to filter the table below, click several to require all of them.

Three charts sit underneath:

Findings by Category - the volume mix across categories.
Top Datastores by Findings - the concentration. A single datastore holding most of a category is a very different problem from the same count spread across forty.
Detection Confidence - the High, Medium, and Low split across all findings.

Read the confidence donut before you act on the counts. A large low-confidence share usually means the data is unstructured or the sample was thin, not that you have a large exposure. The distinction is explained in Confidence scoring.

The Classified Datastores table below lists only datastores with findings, sorted by total findings, with a High Confidence column alongside the total so you can sort by what is actually confirmed. Filters cover Category, Risk Level, and Type. Rows open the same detail drawer as the inventory tab.

Three empty states, and they mean different things: no datastores at all (nothing discovered yet), no scans completed (discovered but never scanned), and no sensitive data detected across N scanned datastores (a real, clean result).

Tab 3: Analytics

The estate-level distribution view, for reporting and for spotting gaps rather than for triage.

Four KPIs: Total Datastores, Scanned as a percentage with the raw fraction, With Findings as a percentage of scanned, and Avg Risk Score.

Four charts:

Status Distribution - where your inventory sits in the lifecycle. A large Discovered slice means scanning is behind; a large Needs Credentials slice means database engines are waiting on connection details.
Type Distribution - the mix of resource types.
Scan Recency Distribution - how fresh your coverage is. This is the chart that tells you whether your posture is current or historical.
Risk Distribution - the spread across risk bands.

The datastore detail drawer

Clicking any row opens the drawer. Its header carries the status badge, a link out to the AWS Console or Azure Portal for that exact resource, and a scan button. Hidden or not-found datastores lead with a callout explaining their state, including who hid it and why, or a link to the run that declared it missing.

Sections, in order:

Overview - name, provider, region, discovered date, size, and type-specific fields. For database engines, the databases that were actually scanned.

Credentials (RDS and Redshift only) - see below.

Risk & Sensitivity - the score and band, then Risk Drivers: the specific reasons this datastore scores what it does, in plain language. Examples you will see:

Driver	What it is telling you
High exposure (publicly accessible)	The strongest single driver.
Critical data sensitivity	The categories found are among the most damaging to lose.
High finding density	A large share of what was sampled is sensitive.
Compliance impact	The datastore is failing controls in one or more frameworks.
Reachability risk	Stale access, over-privilege, or encryption gaps widen the blast radius.
Risk trending up over the last 30 days	Getting worse, not just bad.
Public exposure unverified	The agent could not check. The score assumes exposed.
Encryption unverified	The agent could not check. The score assumes unencrypted.

The last two are shown in grey rather than red because the fix is different: grant the agent the missing read permission so it can confirm, rather than changing the resource. See IAM permissions. Why Argus worst-cases a blind spot instead of assuming safety is explained in Risk engine.

Below the drivers, the findings break down by data type, with a detection summary of total findings, how many objects or tables contained them, and how many were high confidence.

Security Alerts - open alerts for this datastore, each a link into the alert drawer.

Policy Violations - unresolved violations for this datastore, linking into the violation.

Compliance - the controls evaluated against this datastore, grouped by framework, with failures listed first. The section opens by default when something is failing.

Risk History - a daily trend of this datastore’s score, annotated with the events that moved it, so “why did this jump on Tuesday” has an answer.

Remediation - recent remediation executions targeting this datastore.

Scan History - past scan jobs with type, duration, and findings summary. Each links to the job on the Agents page, which is where you go when a scan failed and you need the reason.

Database credentials

Object stores are read with the agent’s own cloud role. Database engines are not: RDS and Redshift need their own connection details, and until you provide them the datastore sits in Needs Credentials and is skipped by every scan.

Two methods:

IAM DB Auth - you supply the database username, and the agent authenticates using IAM. Nothing secret is stored.
Secrets Manager - you supply the ARN of an existing secret. Argus stores the ARN, not the secret.

Either way the agent validates the credentials before they are accepted, so a bad username or an unreadable secret fails at configuration time rather than silently at the next scheduled scan. Once configured, the drawer’s Credentials section shows the method, the validation status, and the last validation job, and lets you re-validate, replace, or delete.