Remove standing access before AI agents exploit it

AI has changed the calculus of a credential attack. Before, finding and exploiting credentials in an enterprise environment required time, patience, and human judgment. An attacker had to decide which accounts were worth testing and which systems were worth reaching. Many credentials never made the list. 

By contrast, an autonomous system that gains a foothold in a victim’s systems has no need to be picky. It can sweep an environment in moments, scooping up API keys, service account tokens, OAuth tokens, cloud credentials, and plaintext secrets on developer devices. It authenticates with whatever it finds and moves laterally as far as standing access allows, one credential opening the next, at machine speed. An attacker with AI doesn't need to choose targets. Everything accessible is worth exploiting.

Recent high-profile incidents with experimental AI models have shown that pattern in action. Entry points differed: software exploits in two cases, weak passwords in a third. But what followed was the same in each incident: automated systems swept for whatever credentials the environment offered and moved as far as standing access would carry them. In one documented case, that meant more than 17,000 recorded attacker events over a single weekend. 

These stories are just early indicators of what defenders will soon be facing as these experimental models become commonly available services. As autonomous systems become more capable and more widely deployed, credential sweeps after breaches will become faster, more thorough, and harder to detect. 

Any enterprise running AI workloads, AI coding tools, or developer workflows on shared infrastructure has accumulated the same kind of exposure that made these headline-grabbing attacks successful: service accounts whose permissions grew beyond their original purpose, API keys that were never rotated, and secrets left in plaintext on developer devices because they were easier to use that way.

In the face of what is coming, strengthening perimeter controls is necessary but not sufficient. Once an AI attack has breached the perimeter, what matters is what it finds. Limiting the blast radius requires working through three connected steps: 

1. Find and remove the easy credential paths before a threat actor exploits them. 

2. Vault the plaintext secrets scattered across engineering environments so they are no longer exposed to any process reading the environment. 

3. When workflows and AI agents need credentials or access, issue them at runtime, scoped to the specific task, with authorization that ends when the job does. 

Together, those steps limit the number of credentials an AI attack will discover, and reduce the reach to just the authorized jobs scoped into those credentials with just enough access.

How AI agents inherit your credential risk

Most AI agents deployed in enterprise environments today authenticate using the same infrastructure that was built for humans: service accounts, API keys, OAuth tokens, and long-lived secrets stored in environment variables or configuration files. None of it was designed with agent authentication in mind.

A human employee authenticates interactively, typically through SSO, with a session bounded by time and revocable on demand. When they leave, accounts are deprovisioned; when a breach is disclosed, they reset their passwords. The credential lifecycle has a rhythm tied to human events.

AI agent credentials follow no such rhythm. A service account for a coding agent or an automation pipeline is typically configured at deployment and left in place indefinitely, with credentials that don't expire, no session boundary, no periodic review, and no human event that would ordinarily trigger rotation. The API keys it uses to authenticate against cloud infrastructure or connect to databases are often stored as environment variables and passed to every subprocess the agent spawns. The OAuth tokens it holds to access SaaS systems frequently carry scopes set during initial setup for convenience rather than least privilege, with no periodic review to confirm that scope still matches what the agent actually needs. SSO doesn't cover any of this, and most of it isn't in the enterprise password manager.

Over time, the scope tends to expand: the service account that started with read access to a staging database acquires write permissions for a new workflow, then a credential for the CI/CD pipeline, then an API key for the production monitoring stack. Each expansion makes sense in isolation, but the result is a service account with far more access than any single team explicitly approved.

What a credential sweep actually looks like

When an AI agent runs in a compute environment, it can access everything the identity it runs under is permitted to read: environment variables, configuration files, mounted secrets volumes, and in some cases in-memory credential stores.

A credential sweep requires no specialized tooling and no elevated privileges. It reads the environment systematically, collecting the credential types that unlock the most downstream access: API keys for third-party services and cloud providers, connection strings for databases, cloud provider credentials (AWS access keys, Azure service principals, GCP service account keys) for infrastructure at whatever scope the permissions policy allows, and OAuth tokens for SaaS systems on behalf of the issuing account.

Each credential type found in that sweep unlocks a different system or class of systems, and what's accessible depends on the scope that was granted when the credential was configured. In environments with typical credential hygiene, that scope is often broader than intended, because the credential was set up for one specific use and never narrowed afterward.

Consider a coding agent with write access to a Git repository, a service account token for the CI/CD pipeline stored as an environment variable, and API keys for the deployment infrastructure. That's three independent lateral movement paths, none requiring anything beyond reading what's already accessible to the agent's process. The Git repository may contain hardcoded secrets from other pipelines, the CI/CD token can modify deployments, and the infrastructure credentials can reach production.

