Skip to main content

Sensitive-Column Detection

Sensitive-column detection identifies schema fields that may contain personal, financial, health, authentication, or other protected data. It is a review aid. It does not inspect the values stored in those columns.

Data used​

The detector may use:

  • schema name;
  • table name;
  • column name;
  • declared data type;
  • sibling column names for context.

It never sends database row values, file contents, credentials, or agent conversations to the judgment engine.

Detection cascade​

Built-in rules run first. They catch clear names and exclude common false positives. Only ambiguous metadata reaches the managed judgment engine when the feature is effectively enabled.

Each stored finding shows:

  • category and severity;
  • Flagged or Review band;
  • whether a deterministic rule or a judgment produced it;
  • current state: open, confirmed, or dismissed;
  • the schema, table, and column it refers to.

Rule findings do not have a probability. Standard customer views do not show exact judgment probabilities.

Review workflow​

Confirm a finding when the column holds the indicated sensitive data. Dismiss it when the metadata was misleading. A later scan of the unchanged column preserves that human decision.

The findings queue supports category, confidence-band, state, and schema/table/column search filters. Results are paginated. Open findings can be confirmed or dismissed, confirmed findings can be dismissed, and dismissed findings can be reopened for review. The Why? control shows the band meaning, rule or judgment source, field, declared type, category, state, evaluation time, and question-set version when present. It never shows row values, an engine model identifier, or an exact probability.

Use findings to prioritize masking, access review, route review, and retention work. A finding does not automatically change a schema, route, grant, or policy.

A finding may offer a supported masking transform as a suggestion. The route shows how many eligible fields are protected, unprotected, or have a route-only dismissal. Dismissing a route suggestion does not change the finding's global classification and can be restored later. Nothing is applied until a person with route-management permission chooses an enabled sink and confirms the normal transform-create action. After creation, the route links to the normal transformations page. Agent-authored masking drafts still require Inbox approval.

For pipeline sources, findings are keyed to the stable connection ID plus schema, table, and column. SchemaBounce queues a background scan after a successful connection test and whenever the schema revision changes. The source surface reports queued, running, completed, rules_only, failed, or unavailable, together with aggregate scan counts and a bounded reason. A failed or unavailable scan can be retried by testing the connection again, even when the schema did not change. A failed scan does not fail or delay the connection. SQL Workbench can still run a manual scan for an analytics connection.

Reduced mode​

The rule detector continues when:

  • the platform capability is off;
  • the workspace or feature switch is off;
  • no usable judgment credential exists;
  • the judgment service is unavailable.

The scan reports rule_only and a reason. It does not claim the full cascade ran.

Cost​

SchemaBounce pays for sensitive-column judgment calls during the private preview. Deterministic matches and cached unchanged results do not create a judgment call.