TL;DR: Attackers are targeting Salesforce case data because support records often contain plaintext credentials, API keys, and debug snippets, and Google Threat Intelligence Group recommends scanning Salesforce instances for exposed secrets, according to TruffleHog. The governance lesson is that CRM data has become part of the NHI attack surface, so integration scope, data handling, and secret detection now need to be managed together.
NHIMG editorial — based on content published by TruffleHog: Detecting Exposed Secrets in Salesforce with TruffleHog
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
Q: How should security teams handle secrets found in Salesforce case data?
A: Treat them as live credential exposure, not as ordinary data leakage.
Q: Why do support systems create hidden NHI risk?
A: Support systems encourage people to paste diagnostics, snippets, and temporary credentials into free-text fields.
Q: What breaks when teams do not scan exported CRM data?
A: Leaked credentials remain buried inside files that look like ordinary reports.
Practitioner guidance
- Scan exported CRM data for live credentials Export Case, Account, User, and Opportunity objects into a controlled workspace and run verified secret scanning before any file is retained, shared, or re-imported.
- Restrict which Salesforce fields can carry sensitive data Review standard and custom case fields for places where passwords, API keys, or debug output are likely to appear.
- Reassess third-party integration scopes Inventory every Salesforce integration and downgrade permissions to the minimum required for business function.
What's in the full article
TruffleHog's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step Bulk API 2.0 and GUI export methods for collecting Salesforce Case data safely for scanning.
- Command examples for running TruffleHog against exported CSV files and using the only-verified flag to confirm live secrets.
- Practical guidance on which Salesforce objects and custom fields deserve priority when you are building an internal scan workflow.
- Remediation workflow detail for tracing a discovered secret back to the case record and deleting the exported file securely.
👉 Read TruffleHog's analysis of exposed secrets in Salesforce case data →
Salesforce case records and secret exposure: what IAM teams need to know?
Explore further
Salesforce case data is now secret-bearing identity infrastructure. The article makes clear that support records can contain live credentials, which means CRM governance now overlaps with NHI governance. That changes the operating model: access to case data is no longer just a data protection issue, it is a credential exposure problem. Practitioners should treat exported cases, custom fields, and support attachments as part of the secret lifecycle, not as passive records.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: Who is accountable when a Salesforce integration exposes credentials?
A: The accountable party is the organization that owns the data flow and the integration permissions, not just the CRM platform owner. Security, IAM, and application teams need a shared revocation and containment process because the exposure often happens in the connection layer, where ownership is easiest to blur.
👉 Read our full editorial: Salesforce case records are becoming a secret exposure hotspot