Privacy and preparation
Passwords and API keys customers paste into support tickets
By SourceX Editorial · Updated
Short answer
Credentials in support tickets are common because customers paste passwords, API keys, tokens and connection strings to speed up a fix. Before licensing ticket history, scan bodies, internal notes and attachments, get every live credential revoked or rotated by whoever issued it, then redact with typed placeholders and rescan the delivery copy.
Key takeaways
- Scan ticket bodies, internal notes, custom fields, chat transcripts and attachments, not only the customer's first message.
- Credentials your product issued can be revoked by you; credentials for other systems belong to the customer, who must rotate them.
- Never log in with a customer's credential to test whether it still works.
- Typed placeholders keep the troubleshooting sequence useful while removing the secret itself.
- Drop HAR files, log bundles and config attachments unless each one is sanitized and reviewed.
Why do support tickets collect credentials?#
Support tickets collect credentials because customers want problems fixed quickly and assume the support team needs access. A customer whose integration fails pastes the API key it uses; an admin locked out of a server pastes the connection string; someone shares a login so an agent can see the bug.
Agents add to the problem. Older macros sometimes ask customers to send a password, engineers debugging an escalation paste tokens into internal notes, and integrations copy webhook URLs with embedded secrets into ticket fields. In a helpdesk that has run for years, credentials end up spread across many record types.
Where credentials hide in a helpdesk#
Credentials hide in places a simple text search of ticket bodies will miss, so map every location before scanning.
HAR files deserve special attention. A browser HAR capture records request headers and cookies, so a single attachment can carry a working session for the customer's account.
| Location | What tends to turn up | How to check |
|---|---|---|
| Ticket bodies and public replies | Pasted keys, passwords, connection strings | Pattern and entropy scanning on exported text |
| Internal notes | Tokens and admin credentials pasted by agents and engineers | The same scan; notes often sit in a separate export field |
| Attachments | HAR files, log bundles, config files, screenshots of settings pages | File-type triage, then scanning or exclusion |
| Custom fields and form fields | Account IDs, license keys, integration tokens | Field-by-field review of the ticket schema |
| Chat and call transcripts | Passwords read aloud or typed into chat | Transcript scanning plus keyword review |
| Macros and templates | Wording that invites customers to send passwords | Read every active and retired macro |
A pattern list for the first scan#
A pattern list for the first scan should combine known credential formats with context words, because many passwords look like ordinary text.
Use more than one tool. Secret scanners built for code, such as TruffleHog, also scan chats, wikis and logs. Gitleaks, an MIT-licensed scanner for repositories and files, can read exported ticket text too, though its maintainer announced in May 2026 that it is feature complete and will receive security patches only. Some PII services cover credentials as well: Amazon Comprehend's developer guide has listed passwords and AWS access and secret keys among its entity types.
Run scans inside your own environment where you can, because sending raw tickets to an outside API creates another copy of every secret. No scanner is complete, and the Presidio project's documentation states that automated detection cannot guarantee finding all sensitive information, so sample the results by hand.
- API keys and access tokens with recognizable provider prefixes.
- Bearer tokens and JSON Web Tokens in pasted headers or curl commands.
- Connection strings that place a user name and password before a host name.
- URLs with embedded credentials or tokens in query strings, including webhook URLs.
- Private key blocks and SSH keys.
- Cloud access key pairs.
- Context words next to a value: password, pw:, pwd=, passcode, login, secret, token, PIN.
- One-time codes, recovery codes and license keys.
Rotate before you redact#
Rotation comes before redaction because a credential copied into an export, a backup or a reviewer's laptop is already exposed, whatever the delivery copy looks like. Sort every finding by who issued the credential, since that decides who can act.
Do not test customer credentials for other systems. Some scanners can confirm whether a secret is live by trying to authenticate with it; TruffleHog, for example, says it can log in to check each secret type it classifies. For keys your own platform issued, check status in your own systems instead. Using a customer's credential against its cloud account or database is a decision for the customer and your counsel, so scan customer tickets with live verification switched off.
| Credential type | Who can rotate it | Action |
|---|---|---|
| API keys and tokens your product issued | Your company | Check status in your own system, revoke or force rotation, tell the customer |
| Customer passwords for your product | Your company and the customer | Force a reset where the account is still active |
| Credentials for the customer's other systems | Only the customer | Notify the customer through its account contact; do not test the credential |
| Staff or service credentials pasted by your agents | Your company | Rotate at once and review access logs |
Redact with typed placeholders#
Typed placeholders are usually the most useful redaction format for licensed tickets because they remove the secret while keeping the troubleshooting sequence readable. Replace each finding with a label such as [API_KEY], [PASSWORD] or [CONNECTION_STRING], so the record still shows that the customer shared a key and how the agent responded.
Apply redaction to a separate delivery copy, then rescan that copy with the same rules. Separately, decide whether to redact at the source: many helpdesks offer redaction or deletion features for tickets and attachments, but availability depends on your plan, so check the vendor's documentation. Cleaning the live helpdesk reduces risk well beyond the licensing project.
Attachments are usually excluded rather than redacted. Sanitizing HAR files, log bundles and config exports one at a time is slow and error-prone, and they rarely add anything a buyer cannot get from the ticket text.
Illustrative: a carrier integration platform cleans its ticket history#
Illustrative: a fictional software company that connects shippers to freight carriers wants to license years of Zendesk tickets about integration failures. A first scan finds API keys its own platform issued, carrier portal passwords, SFTP connection strings and many HAR attachments.
Engineering revokes every platform key that is still active and notifies those customers. Account managers tell customers about third-party credentials found in their tickets, without testing any of them. All attachments are excluded, findings become typed placeholders, and a second scanner pass plus a manual sample of the delivery copy finds nothing further.
The company also rewrites the macros that asked for passwords and switches on inbound redaction in its helpdesk. The licensed package keeps the full troubleshooting story, and the secrets are gone from both the package and the live system.
Stop the next credential from landing in a ticket#
Preventing new credentials in tickets is cheaper than cleaning them out later, and it keeps future exports usable for licensing without a fresh round of rotation. Most of the fixes sit in support operations rather than engineering.
- Rewrite every macro that asks for a password, and replace it with instructions for granting temporary access.
- Offer a support access or impersonation feature in the product so agents never need customer logins.
- Switch on inbound redaction or secret detection in the helpdesk where your plan supports it.
- Give customers a secure upload route for logs and HAR files that strips cookies and auth headers.
- Train agents and engineers never to paste tokens or admin credentials into internal notes.
- Add a periodic scan of new tickets, so leaks are caught soon after they appear rather than at export.
How SourceX handles credentials in ticket packages#
SourceX treats credential removal as part of the Preparation step of the SourceX five-step transaction, alongside removal of personal and confidential details. Ticket packages are scanned, rotation is confirmed with the supplier, and the delivery copy is rescanned before the supplier approves release.
Scan results and the supplier's sign-off are recorded in the release authorization of the SourceX Evidence Packet.
Frequently asked questions
Should we tell customers we found their credentials?
Yes, for any credential that may still work. A short notice through the account contact, naming the ticket and the credential type without repeating the secret, lets the customer rotate it. Coordinate wording with security and counsel, and keep a record of who was told and when.
Are expired or revoked credentials safe to leave in?
No. A dead key still reveals formats, internal host names and account identifiers, and you may not be able to prove it is dead. Redact every finding to a typed placeholder regardless of its status.
What about passwords masked with asterisks in screenshots?
Masked fields are not the main risk, but screenshots often show other details: account names, URLs, internal settings and sometimes partly visible keys. That is one more reason to exclude image attachments from a licensed package unless each one is reviewed.
Can a model memorize a key that slips through?
Models can reproduce rare strings from their training data, which is why buyers expect secrets to be removed before delivery. Treat a licensed package as if any string in it could reappear later, and scan and sample accordingly.
Who should own this work?
The CTO or head of security usually owns detection and rotation, the head of support owns macros and customer notices, and the licensing lead confirms that the delivery copy passed its rescan before release.
Sources
- TruffleHog scans sources including Git, chats, wikis, logs, object stores and filesystems, and for each secret it can classify it can log in to confirm whether the secret is live. Source
- The Amazon Comprehend Developer Guide, as archived on GitHub in June 2023, lists PII entity types including PASSWORD, AWS_ACCESS_KEY and AWS_SECRET_KEY. Source
- Presidio's documentation warns that because it uses automated detection mechanisms, there is no guarantee it will find all sensitive information, and additional systems and protections should be employed. Source
- On May 21, 2026, the gitleaks README was updated to state that Gitleaks is feature complete and that future releases will be security patches only; Gitleaks is MIT-licensed and detects secrets such as passwords, API keys and tokens in git repositories, files and stdin. Source
Related resources
- InsightCan property management companies sell their data to AI companies?
- InsightCan observability data such as logs, traces and errors be licensed?
- IndustryBPO & contact centers data
- IndustryHealthcare administration data
- QuestionDo AI companies buy private business data?
- QuestionIs selling company data legal?
See if your company qualifies
A short company assessment. No data uploads are needed.