Salesforce case records are becoming a secret exposure hotspot

At a glance

What this is: TruffleHog shows that Salesforce Case objects can store exposed secrets and credentials, making support data a practical target for attackers.

Why it matters: IAM, PAM, and NHI teams need to treat CRM objects as secret-bearing data stores because exposed credentials in business workflows can expand access beyond the system that originally collected them.

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.

👉 Read TruffleHog's analysis of exposed secrets in Salesforce case data

Context

Salesforce Case objects are often treated as operational records, but they can also become secret repositories when customers, support staff, or engineers paste credentials, tokens, or configuration snippets into case text fields. That makes the CRM part of the identity and secrets problem, not just the customer service stack.

The article is about a familiar governance failure: organizations extend trust to business systems that were never designed to control secret material at scale. For NHI and IAM programmes, the question is not whether secrets appear in support data, but how quickly they can be found, verified, and removed before access spreads.

TruffleHog frames this as a scanning problem, but the deeper issue is lifecycle control across third-party integrations, exported reports, and custom Salesforce fields. Once secrets are copied into those paths, they become harder to govern than the systems they were meant to support.

Key questions

Q: How should security teams handle secrets found in Salesforce case data?

A: Treat them as live credential exposure, not as ordinary data leakage. Validate whether the secret is still active, identify the owning team, rotate or revoke it through an assigned workflow, and remove the source record where feasible. Salesforce exports should be scanned before storage or sharing because case data can become an NHI exposure point.

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. That turns business records into shadow secret stores, which expands the identity attack surface beyond dedicated vaults. The risk grows when those records are exported, copied, or connected to third-party tools without strong lifecycle controls.

Q: What breaks when teams do not scan exported CRM data?

A: Leaked credentials remain buried inside files that look like ordinary reports. Without scanning, you lose visibility into whether those secrets are live, where they originated, and whether they have already been copied into other systems. That delay gives attackers time to reuse the credential elsewhere.

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.

Technical breakdown

Why Salesforce case fields become a secret store

Support workflows encourage users to include raw detail so technicians can reproduce problems quickly. That detail often includes hardcoded API keys, bearer tokens, passwords, and log fragments, especially in Case description and comment fields. Salesforce customisation expands the risk because organizations add fields for attachments, notes, and internal context without treating them as secret-bearing data. The result is a hidden repository of credentials inside a business application, not a dedicated secret system. This is an NHI problem because the secret, not the user, becomes the access primitive.

Practical implication: Classify case fields and report exports as potential secret containers before you assume they are ordinary business records.

Bulk export and report download are the exposure accelerants

The article shows two practical exfiltration paths: Bulk API 2.0 exports and GUI report downloads. Both create a flat file that can be scanned locally, but both also widen the blast radius because exported CRM data can be copied, moved, retained, or indexed outside Salesforce controls. Once a case export exists, the organization is no longer governing the live application only. It is also governing replicas of its data, which may sit on endpoints, in temp folders, or in scanner pipelines.

Practical implication: Treat every export path as a controlled disclosure event and limit who can create, store, or re-use downloaded CRM data.

Verified secret scanning changes the response model

The article distinguishes plain detection from verified detection. A secret scanner can flag patterns, but verification checks whether the credential is still live and therefore exploitable. That distinction matters because an unverified string in a case comment is a signal, while a verified token is an active identity asset that can be abused immediately. In NHI terms, the security question shifts from data discovery to credential validity, ownership, and revocation workflow.

Practical implication: Use verified scanning for CRM exports so remediation is driven by live credential exposure, not by pattern noise.

Threat narrative

Attacker objective: The attacker wants live credentials hidden in Salesforce data so they can pivot into downstream systems and harvest more access than the CRM alone would provide.

1. Entry occurs when attackers obtain Salesforce data through a third-party integration or exported case data rather than by breaching Salesforce directly.
2. Credential exposure follows because support records, custom fields, and internal notes can contain plaintext secrets, API keys, or temporary passwords.
3. Impact occurs when those exposed credentials are validated and used to access downstream systems, broadening the compromise beyond the CRM itself.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Verified scanning matters more than pattern detection alone. The difference between spotting a token-shaped string and confirming a live credential is operationally decisive. Pattern-only workflows create noise, but verified secret scanning identifies identity material that can actually be abused. The implication is that secret response must be tied to credential state, ownership, and revocation readiness, not just to detection volume.

