why - Currently Sensitive Data Discovery does not support an “invert matcher” or negative key list capability for Key-Value Pattern rules. The available options are limited to exact match, substring, or regex for expected keys, and there is no built-in mechanism to define “match all keys except these” or to invert the key pattern logic. Given that limitation, we're having to use a two-data-type strategy using one data type that evaluates value-only via regex for coverage, and a second that combines value regex with an allowed key list for higher fidelity. This approach allows us to identify false positives over time and gradually refine the allowed key set without sacrificing broad detection visibility. But it requires constant review and filtering of found APIs for the false positives outside of the tool. An easier approach would be to use a data type with "invert matcher" or negative key list such that the work of identifying false positives is maintained in the XC tool/console/data itself, each time we identify a false positive, we add it to the list, and the next time we review the findings it excludes that false positive field. This makes the process more efficient for the humans involved and keeps all the steps of the process withing the XC tool, the users doesn't have to maintain any aspect of the process outside of the tool. One example use case is looking for APIs that include credit card fields in the body/payload, there are many fields that match card regex and pass the MOD 10 (LUHN check) that are not credit cards, filtering those out via a false positive list is ideal.

who - security engineers looking to identify high risk APIs needing more controls like anti-automation or looking for APIs that require CSD for PCI compliance.

how - allow the "invert match" option on the key list