Long-lived credentials and why they amplify the risk

Whether a found credential enables lateral movement depends on what access it grants and whether that access is persistent.

Two syntactically identical API keys can carry entirely different risk profiles. A credential issued for a single job, scoped to exactly what that job needs, with access ending when the job completes, provides no opportunities for lateral movement; by the time anything else could attempt to use it, it's gone. But a credential with standing access to production infrastructure, issued at initial deployment and never rotated, gives anyone who finds it immediate access to everything that account can reach.

Most enterprise AI agent deployments look like the second case. Service accounts are configured broadly because scoping them narrowly requires anticipating every future workflow, which is difficult to do at deployment and rarely happens. OAuth tokens accumulate permissions through successive integrations, each of which adds scope without removing what was there before. API keys persist indefinitely in most systems because manual rotation is inconvenient and easy to skip. Taken together, these are long-lived credentials that grant far more access than any single job requires, and there is no mechanism to detect when something unexpected has used them.

That credential surface scales directly with your adversary’s AI capability. Capable threat actors will keep finding ways past the perimeter: model-level exploits, zero-days, and techniques that emerge as AI capability does. What they find inside depends on whether the credential model runs on long-lived standing access or runtime-scoped delivery. If every machine workload holds a persistent, broadly-scoped token, every token is part of the attack surface the moment any foothold is established.

The risk most security teams can't see

Weak and exposed credentials are one of the biggest and persistent risks in the enterprise, whether we’re talking about a marketer’s passwords or a developer's SSH keys.

1Password's research found that 66% of employees have poor password practices, including reusing passwords across accounts and sharing them via email or direct messages GitGuardian's 2026 State of Secrets Sprawl found 28.65 million new secrets exposed in public GitHub commits in 2025, up 34% year over year. Meanwhile, leaked secrets for AI services grew 81% in a single year. 

We’ve already begun to see what it means for an AI agent to exploit secrets at machine speed. Frontier AI models operating in an evaluation environment have reached real organizations' systems through weak passwords and services that required no authentication to access. The models took the simplest path available, because those paths had never been closed.

When it comes to securing credentials, visibility is the real constraint. Security and IT teams typically have no reliable way to see which accounts are using weak or reused passwords, when a service account credential was last rotated, or which automated workloads and AI agents are operating on access that far exceeds what they need. 

Three steps, one model change

Closing this exposure means working through three steps in sequence: surface what's at risk, vault what was never protected, and replace standing credentials with access issued only for the work at hand.

Watchtower, 1Password's credential risk monitoring capability within Enterprise Password Manager, continuously scans credentials for risk signals: weak or reused passwords, credentials exposed in known data breaches, and accounts without MFA enabled. Admins see which accounts need attention and what the specific risk is, without needing to manually audit credential inventories or wait for an incident to expose the gap.

Developer Watchtower and 1Password Environments address a different gap: credentials that were never vaulted. Developer Watchtower scans local devices for plaintext developer credentials, including API keys, access tokens, database passwords, and cloud credentials stored in .env files. When it identifies them, developers import them into 1Password Environments in one click. Environments stores developer secrets securely and makes them available to apps at runtime without writing values to disk. Admins get a local disk exposure report showing which devices hold unprotected credentials across the organization. The credentials that sat in local .env files, accessible to any agent sweeping the environment, are no longer there.

1Password Credential Broker changes how machine workloads receive access. Rather than a workload holding a long-lived service account token with standing access, Credential Broker validates the workload's identity, determines scope based on the defined trust policy, and issues credentials at runtime, with vault access time-bound to that job's duration. The blast radius is limited to the credentials that workload was authorized to receive.

With Credential Broker in place, a sweep of the environment finds no standing credentials. Instead of a long-lived access key with production scope sitting in the environment, the workload receives a credential issued for this specific job and scoped to what it needs. Every issuance appears in the audit trail: what ran, what credential it received, what scope was granted, and when access ended.

1Password Privileged Access applies the same principle to infrastructure. Rather than granting standing access to databases, cloud environments, or servers, it issues time-bounded access approvals tied to a specific request. Engineers or agents request access for a defined task; a human approves it; access is revoked when the window closes. No standing privilege accumulates.

Credential hygiene closes the easy paths. Removing standing access eliminates what makes those paths worth finding. Together, these solutions create an unwelcoming environment for an adversarial agent.

To learn more about how the 1Password Unified Access platform can provide secure access for humans, AI agents, and machine workloads, talk to an expert today.