Integration trust without lifecycle offboarding creates hidden blast radius. Third-party Salesforce connections can move data out of the CRM without a breach of the core platform, which means trust assumptions outlive the business relationship that justified them. That is a lifecycle failure, not a tooling failure. Practitioners should re-examine which integrations still need access, which scopes are excessive, and which data paths are no longer justifiable.

Support workflows need a named concept: secret sprawl in CRM systems. When customers and internal teams paste credentials into support systems, the organization creates a secondary secret store that sits outside dedicated secrets management. This is not random leakage, it is predictable sprawl caused by workflow design. The practitioner conclusion is straightforward: CRM content must be governed as a secret source, not merely archived as case history.

Case-object exposure proves that IAM scope and data scope are now inseparable. If a support workflow can carry credentials into a CRM, then authorization decisions for the CRM are also decisions about downstream access risk. That connects least privilege, export control, and NHI discovery into one problem. Teams should stop separating business-system administration from identity governance because attackers do not respect that boundary.

From our research:

• 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.
• Follow the Guide to the Secret Sprawl Challenge for a practical view of how secrets spread across workflows and where governance usually breaks down.

What this signals

Secret sprawl in business systems is now a governance problem, not just a detection problem. The more support workflows, exports, and custom fields accept raw credentials, the more NHI teams need to treat data handling as part of identity control. With 88% of security professionals already concerned about secrets sprawl according to the 2024 State of Secrets Management Survey, the operational question is how quickly your programme can find and retire exposed credentials before they are reused.

Secret sprawl in CRM systems is the named concept teams should watch. It describes the accumulation of credentials in case notes, comments, attachments, and report exports, where they sit outside dedicated secrets management. That pattern forces IAM, PAM, and data governance teams to coordinate around the same record set instead of working in separate lanes.

Export paths deserve the same review standard as production APIs because they can move identity material into locations your normal controls do not cover. If a workflow can create a static copy of live credentials, then access reviews and data-loss checks need to include the copy, not just the source system.

For practitioners

• 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. Treat the exported CSV as sensitive until it is securely deleted.
• 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. Remove unnecessary free-text paths and add input filtering where users routinely paste support diagnostics.
• Reassess third-party integration scopes Inventory every Salesforce integration and downgrade permissions to the minimum required for business function. Pay special attention to connectors that can read case comments, attachments, or custom fields because those paths may expose credentials.
• Tie credential findings to revocation workflows When a secret is confirmed in a case export, assign ownership, determine whether it is still valid, and route it into rotation or revocation immediately. Do not let discovered secrets sit in ticket queues without a closure owner.

Key takeaways

• Salesforce support data can contain live secrets, which turns a business workflow into an NHI exposure point.
• Verified scanning is the difference between finding noise and finding credentials that attackers can actually use.
• Integration scope, export controls, and revocation workflows need to be managed together because leaked credentials spread across system boundaries.

Key terms

• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across business systems, exports, notes, and attachments. In practice, it means passwords, API keys, and tokens appear in places that were not designed to store them, making discovery, ownership, and rotation harder than they should be.
• Verified Secret Scanning: Verified secret scanning checks whether a detected credential is still active, rather than stopping at pattern matching. That difference matters because only live secrets create immediate identity risk, and only live findings justify urgent revocation, rotation, and containment work.
• Exported Data Exposure: Exported data exposure occurs when live records are copied out of their governed system into files, folders, or scanners with weaker controls. The security problem is not only the source system, but every duplicate created during analysis, support, or reporting workflows.
• Integration Trust Boundary: An integration trust boundary is the point where access granted to one system can move data into another system or into a third-party workflow. In identity terms, that boundary defines where local permissions stop being local and start influencing broader exposure.

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.

👉 TruffleHog's full post covers the scanning workflow, export methods, and remediation steps in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.