AWS IAM user access keys don't expire automatically, leaving forgotten credentials valid indefinitely until someone manually disables or deletes them—a problem that opens the door to attackers who move faster than annual audits. A technical infrastructure report published by The New Stack in October 2026 examines the lifecycle challenge of managing credentials for AI agents and automated workloads. The report concludes that unowned, long-lived credentials represent a security gap that demands proactive governance through queries, policies, and enforced expiration mechanisms.

The report describes a credential lifecycle problem in which an agent is created for a task, the task ends, and nobody revisits its access. OWASP ranks improper offboarding as the top risk in its 2025 Top 10 for non-human identities, with the recommended fix being to retire what's no longer needed and assign the rest an accountable owner. In September 2026, GreyNoise documented an AI-orchestrated campaign against PaperCut servers that went from an empty workspace to remote code execution at a real victim in under four hours, and once launched, the campaign compromised at least eleven organizations in 26 seconds. The report notes that this wasn't an attack using abandoned AWS IAM keys but demonstrates how quickly exposed access becomes useful once an attacker gains entry.

According to the report, "a departing person triggers offboarding; a finished agent just leaves a closed tab." The authors emphasize that this doesn't require carelessness—it's a structural problem where an agent's deployment identity authenticates it to a cloud account, but a provisioned credential is a persistent key, secret, or token that exists for another workload with different owners and revocation procedures. The report states that "a forgotten VM costs money; a forgotten credential can grant access," and warns that "an old key doesn't need to be labeled orphaned for an attacker to use it; it only needs to be valid."

The report explains that attackers exploit dormant credentials because the gap between credential creation and revocation is typically measured in months or years, while modern attacks move in hours or seconds. The hard part, the authors note, isn't knowing what to do—it's knowing what exists in the first place. The report recommends a three-part remedy: queries that find keys no one is using, policies that prevent agents from minting new long-lived keys at deploy time, and enforced expiration through environment time-to-live settings or manual deactivation with monitoring. For keys outside any environment lifecycle, the report advises retiring them under control by deactivating first, watching for authentication errors through an observation period matched to the workload's schedule, getting owner sign-off, then deleting under change procedures since deletion isn't reversible. The bottom line: every credential needs an end date, and agents who finished last quarter's projects won't flag their own credentials—the next agent to encounter one might not belong to your organization. Platform teams that don't enforce credential lifecycles are handing attackers keys that stay valid long after the work is done, and no amount of perimeter security compensates for access granted from the inside.