Two custom fields on my NetSuite test account hold credential material in plain, unencrypted text, readable by any role with access to the record. One holds what appears to be a client ID and secret pair in JSON on both records of a filing-authorization record type. The other is populated on all fifteen records of a payment-gateway credential type. During schema verification, one of those secrets surfaced in diagnostic output, and the report says to treat it as exposed and rotate it regardless of anything else that happens.
The Sensitive-Data Hazard Scan found those two fields by scanning 2,485 custom field definitions, and it did it without reading a single stored value into the report. It went into the Sonar AI Prompt Library in September. If you're new to this, Sonar AI is an AI agent that runs inside NetSuite. Every prompt in the library is a playbook that I engineered and tested against live NetSuite data, and you run it inside your own account, against your own records. Nothing leaves the account, and nothing is written to it.
The Funnel
The scan works on metadata. Field names and script IDs are matched against two dictionaries, one for credential terms like password, secret, token, API key, and private key, and one for regulated data like email, phone, social security number, tax ID, bank account, routing, credit card, and date of birth. Fields typed as email address or phone number match directly.
2,485 definitions produced 159 raw hits. Triage dismissed 146 of them, and the report says which: "Author" and "Authorization" fields caught by the auth pattern, "activation" caught by the VAT pattern, manufacturing routing caught by bank routing, and template-text fields holding button labels rather than personal data. A first, broader regulated-data pass returned 141 hits and was discarded after bare mobile and VAT patterns matched device-layout fields. Thirteen verified hazard fields survived. Then each survivor was population-checked with count-only queries against its host table, which left two fields with live high-severity data on seventeen records.
That funnel is drawn in the report with the subtraction at each stage, and each stage is reproducible from the queries in section five.
Thirteen Findings
Two high. The plaintext credential pair, owned by a named employee, top remediation priority. And the fifteen gateway credential IDs, where the report says values were deliberately not read, and that if these are gateway secrets rather than reference IDs they get the same treatment as the first finding. It recommends opening one record to classify.
Seven medium. Three of them are payment-gateway bundle fields designed to hold an API key or hash secret in plain text, all empty today, and the report's line on them is that they become high severity the moment the gateway is configured, so restrict the record type now. Three consumer email addresses on a stock-notification subscription record, outside the entity model, which means that if the subscribers aren't also customer records, they're invisible to data-subject access and erasure workflows that only sweep native entities. The company's own published storefront contact information, flagged by pattern and low practical risk. And a Google OAuth client ID stored as a script parameter, which the report notes is a semi-public identifier and a downgrade candidate.
Four low, all dormant: bundle-remnant VAT registration fields, a bank account number field populated on zero of 244 accounts, and a credit-card signature image and card-pattern field from a point-of-sale bundle, where the pattern field turned out to be BIN-matching configuration rather than cardholder data and was cleared on inspection.
The Population Chart
Every credential-pattern field whose host record type has rows is populated at 100%. The report's reading is that these fields are in active use, not residue. The empty bars are dormant definitions, and the recommendation is to remediate them now, before data arrives, because it's cheap.
What It Recommends
Six steps in urgency order. Immediately, rotate the filing-authorization secret at the issuing provider, then fix the storage. This week, migrate stored secrets to NetSuite's API Secrets feature and blank the legacy fields, and classify the fifteen gateway credential values by opening one record. This month, lock the payment-gateway configuration record types to administrator-only permissions before they're populated, and fold the subscription emails into privacy workflows. Quarterly, re-run the two scan queries as they stand and prune dormant hazards, because the report says an empty hazard field is still an invitation.
What It Can't See
The assumptions section is short and specific. Detection is name-based, so a field named "Config Value" that stores a secret won't be caught, and free-text blobs and File Cabinet contents weren't content-scanned. Populated doesn't mean sensitive. One VAT field couldn't be population-checked because it isn't applied to any table the role can query. Owner attribution reflects the field's owner attribute, which for bundle fields is the installing account rather than the current maintainer. Scope is custom field definitions only, so native fields, saved-search exposure, and workflow fields are out. And the scan ran under one role, so fields hidden from it by field-level security wouldn't appear.
Wrapping Up
The plaintext vendor credential that the Instance Integrity Diagnostic and the Instance Technical Documentation each flagged on the test account is the kind of field this scan is built to find in bulk. Those two prompts found one. This one is the sweep.
Sensitive-Data Hazard Scan is in the paid tier of the library. The full sample report from the test account is online, and I covered the whole September release in a separate post.
Counts only, no values, and two live secrets found anyway. That's the right way to run it.