Identify what the key allows
Before integrating a service, establish whether the value is a private credential, a public identifier or a key designed for browser use. Conditions differ between services. For a private credential, record its purpose, project and necessary permissions without putting the actual value in the documentation shared with people working on the application.
Imagine an application sending request confirmations through an external service. The credential authorising those messages may enable actions on the company's behalf. If someone obtains it, the impact depends on its powers: unauthorised sending, access to information or resource consumption may be possible, according to the service and its configuration.
This distinction supports concrete questions for the agent. Instead of asking it to connect the platform by any means, specify the required operation and ask it to identify the appropriate credential type. Do not automatically grant administration powers when the application only needs to perform a bounded task in that service.
Avoid distributing the same credential across projects that do not need to share it. Separating purposes and limiting permissions makes a problem's scope easier to understand and affected access easier to replace. The organisation should know who manages each credential and which applications need updating whenever that credential changes.
These choices belong in planning an application before construction. An integration has a purpose and a boundary beyond a technical connection that works. Writing the boundary helps review implementation and prevents accepting the most powerful configuration simply because it resolved the first test, without considering the access it grants.
To prepare your next step, explore Security for applications developed with AI.
Prepare configuration without pasting the secret into chat
Ask the agent to prepare variable names and placeholders using fictional or empty values. The real value should enter through the configuration mechanism chosen for the project. An environment file needs appropriate permissions and handling; its filename does not make the contents protected by itself or determine who can read them.
In the confirmation example, documentation can identify a variable for the messaging service token and explain where to configure it. It does not need the token itself. The responsible person can complete configuration without turning the credential into an example copied into instructions, reports or messages sent for technical support.
Also define what the agent may display during checks. It can confirm that a variable is present and configuration was recognised without printing the full value. An attempt to help, such as listing every variable to diagnose an error, can create another exposure in the record of the conversation.
When preparing the environment for work with Claude Code, distinguish the example file from files containing actual values. The example can accompany the project with installation instructions. The others need to stay outside shared materials and be managed according to the environment where the application will actually run and use them.
Confirm what the application delivers to the browser
Storing a key in an environment variable is insufficient if configuration or code eventually sends it to the browser. Check where the value is read and what leaves the server. For an operation using a private credential, the browser should receive only the information needed for the authorised result of that operation.
In Next.js, variables used with the NEXT_PUBLIC_ prefix may be incorporated into JavaScript delivered to the browser. That mechanism is intended for public values and should not hold a private secret. Verification needs to consider the built version as well as the variable name present in the configuration file.
The server can also accidentally reveal a credential in a response or error message without using a public prefix. Follow the value from configuration through the service call. Confirm that the response returned to the application does not include information that only the integration needed to know to perform its task.
For confirmations, the user requests the intended action and receives the corresponding status. The system still needs to verify who may request that sending and under which conditions. Keeping the private key on the server does not authorise everyone to use the operation without limits or an appropriate access rule.
Review the repository and supporting materials
Review should cover current code, relevant history and files accompanying delivery. Confirm that repository exclusions apply to the correct files. Adding a file to the exclusion mechanism does not automatically remove content already tracked by version control, so the current exclusion list alone cannot prove that the content was never included.
Ask the agent to identify possible credentials by location and category without copying them into the response. The report can explain that it found a suspicious value in a configuration file or an earlier version. Confirmation should then follow a process that does not spread the discovered value again.
Look at screenshots, request examples, technical exports and execution logs as well. A file used to explain an integration may contain more information than needed. When preparing advertising data for AI analysis, the same discipline helps: separate useful data from the configuration and access information used to obtain it in the first place.
Automatic detection tools can help find known patterns, but results need context. A flagged item may be fictional, and the absence of alerts does not establish that every possible format was recognised. Combine searching with reviewing the places where the application receives, uses and displays credentials throughout the relevant workflow.
Treat an exposed key as access that needs replacing
If a private credential is confirmed as exposed, prioritise revoking or replacing it according to the service and updating its dependencies. Removing the value from a public file does not invalidate copies someone may already hold. The response needs to address the credential, the cause and the continuity of the application.
Identify affected services and who has authority to replace access. Then confirm that the application uses the new configuration and the old access is no longer valid. Consider possible interruptions without leaving a compromised credential active indefinitely simply because the change requires coordination between people responsible for different parts.
Assess the period and locations of exposure, including history and shared materials, and review activity available from the service. That information helps establish what happened and what needs follow-up. Do not conclude that abuse occurred without evidence, or confuse the absence of an alert with proof that nothing happened.
Finally, correct the route that allowed exposure and record the checks without storing the secret in the report. The cause may be a publication rule, overly detailed logging or a value placed on the wrong side of the application. Prevention improves when that cause is resolved and the next delivery repeats the relevant controls.