The Problem No One Is Talking About

Security teams have spent years fighting credential sprawl in human environments: developers with SSH keys to servers they no longer work on, service accounts with permissions that were "temporary" in 2019, API tokens that got copy-pasted into twelve different config files.

AI agents do the same thing, faster, and often invisibly. An agent working on a multi-system task will touch credentials for each system it interacts with. If those credentials live in the environment, in configuration files, or in shell history — and they often do — the agent now has access to all of them.

This is credential sprawl at machine speed. And unlike a human developer who accumulates access gradually over months, an agent can accumulate it across a dozen systems in a single afternoon.

How Agents Accumulate Credentials

Environment Variables

The most common vector. Most agent frameworks inherit the shell environment, which means the agent has access to every API_KEY, DATABASE_URL, and AWS_SECRET_ACCESS_KEY that was set when the session started. This includes variables set for unrelated purposes — the developer's personal AWS profile, their GitHub token for a different project, credentials that were "just this once" for a debug session.

When you run env | grep -i key, you might be surprised how much is sitting there. Your agent can run that same command.

Configuration Files

Agents that have shell access will inevitably browse configuration files during tasks. ~/.aws/credentials, ~/.ssh/config, ~/.npmrc, ~/.netrc, application .env files — these are all discoverable through normal filesystem exploration. An agent looking for "how the project is configured" will find all of them.

This isn't hypothetical. It's what happens when an agent runs find . -name "*.env" -o -name "config.toml" to understand a project structure.

Shell History

Shell history is a credential goldmine that most teams overlook. Developers frequently pass credentials as command-line arguments — curl -H "Authorization: Bearer eyJ..." or psql "postgres://user:password@host/db". Every one of these ends up in ~/.bash_history or ~/.zsh_history.

An agent doing research on "how does this system work" may read shell history to understand past operations. It's a reasonable thing to do. It also exposes every credential that was ever passed on the command line.

In-Context Accumulation

Beyond what's already on disk, agents accumulate credentials within a session as they're used. A credential mentioned to help with task A is still in context when the agent moves to task B. Multi-turn agents with long context windows carry credentials from early in the conversation all the way through to the end — including tasks where those credentials have no business being present.

Why This Creates Real Risk

The Blast Radius Problem

When a human developer is compromised, the attacker gets access to whatever that developer had. When an agent is compromised — through prompt injection, model error, or a malicious task — the attacker gets access to whatever the agent accumulated across all the tasks it's touched.

That blast radius grows with every task. An agent that's been running for a week, helping with production deployments, database migrations, and API integrations, has seen credentials for all of those systems. A compromise of that agent is a compromise of all of them.

No Audit Trail for Credential Access

With human developers, there are typically some signals when credentials are accessed: VPN logs, access logs, authentication events. With agents operating through a shell, credential access often leaves no trail at all. The agent reads ~/.aws/credentials, stores the contents in context, and uses the credentials — all without generating an authentication event that your SIEM would catch.

Cross-System Lateral Movement

Credential sprawl enables lateral movement. An agent that accumulated credentials for system A during one task can now access system B — even if the task it's currently working on has nothing to do with system B. This is especially dangerous with cloud credentials, which often grant broad access across an account or organization.

The Authentication Event Your SIEM Won't See

Traditional credential monitoring works by watching authentication events: login attempts, API calls, SSH connections. Your SIEM fires an alert when credentials are used from an unusual location or at an unusual time.

Agent credential access often bypasses this entirely. If the agent reads a credential from disk and uses it from the same IP address, at a normal time, the authentication event looks identical to a legitimate human developer doing the same thing. There's nothing to alert on.

The only place you can catch this is at the execution layer — watching what commands the agent runs before it uses the credential, not after.

Containment: Four Approaches That Actually Work

1. Minimal Credential Environments

Agents should run in stripped environments with only the credentials needed for their specific task. This means not launching agents from your developer shell. It means creating task-scoped environments where env shows exactly what the agent needs and nothing else.

This is operationally annoying. It's also the only way to prevent ambient credential inheritance.

2. Credential Scoping by Task

Where possible, use short-lived, scoped credentials rather than long-lived master credentials. AWS IAM roles with specific permissions, GitHub tokens scoped to specific repositories, database users with read-only access for read-only tasks.

This doesn't prevent accumulation, but it limits what accumulated credentials can do. A compromised agent that holds a read-only database credential can exfiltrate data, but it can't drop tables.

3. Command Authorization at the Shell Layer

The most reliable containment is intercepting commands before they execute. When an agent tries to read ~/.aws/credentials, that should be a reviewable action — not something that happens silently in the background.

This is what command-layer authorization tools like expacti provide: the ability to see every command the agent wants to run, before it runs, and approve or deny based on context. An agent attempting to read a credentials file during a documentation task is a signal. A command authorization layer lets you catch it.

4. Credential Rotation After Agent Tasks

For high-sensitivity systems, rotate credentials after significant agent tasks complete. If an agent touched your production database, rotate the credentials it used. This is operationally expensive but bounds the exposure window — even if the agent's context was compromised, the credentials it accumulated are no longer valid.

The Honest Limitation

None of these approaches is complete. Minimal environments require discipline and tooling investment. Scoped credentials require someone to define what "minimal necessary access" means for each agent task. Command authorization adds latency. Rotation is operationally costly.

The realistic baseline for most teams is: scoped credentials where easy, command authorization for shell access, and periodic audit of what credentials your agents have touched. That's not perfect, but it's substantially better than the current state, which is usually "we don't know."

Knowing What Your Agent Knows

The fundamental problem is visibility. Most teams can't answer the question "what credentials has our agent touched in the last 30 days?" The answer would require reconstructing every session, every file read, every environment variable that was inherited.

An audit trail at the shell layer gives you that visibility. Not perfect — an agent can accumulate context that doesn't show up in shell commands — but enough to understand the access pattern and identify anomalies.

Credential sprawl with human developers took years to become a serious problem. With AI agents operating at machine speed across multiple systems, you can build the same level of sprawl in days. The time to address it is before the first agent goes into production, not after.