Reducing credential exposure as agents take on more work

At 1Password, we’re building a trusted home for the credentials behind your digital life One minute, your team is merging a pull request on an average Wednesday. The next minute, the platform running your deployment tells you to rotate every secret stored there, including API keys, database credentials, and signing keys. Your security team will identify and scope the radius of the impact. Security engages the developer who owns the service and starts opening deployment settings, CI workflows, cloud consoles, old scripts, and local .env files, trying to answer: Which credentials may have been exposed? Where are all the places they appear? What can they access? And how in the world can I rotate them as fast as possible without breaking production? It’s a scenario every developer and security practitioner dreads because it feels like a high-stakes treasure hunt. Recent security disclosures 1, 2, 3 have brought that challenge into focus: credentials exposed in config repos, environment variables accessed without authorization, access tokens appearing in AI responses and logs, and the scramble to identify, revoke, and replace what may have been exposed without breaking production. These incidents involved different systems and access types, but they highlight the risks when credentials collect in places where they can be copied, logged, or forgotten. Once exposed, the fallout can move downstream fast, and the rotation and cleanup can be a massive undertaking. That leaves the practical question of how to keep using these tools without making every platform, workflow, and agent another source of credential sprawl. Start where the credentials live First, keep the real credential out of the source code, config, or workflow whenever possible. Users can store the real credential in 1Password and put a reference in the config. Locally, 1Password CLI commands such as op run resolve secret references and pass the values to the launched process at runtime. With the 1Password Credential Broker, repos inject credentials at runtime, and the application gets what it needs without leaving a copy of a credential in the CI/CD pipeline or config. Credential Broker removes the need for a Service Account and brings Workload Identity Federation (WIF) to 1Password. 1Password Environments, op run, and op:// references support this approach. For non-interactive workloads, teams can use a scoped Service Account token to resolve secrets at runtime. That bootstrap credential still needs to be protected and carefully scoped. To help keep sensitive infrastructure credentials off developers’ disks, 1Password CLI also supports over 80 shell plug-ins, including for platforms like AWS & GitHub. The common thread is keeping credentials out of places where they can be copied, logged, or forgotten, and always keeping them in a secure vault. These easy-to-implement changes in developer workflows can reduce exposure and speed up recovery. Access should be temporary Centralizing the credential addresses one part of the problem. The next question is what happens when a person needs elevated access to the systems behind it. A standing cluster-admin credential is a master key that never gets returned. 1Password Privileged Access gives authorized people and their local AI agents just enough access only when they need it, based on their identity and the organization’s policy, then removes it when the access duration expires. Access is revoked when the session ends, or policy requires it, so nothing is left to remember or clean up afterward. It complements the developer tools described above. 1Password Environments helps protect your project’s environment variables and the secrets contained within them, while Privileged Access controls human and local AI agents' administrative access to critical infrastructure. Together, these approaches help teams reduce unnecessary copies of credentials and standing access to the systems those credentials protect. The same rules apply to personal agents Everything we’ve talked about so far applies to developers and the environments they run. Still, the same problem is moving into everyday workflows as personal agent adoption starts to take off. Personal AI agents can summarize your email, book your vacation, schedule a birthday party, and work across many applications, but to do that, they need to authenticate to those services. If those credentials end up in the agent’s context, logs, or chat history, you’ve created a similar credential exposure problem we just saw in developer environments. And because personal agents are moving into the hands of a much broader audience, the credential risk for everyday, non-technical users is also broader. If an agent needs to book a trip, pay a bill, or update a work account, people need a clear way to see what the agent wants to access and approve the sign-in without handing over a password. That way, the credential stays out of shared chat logs and the agent’s memory, reducing th

Extras afișat conform termenilor RSS ai publicației · 103 cuvinte · textul integral și figurile sunt pe site-ul publicației