Orphaned AI agent keys remain active long after projects end

As artificial intelligence agents become common in development workflows, they frequently leave behind active identity and access management (IAM) keys long after their tasks are complete. This creates a significant security gap where valid credentials exist without an owner or purpose. Recent analysis highlights how these orphaned keys can persist for months, offering attackers a potential entry point into cloud environments.

What happened

A hypothetical but representative scenario illustrates the core issue: an IAM user named _research-agent-2 retains an access key created fourteen months ago. The key was last used eleven months ago, yet it remains active. The project it supported has closed, and the employee who approved its creation no longer works for the company. Unlike human employees who trigger offboarding procedures when they leave, finished AI agents simply stop running, leaving their credentials in a limbo state.

This lifecycle problem is not due to carelessness but rather a structural gap in how non-human identities are managed. AWS IAM user access keys do not expire automatically. Consequently, a forgotten key stays valid indefinitely until someone manually disables or deletes it. The Open Web Application Security Project (OWASP) listed improper offboarding as the top risk in its 2025 Top 10 for non-human identities, emphasizing the need to retire unused assets and assign accountable owners to those that remain.

The urgency of this issue is underscored by the speed of modern attacks. In September 2026, GreyNoise documented an AI-orchestrated campaign against PaperCut servers. Attackers moved from an empty workspace to remote code execution in under four hours. Once launched, the campaign compromised at least eleven organizations in just twenty-six seconds. While this specific attack did not use abandoned AWS IAM keys, it demonstrates how quickly exposed access becomes useful to adversaries. Slow inventory and revocation processes are dangerously inadequate in this context.

Key details

• AWS IAM user access keys have no automatic expiration date and remain valid until manually revoked.
• OWASP’s 2025 Top 10 for non-human identities ranks improper offboarding as the primary risk.
• A GreyNoise report from September 2026 showed an AI-driven attack compromising eleven organizations in 26 seconds.
• CloudQuery can sync AWS IAM credential reports to help identify keys unused for over 90 days.
• Environment time-to-live (TTL) settings can help manage disposable credentials but do not guarantee immediate revocation if destroys fail.
• Root account access keys require separate, urgent auditing and should generally not exist.

Background

Non-human identities refer to service accounts, bots, and AI agents that interact with cloud infrastructure. Unlike human users, these entities do not have natural turnover events like resignation or retirement. Their credentials, such as access keys or tokens, are often provisioned for specific tasks but lack built-in lifecycle management. When the task ends, the credential may remain active if not explicitly decommissioned.

Inventorying these identities is challenging because cloud providers do not always track which specific agent used an account. Correlating activity with audit logs and named owners is necessary to determine if a key is still needed. Additionally, while deployment platforms can enforce policies during infrastructure creation, they cannot always control credentials created via consoles or external scripts. This distinction between deployment identity and provisioned credentials complicates governance efforts.

Why it matters

For teams running their own software, orphaned keys represent a silent security debt. A forgotten virtual machine incurs financial costs, but a forgotten credential grants potential access to sensitive data and systems. Attackers do not need to know a key is orphaned to exploit it; they only need it to be valid. As AI agents proliferate, the volume of these non-human identities will grow, increasing the attack surface if proper governance is not implemented.

Manual annual audits are insufficient given the speed of automated attacks. Teams need continuous visibility into credential usage. Without automated queries and policies, security leads may remain unaware of active keys associated with defunct projects. This lag between project closure and credential revocation creates windows of vulnerability that sophisticated attackers can exploit rapidly.

Furthermore, reliance on infrastructure-as-code tools alone is not enough. While tools like Terraform can manage key creation, they do not automatically revoke keys if the destruction process fails or if keys are created outside the managed environment. Teams must verify revocation actively rather than trusting countdown timers or deployment scripts.

What you can do

• Run SQL queries against synced IAM credential reports to find active keys unused for more than 90 days.
• Implement approval policies in deployment platforms to block the creation of long-lived credentials in Terraform or OpenTofu plans.
• Prefer OIDC-based federation for deployments to use temporary credentials that expire with the session.
• Set environment TTLs for disposable credentials but verify actual revocation through state checks.
• Deactivate suspicious keys first to monitor for authentication errors before permanently deleting them.
• Assign explicit owners to all non-human identities and record ownership in your credential inventory.

The closing section appears below.