This guide defines ALTR product names and terms that have a specific meaning in ALTR’s documentation, particularly ones that sound similar to each other but describe different capabilities.
| Term |
Definition |
| ALTR |
The platform. Always written in all caps. |
| ALTRNet |
The ALTR web portal you sign into to manage data sources, policies, and settings. |
| Organization |
The boundary that contains your data sources, policies, applications, and administrators – what other products call an account or tenant. Identified by the ALTR Organization ID. |
| Single Sign-On (SSO) |
Authenticates ALTR administrators through your organization’s identity provider (IdP) instead of a separate ALTR password. |
| System for Cross-domain Identity Management (SCIM) |
Provisions and deprovisions ALTR administrator accounts directly from your IdP. Currently supported with Okta. |
| Impersonation |
Lets multiple users securely share a login to a database without sharing credentials, using a temporary token gated through SSO/SCIM. |
| Term |
Definition |
| Database Activity Monitoring (DAM) |
Query-level activity in your connected databases – what was queried, by whom, when, and from where. |
| Audit Logging |
Events inside the ALTR platform itself – system events and administrative actions. Distinct from Database Activity Monitoring, which covers your databases, not ALTR’s own platform. |
| Audit Reports |
Formatted, reviewable reports generated over Database Activity Monitoring query activity. |
| DAM Alerting |
A rule-based, notification-only engine that evaluates Database Activity Monitoring data and sends notifications through email or a connected channel when a rule matches. |
| Policy Alerts |
A legacy, Snowflake-only alerting capability configured inside a masking policy, based on access rate or time window, that can block access. Distinct from DAM Alerting, which is notification-only. |
| Term |
Definition |
| Masking Type |
The specific masking behavior a masking policy applies to a value – for example, redaction or hashing. |
| Access Management Policy (AMP) |
Controls access to schema objects, such as tables and views. |
| Row Access Policy |
Controls access to individual rows within a table. Distinct from Access Management Policy, which controls schema objects rather than rows. |
| Term |
Definition |
| AI Data Shield |
Protects sensitive data in free text, including the prompts and responses that pass through a large language model. Classifies the text, tokenizes, masks, or leaves each match in the clear according to policy, and restores protected values when policy allows. |
| Format-Preserving Encryption (FPE) |
Encrypts a value while preserving its original format, so an encrypted value fits the same field length and type as the original. |
| Bring Your Own Key (BYOK) |
Lets you supply and control the encryption key ALTR uses, rather than using an ALTR-managed key. |
| Vaulted Tokenization |
Replaces a sensitive value with a token, storing the original value so it can be recovered by an authorized user or process. |
| Critical Tokenization |
Vaulted tokenization plus an additional scattering step, for the highest-sensitivity data. |
| Application (AI Data Shield) |
The identity AI Data Shield authenticates on every call – your own code, holding a registered signing key. Not a data source. |
| API Payload Classification |
Finds sensitive data in one application payload and reports each match as a finding, located by its position in the text. |
| Tokenization Strategy |
The choice on a Tokenize protection rule that decides how a token is minted: Critical, Vaulted, Critical (Deterministic), or Vaulted (Deterministic). |
| Determinism Context |
The scope a protect call sets for deterministic tokenization. The same value repeats a token only within the same context. |
| Term |
Definition |
| OLTP |
Online transaction processing databases – for example, MySQL, PostgreSQL, SQL Server, and Oracle – that ALTR connects to through a sidecar. |
| Sidecar |
The proxy that runs on your infrastructure to monitor and protect OLTP database traffic in real time. Also called an agent. |
| Classification Agent |
A standing OLTP component that runs classification jobs against a repository on a schedule. Distinct from the sidecar and from a scout agent. |
| Security Intelligence Scout (SIS) |
A database audit agent that reads a database’s native audit trail on a polling basis and publishes the activity to ALTR for database activity monitoring, alongside the sidecar. |
| Validated Databases |
The specific OLTP database versions ALTR’s sidecar has been validated against. |
| Term |
Definition |
| Classifier Rules |
The conditions – such as column name lookups, regular expression matches, or ML-based classifiers – that ALTR uses to match data during classification. |
| Finding |
One classifier match on one column – the unit you approve or reject in Human-in-the-Loop Review. |
| Human-in-the-Loop Review |
A per-job option that holds a classification job after scanning so you approve or reject each finding before ALTR generates the report. |
| Processing Location |
Where a classification job runs: ALTR Hosted, In-Warehouse (Snowflake only), or the OLTP Classification Agent. |
| Scan Scope |
The object a Snowflake classification job is narrowed to – the whole database, one schema, or one table. |
| Targeted Classification |
Narrowing a Snowflake classification job to one schema or table, and excluding objects inside that scope from being sampled. |
| Term |
Definition |
| Snowflake Marketplace |
The Snowflake listing used to provision an ALTR integration directly from Snowflake. |
| Microsoft Entra ID |
Microsoft’s identity provider, formerly named Azure Active Directory. |