Dynamic data masking: what comes back when they query (6/7)
Get Started
Dynamic data masking (6/7)
Access control decides who can query a table. Masking decides what comes back — the analyst who needs the orders table has no business reading the email addresses in it.
Bytebase masks sensitive columns on the way back — in the SQL Editor, in exports, and in whatever an AI assistant reads over MCP. This covers reads that go through Bytebase; the connection your application already holds is not one of them.
Four controls decide what gets masked — three policies in a fixed order of precedence, plus classification at scale:
Masking Exemption
Overrides the other two. A named user or group sees a table as it really is, for query or for export. Give it an expiry when you grant it — an exemption with no expiration timestamp never expires.
Global Masking Rule
Workspace-wide, and ordered like an iptables chain: first match wins. Mask everything in production, everything in one project, or everything your classification marks sensitive.
Column Masking
Per project, column by column — the fallback for the columns no global rule covers.
Data Classification
The scale lever. Tag columns by sensitivity — by hand, or from a convention in the column comment — and one global rule masks everything above a level, instead of a rule written per column.
Bytebase — the standard for database governance.
