{
  "id": 16910818,
  "title": "What happens when the agent is long gone, but its access key lives on?",
  "url": "https://urgent.news/2026/10/28/what-happens-when-the-agent-is-long-gone-but-its-access-key-lives-on",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-28T14:00:00.000Z",
  "source": {
    "name": "The New Stack",
    "slug": "the-new-stack",
    "url": "https://thenewstack.io/governing-ai-agent-credentials/"
  },
  "original_language": "en",
  "account": "When a developer creates an IAM user called research-agent-2, a corresponding access key is generated and assigned. This key remains active even though the project it supported has long since closed and the original approver is no longer employed at the company. This scenario is not an isolated case; it reflects a broader issue where agents are created for tasks, but once the task is finished, the access key is left untouched. AWS IAM user access keys do not expire automatically, remaining valid until someone takes action to disable or delete them. The lack of automatic expiration means that forgotten keys can stay active indefinitely, posing a security risk. Improper offboarding is highlighted as a critical problem in OWASP's 2025 Top 10 for non-human identities, emphasizing the need to retire unused keys and assign accountable owners to the remaining ones. However, the challenge lies in identifying what no longer exists. Attackers are swift, capable of turning an inactive AWS IAM key into a tool for remote code execution within just a few hours. This rapid escalation underscores the dangers of delayed inventory and revocation processes. To address this, it is crucial to ensure that every agent's access is governed throughout its lifecycle. The articles previously discussed in this series covered methods for attaching an owner during discovery, reassigning the responsibility before an agent's last day, and the specific ramifications when the owner is an agent. A significant distinction exists between an agent's deployment identity, which authenticates it to a cloud account, and provisioned credentials, which are persistent keys, secrets, or tokens assigned to other workloads. The remedy for managing this issue involves a systematic approach: querying for inactive keys, implementing policies, and ensuring timely revocation. The process begins with a query that identifies keys that are no longer in use. CloudQuery can sync AWS IAM credential reports into a database, creating a table named aws_iam_credential_reports. This table lists up to two access-key slots per user, detailing the active status and last used date for each key. A SQL query is then written to extract active IAM user keys that have been unused for at least 90 days. The query retrieves the latest synchronized row for each AWS IAM credential report, turning the slots into rows and returning keys that meet the criteria of being active, yet older than 90 days without any use. The query returns key details such as the account ID, ARN, principal (user or role), key slot, creation date, and the last used date. The query skips the root account, which requires a separate, urgent audit, and recommends not having access keys for it. For PostgreSQL users, the query syntax includes specific instructions for handling the ARN (Amazon Resource Name), ensuring unique identification of each report. On different cloud platforms, similar concerns arise but manifest in distinct ways. For instance, in Microsoft Entra ID, the entraid_serviceprincipals table includes credential metadata, while entraid_serviceprincipal_owners identifies accountable entities. In Google Cloud, the gcp_iam_service_account_keys table can be used to inventory service-account keys if that table is enabled in the data sync. The overarching remedy remains consistent: a query to locate unused and outdated keys, followed by a policy-driven approach to revoke those keys promptly. This multi-faceted strategy helps mitigate the risk posed by overlooked or forgotten access keys, ensuring that only active and necessary credentials remain.",
  "summary": "Imagine: There’s a line on the credential report that no one on the platform team can explain. An IAM user The post What happens when the agent is long gone, but its access key lives on? appeared first on The New Stack .",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}