2026.09.23 — 2026-09-14
Breaking
Store messages masked with sealed originals, and add the classification inbox (5dfc37fc)
Studio no longer keeps sensitive values in its own database. The message index, capture and request-reply payloads store the masked form, so full-text and LIKE search never see a card number, email or credential. The originals of masked values other than credentials are sealed beside each row with Studio's secret key and opened only for callers holding message:clear. Every stored row records the policy version it was masked under: a rule change applies on every read at once, and a background job re-masks stored rows in bounded batches. Administration > Masking rules shows how many are still under an earlier version.
Personal data detected in a field no rule covers is masked immediately and listed under Administration > Classification inbox, where a governance:write holder confirms it into a rule or dismisses it as a false positive; both are audited and neither ever shows the detected value. Request-reply flow detail shows payloads masked, marks clear-by-grant values as sensitive, and audits clear views. An index query on a field stored masked now says so. The site guide gains a Data governance page.
Govern SQL console results, tails, exports and predicates (a438e1fd)
The SQL console now applies the content policy to every result row, whether streamed, tailed or exported: credentials are dropped, detected personal data is masked, and each row carries redactions and withheld descriptors. CSV and JSON exports contain exactly the masked values shown on screen.
A query that filters or orders on a header, property or JSON body path a masking rule covers is refused before execution for callers without message:clear, naming the field; body predicates are evaluated against the masked body, so a search cannot confirm a value the caller only sees masked. The query's audit record carries clearFields (classes and counts served in clear), a tail's clear values are audited when the stream ends, and literals compared with classified properties (props.name = '...') are masked in the audited query text.
Mask sensitive message values with a content policy (df6ec970)
Studio now governs every message it shows through browse, message detail, the MCP browse_messages tool and broker event history. Built-in rules drop credentials everywhere, for every user: Authorization, Proxy-Authorization, Cookie, Set-Cookie, and any property whose name contains password, secret, token or api-key, plus bearer tokens and JWTs found in any value. Payment card numbers (Luhn-checked), IBANs (mod-97), emails and phone numbers are detected automatically and masked; a binary body or bytes beyond the scan limit (governance.scan-limit, 256 KiB) are withheld with the reason.
Holders of the new message:clear permission see non-credential values in clear, marked as sensitive, and each such response writes a VIEW_CLEAR audit event carrying classes and counts, never values. Masking rules (header, property or JSON body path, optionally per address pattern) are managed under Administration > Masking rules with governance:read / governance:write. Audit parameters (filters, query text) are masked before they are written.
Added
Store messages masked with sealed originals, and add the classification inbox (5dfc37fc)
Studio no longer keeps sensitive values in its own database. The message index, capture and request-reply payloads store the masked form, so full-text and LIKE search never see a card number, email or credential. The originals of masked values other than credentials are sealed beside each row with Studio's secret key and opened only for callers holding message:clear. Every stored row records the policy version it was masked under: a rule change applies on every read at once, and a background job re-masks stored rows in bounded batches. Administration > Masking rules shows how many are still under an earlier version.
Personal data detected in a field no rule covers is masked immediately and listed under Administration > Classification inbox, where a governance:write holder confirms it into a rule or dismisses it as a false positive; both are audited and neither ever shows the detected value. Request-reply flow detail shows payloads masked, marks clear-by-grant values as sensitive, and audits clear views. An index query on a field stored masked now says so. The site guide gains a Data governance page.
Govern SQL console results, tails, exports and predicates (a438e1fd)
The SQL console now applies the content policy to every result row, whether streamed, tailed or exported: credentials are dropped, detected personal data is masked, and each row carries redactions and withheld descriptors. CSV and JSON exports contain exactly the masked values shown on screen.
A query that filters or orders on a header, property or JSON body path a masking rule covers is refused before execution for callers without message:clear, naming the field; body predicates are evaluated against the masked body, so a search cannot confirm a value the caller only sees masked. The query's audit record carries clearFields (classes and counts served in clear), a tail's clear values are audited when the stream ends, and literals compared with classified properties (props.name = '...') are masked in the audited query text.
Mask sensitive message values with a content policy (df6ec970)
Studio now governs every message it shows through browse, message detail, the MCP browse_messages tool and broker event history. Built-in rules drop credentials everywhere, for every user: Authorization, Proxy-Authorization, Cookie, Set-Cookie, and any property whose name contains password, secret, token or api-key, plus bearer tokens and JWTs found in any value. Payment card numbers (Luhn-checked), IBANs (mod-97), emails and phone numbers are detected automatically and masked; a binary body or bytes beyond the scan limit (governance.scan-limit, 256 KiB) are withheld with the reason.
Holders of the new message:clear permission see non-credential values in clear, marked as sensitive, and each such response writes a VIEW_CLEAR audit event carrying classes and counts, never values. Masking rules (header, property or JSON body path, optionally per address pattern) are managed under Administration > Masking rules with governance:read / governance:write. Audit parameters (filters, query text) are masked before they are written.
Fixed
Select on AMQTimestamp so timestamp queries and index sampling find messages (341b16ab)
A SQL console predicate on timestamp, and the high-water mark every console tail and every SAMPLE index subscription sends on each poll, rendered the broker selector as JMSTimestamp. Artemis's management browse does not translate JMS header names, so that selector matched no message at all: timestamp queries against a live broker returned empty results, and sampled index subscriptions stored nothing. Only a Core JMS browser, which translates the name itself, happened to work.
Both now use AMQTimestamp, named once in the column catalogue. Index subscriptions that appeared to capture nothing start filling on the next poll; no action is needed.
Escape bare tags in changelog entries so the docs build (e11a3f61)
A commit body mentioning an element such as <core> was copied verbatim into the site and parsed as an unclosed Vue element, failing the docs build for release 2026.09.20. Tag-like angle brackets outside code are now escaped when the changelog is copied; released changelog files are unchanged.