Give our AI Engineer enough information to understand your request while limiting unnecessary sensitive data. Useful context includes the affected website, a public page address, a description of the error, when it began, and the steps that reproduce it. You can usually explain a technical problem without posting passwords, private keys, payment details, or private customer records.
IN THIS ARTICLE
01 Share useful evidence with sensitive details removed
Before pasting a log extract or screenshot, remove API tokens, session cookies, credentials, and personal information that is not needed for the investigation. Preserve the error wording and timing where possible so the remaining information still helps diagnosis. For example, a sanitized error message can identify a failed connection without exposing the database password associated with it.
02 Use authorized access and secure integration settings
Work through the client area and the management workspace for the service you own or are authorized to manage. The Engineer uses the account's supported tools and permissions. If it cannot access a required feature, contact us to check the appropriate setup instead of supplying another person's credentials or requesting unrestricted server access.
When a new integration genuinely needs a secret, ask how it should be entered through the appropriate secure configuration process. Also consider whether test credentials or a test environment can be used while the integration is developed. Authorize only the scope needed for the task and review proposed changes that affect access, customer data, or external systems.
03 Act promptly if a live secret is exposed
If you accidentally share a live secret, arrange to revoke or rotate it through the relevant service and tell us what type of credential was involved without reposting the value. Removing a visible message alone is not a reliable way to make an exposed credential safe again. This approach keeps technical assistance focused on the problem while reducing unnecessary access and disclosure.
04 Example: preserve the diagnostic evidence while removing a secret
If a connection error includes a credential, retain the relevant failure and time while replacing the sensitive value before sharing the excerpt:
Time: [timestamp and timezone]
Affected action: Send the contact-form notification
Result: Authentication failed at the configured mail service
Account: [the relevant service reference]
Password: [REDACTED]
API token: [REDACTED]Add the public page address and the steps that caused the error. Do not substitute a real password just because the first attempt could not connect. If authorised access must be configured, use the supported private settings for that integration.
Expected result: the Engineer can investigate the failed action without an unnecessary credential appearing in the conversation.
Should I paste passwords or API keys into an AI request?
No. Describe the task with the necessary redacted evidence. Enter any required secret through the authorised private configuration process for that service or integration.
- Share the public URL, the failing action and only the necessary redacted error lines.
- Enter required secrets through the appropriate secure application or account settings, using a limited test credential where available.
- If a live secret was exposed, rotate or revoke it with the owning service and check whether dependent applications need updating.
A screenshot can contain tokens, customer addresses or one-click login links even when no password is visible. Review it before sharing. Deleting a message is not a substitute for invalidating a credential that may already have been disclosed.