Potential data loss when a column comment contains [SENSITIVE]

[ayushgade06]

I noticed a small issue in Studio's column sensitivity handling that can cause user-written comments to be silently modified.

Currently, Studio stores the sensitive data flag by prepending [SENSITIVE] to the column's comment (ColumnEditor.utils.ts).

The problem is that the encode/decode helpers don't check whether the marker is actually at the beginning of the comment.

There are two places where this causes trouble:

• isSensitiveDataInComment uses comment.includes('[SENSITIVE]'), so any comment mentioning the marker is incorrectly treated as sensitive.
• encodeCommentWithSensitivityFlag uses comment.replace('[SENSITIVE]', '').trim(), which removes the first occurrence wherever it appears, even when the sensitivity toggle is off.

Reproduction

1. Create or edit a column.

2. Set its comment to:

   Fields marked [SENSITIVE] are PII

3. Save the column.

The comment gets persisted as:

Fields marked are PII

The column is also incorrectly marked as sensitive in the editor.

For example:

encodeCommentWithSensitivityFlag('a [SENSITIVE] b', false)
// Current result: 'a  b'

This isn't an SQL injection issue since pg-meta parameterizes the comment using literal(). The problem is silent data loss of user-authored content.

Proposed fix

I think the immediate fix can be quite small:

• Use startsWith() to detect the marker.
• Strip it only when it appears as an exact leading prefix.
• Remove the marker and at most one following space, preserving the rest of the comment.

The editor already prepends the marker when the sensitivity toggle is enabled, so this should preserve the existing behavior while avoiding accidental matches in the middle of comments.

I have a small patch and unit tests ready. The change is contained to one utility file.

One thing I'd like to discuss

The prefix fix solves the immediate problem, but there's still an edge case: a user who genuinely starts their comment with [SENSITIVE] will still have that text interpreted as the flag.

I see two possible approaches:

1. Short-term: Make marker detection and removal prefix-based. This is a minimal change that fixes the current data-loss issue.
2. Long-term: Store the sensitivity flag separately from the comment, through a dedicated field or API, so the two can never conflict.

I'd lean towards the first approach for now, followed by considering the second separately.

Would appreciate some thoughts before I open a PR. Is there any reason to avoid the prefix-based fix as an interim solution?