Classification & detection categories
When Argus scans a datastore, it is looking for specific, recognizable kinds of sensitive data - roughly seventy distinct types, from credit card numbers to cloud access keys to medical record numbers. Each match is classified by type, grouped into a category, and counted. Argus never stores the matched value itself: the raw text is hashed on the agent before anything leaves your environment, so a finding records that an SSN was found and where, never the SSN.
Categories
Section titled “Categories”Every detected type belongs to one of seven categories, which is how findings are grouped across the dashboard, datastore views, and compliance mapping:
| Category | Examples |
|---|---|
| PII | Email, phone, SSN, passport, driver’s license, date of birth, national IDs |
| Financial | Credit card, IBAN, SWIFT, routing / bank account, tax ID, crypto wallet |
| PHI (Health) | Medical record number, diagnosis code, prescription, NPI, health plan ID |
| Credentials | Passwords, private keys, connection strings, JWTs |
| API Keys | Cloud and SaaS keys and tokens (AWS, GCP, Stripe, GitHub, Slack, and more) |
| Intellectual Property | Confidential markings, proprietary source code |
| Legal | Legal case numbers, contract identifiers |
PII, Financial, PHI, Credentials, and API Keys are treated as high-risk categories - they drive alerts and weigh most heavily in risk scoring. Intellectual Property and Legal are tracked and reported but not treated as high-risk on their own.
How a match is decided
Section titled “How a match is decided”Detection is built to be precise, because a classifier that cries wolf is one people stop trusting. Argus combines several techniques rather than relying on any single one:
- Recognizable-format patterns identify the shape of each data type.
- Checksum validation confirms that a candidate is real, not just correctly shaped. Card numbers are checked with the Luhn algorithm, IBANs with the ISO mod-97 check, Indian Aadhaar with Verhoeff, US bank routing numbers with the ABA checksum, and so on. A string that looks like a card but fails Luhn is discarded rather than reported.
- Context requirements mean many types are only recognized near a corroborating label, which sharply cuts false positives from random digit strings.
- Named-entity recognition handles the types that have no fixed format - people’s names and physical addresses - and acts as a cross-check that suppresses noisier pattern guesses.
- Filename and path context nudges confidence up or down: a match in a file named for
customers or employees is more likely real; one in a file named
test,sample, ordemois treated with more suspicion.
The specific patterns, validators, and tuning are part of what makes detection accurate and are maintained by Argus; the categories and type names above are exactly what you see in the product.
Detection confidence
Section titled “Detection confidence”Every match carries a detection confidence - how sure the classifier is that it is real sensitive data. A validated credit card or a well-formed private key lands at very high confidence; a bare name from entity recognition sits lower. Confidence rolls up so you can see, per datastore, how much of what was found is high-confidence versus uncertain, and triage accordingly. The companion statistical confidence - how well a sampled result represents the whole datastore - is a separate signal, explained in Confidence scoring.
A curated, maintained library
Section titled “A curated, maintained library”The detection library is curated and maintained by Argus rather than user-editable. New data types and validators are added over time, and because the vocabulary is defined once and shared across detection, risk, and compliance mapping, a newly added type flows through all three consistently. If you have a data type you need detected that is not covered, that is a feature request worth sending our way.