After the breach, attackers go credential harvesting

If you’ve spent the past few weeks responding to security advisories, you know what a challenge it is to keep delivery moving. As AI accelerates how quickly vulnerabilities can be found and exploited, it makes fundamentals like credential security more important. While a vulnerability may let attackers into an environment, credentials often determine how fast and how far they can move laterally within an environment. Once inside, they may search for credentials to use elsewhere. That search is known as credential harvesting.

A recent incident involving a compromised CI/CD security tool showed how quickly this access can spread. Attackers obtained a package-publishing credential and used it to distribute a malicious package through AI infrastructure. Once installed, it searched for additional credentials. Within hours, a stolen credential can lead to an outage, a compromised release, a cloud incident, or a costly investigation. Not to mention reputational damage.

AI changes the speed, scale, and frequency of attacks but not the fundamentals of a strong response. As AI-enabled tools reach deeper into developer workflows, security teams need to find those credentials and replace exposed copies, but the hard part is doing it without interrupting developer work.

Where AI tools encounter developer credentials

When you’re getting an app running, the last thing you want is to stop and re-enter a credential every time you run a command. A .env file or local configuration keeps the app connected to its database or API and lets your scripts keep moving. That’s why developers use them.

The convenience of these workflows can make credential security easy to overlook. In a 1Password survey this year, 24% of developers reported that they hardcode credentials directly into code, scripts, or configuration files. 43% said they don’t use a secrets manager or vault. The sprawl makes credentials harder to track, rotate, or remove. 

Now add AI. Nearly half of the developers surveyed said they already use AI agents in production. When an AI coding assistant can read project files or run terminal commands, it may also be able to read .env files and other local settings. If that tool is compromised, an attacker may inherit the same access.

Other recent credential incidents have shown that a valid credential can let an attacker authenticate as an approved user or service and move into other systems without needing to exploit another vulnerability.

Find and secure exposed credentials without slowing developers

The first step is understanding where credentials are stored. That means looking beyond repositories and checking where developers work every day, including .env files, SSH directories, and local configuration. Security teams need a way to find exposed credentials and decide where to start without disrupting workflows that depend on them.

That’s where 1Password Developer Watchtower can help. It checks the local development locations your team chooses for exposed credentials. Admins can see which users and devices may be affected and focus on the findings that need attention first, without seeing the secret itself.

Once it finds a credential, you need to deal with it. If it may have leaked, revoke or rotate it. Developer Watchtower guides developers to move it into 1Password, where they can manage the replacement and make it available to applications and tools at runtime.

This becomes even more important as AI becomes part of everyday development. In the 1Password survey, 65% of developers said their organizations expect or encourage them to use AI agents, but only 33% said they have a secure way to do so.

To keep those ambitions from opening doors for attackers, 1Password Developer Tools help bring credential security into the workflows developers already use. Instead of copying secrets into project files or passing tokens by hand, teams can use managed credentials in the applications and tools that need them, including supported AI coding tools. This lets developers keep working with the tools they use while reducing live credentials left behind in local environments.

From exposed secrets to governed access for automation

When an app moves beyond your laptop, its credentials can move with it. The same key may end up in a CI/CD workflow, a deployment setting, or an AI agent. The app keeps running, but now there are more copies to track and clean up.

That matters more as AI agents take on more development work. In the 1Password survey, 53% of technical employees said they give AI agents overly permissive access, and 40% said they give them persistent access to systems or credentials. Securely deploying agents means giving them a limited way to get the access they need, without leaving a reusable credential behind.

To keep each job, workload, agent and developer working securely, Developer Tools help make credentials available when a command needs them. Tools such as op run, shell plugins, and the SSH agent let developers use the credentials their projects need without leaving live values in files.

The application works, the developer keeps moving, and there is no new plaintext copy to clean up.

For automation, the 1Password GitHub Actions integration, an automation workflow can receive the access it needs when it runs instead of storing a reusable token in its configuration.

No matter where the request comes from you should limit its access with scoped, short-lived credentials, track how that access is used, and let it expire or revoke it when the work is done. That means fewer secrets to copy, fewer files to clean up, and fewer questions about who or what still has access.