Short-Lived AWS Credentials for Coding Agent Sessions

Short-lived AWS credentials, minted fresh for every coding agent session and killed the moment that session ends, are not a nice-to-have on top of good secrets hygiene. They are the primitive that sets whether agentic cloud access is survivable at scale, because they set the outer bound on how much damage a single compromised session can do.

The context for why this matters now is straightforward. By early 2026, a majority of professional developers, 51% by one count, were using AI coding tools daily, and the most capable of those tools had stopped being autocomplete and become agents. Delegation changed shape along with them: engineers stopped asking a model to finish a line of code and started handing it an issue, a database migration, or a CI failure to triage on its own. The agent decides what tool calls to make. That's a different risk profile entirely from a human with admin access, who acts a handful of times an hour and generally pauses to think about consequences before hitting enter. An agent acts at machine speed, can loop indefinitely, and can be redirected mid-task by untrusted text it happens to read while working. None of that is theoretical anymore, and none of it is fixable by better secrets management alone.

What standing credentials expose when an agent holds them

Start with the scale of leakage, because it tells you this is a habit, not an accident. GitGuardian's 2025 report documented 28.65 million new secrets leaked on GitHub, up 34% year over year, and within that figure, 1.2 million were AI-service secrets specifically, up 81%. Those numbers describe a pattern: mint a standing credential, put it somewhere convenient, hand it to a process. AI agents didn't invent that pattern. They inherited it from a world of cron jobs and long-running services that were never designed to be pointed at input they hadn't seen before.

Three incidents make the mechanism concrete. In July 2025, the Amazon Q Developer extension shipped with an inappropriately scoped GitHub token in its build configuration (tracked as CVE-2025-8217 / GHSA-7g7f-ff96-5gcw). An attacker used that opening to land a malicious commit carrying an injected instruction: delete S3 buckets, terminate EC2 instances, delete IAM users. The extension had an install base over 960,000 by the time the issue surfaced. The payload was malformed and didn't actually execute, which is the only reason this reads as a near-miss instead of a disaster. But the path from credential to destructive cloud operation was already complete before anyone caught it.

Later in 2026, a prompt-injection payload hidden in a GitHub issue title tricked an AI workflow into running a malicious npm install inside a CI/CD runner. That install stole npm credentials, which an attacker then used to publish a trojaned package that landed on roughly 4,000 developer machines. Nobody typed the install command. Nobody reviewed it before it ran. The agent read untrusted text, treated it as an instruction, and acted with the full authority of every secret sitting in its environment at the time.

The Cline repository attack follows the identical shape. An attacker's issue title hid a prompt injection that hijacked the project's AI triage bot, which then ran malicious code on a GitHub Actions runner and poisoned the Actions cache. The nightly publish workflow restored that poisoned cache and exfiltrated npm publishing credentials. An unauthorized version of Cline sat live on npm for about eight hours, a window wide enough to expose every user with auto-updates turned on.

Looking across all three, the common thread isn't sophistication. The agent wasn't hacked in any interesting technical sense. It was given a shell and it was given credentials, and then it was pointed, directly or indirectly, at input nobody trusted. No single step in any of these chains was exotic. A Gravitee survey of 919 organizations found that 25.4% still use hardcoded credentials for tool access, and only 21.9% treat agents as independent identity-bearing entities with their own permissions and audit trail. The three incidents above are the expected output of that backdrop. They're the expected output of it.

Better secrets management doesn't change this math. Rotating a key faster, encrypting it more carefully, or storing it in a nicer vault does nothing to stop an agent from using that key the instant it's compromised. Only the lifetime of the credential decides how far the blast radius can travel before the door shuts.

Why credential lifetime is the primary control, not a secondary one

The security value of any credential runs inversely to how long it stays valid. Encryption at rest, rotation policy, secrets managers: all of that is damage control after the fact. Lifetime is the only lever that actually prevents the damage from happening in the first place.

Think through what exploitation actually requires. An attacker holding a stolen credential has to figure out what it unlocks, enumerate the resources it can reach, decide what's worth taking, pivot laterally if there's more to grab, and set up some form of persistence before anyone notices. Each of those steps costs time, and the sequence rarely completes instantly, even for a well-resourced attacker. Shrinking the credential's lifetime enough breaks the chain somewhere in the middle: the token expires before step three finishes, and the attacker is back to square one with nothing but a dead key.

Speed matters here more than it used to. Automated bots scan public commits, paste sites, and CI logs continuously, and they test exposed keys within minutes of finding them. Against that kind of scanning, a credential valid for 24 hours is a generous head start for whoever finds it. A credential valid for five minutes often expires before exploit tooling even finishes its first pass.

Agents multiply the exposure in a way that plain applications never did. A single agent authenticating with a static key is one point of exposure. A hundred agents authenticating with static keys form something closer to a mesh, where one leaked key can be walked laterally across the whole fabric of connected systems. Nobody rotates that by hand fast enough to matter.

Four things about how agents behave make static keys worse for them than they ever were for a traditional long-running service. Agents run continuously, with no human click acting as a natural boundary on when the credential gets used. Their behavior isn't fully predictable, since actions emerge from model reasoning rather than a fixed code path someone can audit line by line. A single task often reaches across many systems at once, so one credential ends up touching many blast surfaces. And agents scale and replicate on container timescales, spinning up and tearing down faster than any provisioning process built around a human clicking "create user."

The SANS 2026 NHI Survey, which polled more than 500 security professionals, found that 80% of identity breaches involve a compromised non-human identity credential, and separately that 74% of organizations now deploy AI agents or automations that require credentials of their own. Overlay those two figures and you get the exact surface that short-lived credentials are built to close.

How AWS STS issues short-lived credentials and what the limits are

AWS Security Token Service is the mechanism most teams reach for first, and for good reason: it issues temporary credentials the moment a workload assumes an IAM role, costs nothing extra to use, plugs directly into existing IAM policies, and refreshes automatically without anyone babysitting it.

"Short-lived" means different things depending on which STS call is doing the issuing. AssumeRole defaults to one hour, can go as low as 15 minutes, and can extend up to the role's configured MaxSessionDuration, which tops out at 12 hours, though role chaining caps the whole thing at one hour regardless. GetFederationToken defaults to 12 hours and ranges from 15 minutes to 36 hours. GetSessionToken follows the same 12-hour default and 15-minute-to-36-hour range for IAM users, but the AWS account root user is capped much tighter, at a maximum of one hour.

What that buys you, honestly, is a jump from "static forever" to "expires in fifteen minutes at the very minimum." That's a genuinely large improvement over a key sitting in a .aws/credentials file indefinitely. It is not, however, a sub-minute credential, and treating STS as the finish line rather than the floor undersells what a determined scanner can do inside a fifteen-minute window.

The practical pattern for agent sessions is to pass the temporary credential set (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN) into the agent process as environment variables, never as CLI arguments that show up in process lists, and never written to a config file the agent might read back into its own context. Injecting credentials only as environment variables, never as CLI arguments or config-file entries, prevents them from showing up in process lists or being read back into the agent's own context. Long-lived keys beginning with AKIA typically live in plaintext inside ~/.aws/credentials, which is a classic exfiltration path even without an agent in the loop. An agent given a shell and pointed at a project directory has a real chance of misreading a .env file at some point and ships those keys straight into its own logs or its own context window.

SSO configuration carries a similar trap. The legacy sso_start_url setting inside a profile produces a long-lived session with no automatic refresh, which is exactly the kind of extended window agent workloads shouldn't have. The current recommended approach splits SSO connection details into a separate [sso-session] section, which does support automatic token refresh. Never point an agent's AWS_PROFILE at a human's poweruser profile. That profile stays local, and it stays human-only.

The SSO session's own lifetime and the permission set session's lifetime that IAM Identity Center enforces underneath it are two distinct things, even though they sound identical. For high-risk agent workloads, the permission set side is the one to tighten, down to an hour or less, and further down to 15 minutes when the workload is also using AssumeRole underneath.

ReadOnlyAccess is not a safe default just because it sounds passive, a mistake that appears often enough in IAM configurations to call out directly. It still lets a session fetch S3 object contents, pull Lambda function code, and read DynamoDB records, all of which can leak sensitive data even without a single write permission attached. When an agent is driving the AWS CLI from inside a shell, IAM policy is the only thing actually stopping it. No amount of prompting or tool-side guardrail substitutes for that. The design principle bears repeating here from AWS's own security guidance: assume every permission granted will eventually get used, whether intentionally or not, and scope the role around the blast radius of that assumption rather than around the workflow you expect the agent to follow.

Architectures that go shorter than STS: SPIFFE/SPIRE, keyless auth, and token brokering

Fifteen minutes is a floor, not a target, and several architectures now push well past it.

SPIFFE and its reference implementation SPIRE were built for workload identity generally, not agents specifically, but the fit is close. SPIRE's SVID lifetime is configurable down to a matter of minutes. For JWT-SVIDs in particular, which can't be revoked mid-life the way a certificate can, SPIRE defaults to a five-minute, 300-second TTL. A short-lived credential in that range is something an attacker genuinely cannot outrun with automated tooling. SPIFFE runs across Kubernetes, AWS, GCP, and on-prem environments alike, and it's already in production at companies operating at the scale of Uber and Netflix for workload identity broadly.

A different approach removes the standing key from the picture entirely. Anthropic's Workload Identity Federation, generally available since June 2026, lets a workload authenticate to the Claude API using short-lived OIDC tokens minted from whatever identity provider that workload already trusts, whether that's AWS IAM, Google Cloud, a Kubernetes service account, GitHub Actions, Entra ID, or any standards-compliant OIDC issuer such as Okta or SPIFFE itself. Federation rules configured in the Claude Console bind an external identity to a service account, and at runtime the workload presents a signed JWT in exchange for a short-lived access token from Anthropic. The SDK handles the exchange and the refresh automatically, and the coverage extends across every Claude API endpoint, Claude Code included. A headless agent running inside CI can operate with no static API key sitting anywhere in its environment.

AWS's own AgentCore pushes the same idea into token brokering. AgentCore Gateway supports OAuth 2.0 On-Behalf-Of token exchange through AgentCore Identity, built on RFC 8693 for token exchange and RFC 7523 for JWT authorization grants. Under this model, an agent never holds a key at all; it acts downstream as a bounded delegate carrying a token that someone else issued and can revoke. The chain runs from an authenticated MCP session with a bounded time-to-live, through an On-Behalf-Of token exchange, into short-lived STS credentials scoped to a specific role for roughly an hour, and finally out to the downstream tool or AWS API. At no point in that chain does a standing key exist anywhere. Auth0's reference integration for this pattern evaluates authorization per action, at the moment the action happens, rather than baking a fixed set of permissions into a key at provisioning time.

The Model Context Protocol's 2025 spec revisions formalized OAuth 2.1 for exactly this use case. A remote MCP server operates as an OAuth 2.1 resource server, PKCE is mandatory rather than optional, and clients are required to use Resource Indicators under RFC 8707. A token minted for one MCP server literally cannot be replayed against a different one. AWS's own MCP Server picked this up in July 2026, adding OAuth 2.1 authorization through AWS Sign-In so that agents such as Claude Code, Kiro, and Gemini CLI can connect using either browser-based authentication for interactive sessions or existing IAM credentials for headless, non-interactive ones.

HashiCorp Vault's dynamic secrets fit the same philosophy from a different angle: Vault generates a fresh credential on demand, attaches a configurable TTL and a lease ID that expires automatically, and issues a unique key for every request rather than handing out the same one repeatedly. An agent using Vault this way never holds a long-lived credential at any point in its lifecycle.

Stripping all of these down reveals five shared verbs as a checklist. Issue credentials on demand, based on proven identity. Scope them to the task at hand, not to the agent as a standing entity. Rotate automatically, invisibly, without a human in the loop. Revoke through an explicit emergency path, backed by a soft expiry that fires even if nobody pulls the trigger. Audit every credential back to the specific workload and task that requested it.

Governing agent identity across multi-agent chains and delegation hierarchies

Multi-agent systems change the shape of identity management entirely. Every agent instance, every orchestrator coordinating them, every tool connector in between becomes a workload with its own identity to manage. A single agent task can touch an LLM provider, a vector database, several MCP servers, external APIs, and cloud storage, all within a few seconds and without a human anywhere in that loop.

Legacy IAM wasn't built to see any of this. Each action inside an agentic chain can create a new trust relationship on the fly, one that IAM was never designed to validate because IAM assumes stable, human-scoped roles that don't change shape mid-session. An AI agent is a non-deterministic actor. It can be talked into unexpected behavior by input it reads while working, and a permission model built around fixed roles has no good way to anticipate that.

The governing rule follows from that directly: treat each AI agent as its own non-human identity, with its own execution role, its own trust policy, and its own review cycle, scoped to the smallest working set of permissions it actually needs. Wildcard access has no place here. And in a delegation chain specifically, tokens should never simply pass through unchanged from one agent to the next. They should be brokered instead: each hop mints a new, appropriately scoped credential rather than reusing the one it received. Passing a shared token down a chain means a single compromise anywhere in that chain propagates to every downstream system the token happens to reach.

AWS addressed this failure mode directly in July 2026 with a three-layer Cedar policy model, paired with OAuth 2.0 authentication and built on Amazon Verified Permissions, aimed specifically at preventing authorization scope from expanding as it moves through a multi-agent delegation chain. The failure it targets is exact: an orchestrator agent's effective permissions creeping wider as it delegates work to sub-agents beneath it, until the sub-agent at the bottom of the chain ends up with more access than anyone intended it to have.

The 2026 OWASP Agentic Security Top 10 places identity and credential handling at the center of agent risk rather than treating it as a footnote. Agent Identity and Privilege Abuse sits among the top four risks in that list, and it intersects directly with prompt injection, since the entire attack path documented across the Amazon Q, npm, and Cline incidents runs through exactly that intersection: untrusted input steering an over-privileged identity.

A governed execution model, described by Qovery in September 2026, offers a practical shape for closing this off. The agent never touches cloud APIs directly. It calls a narrow, authenticated control plane instead, which authenticates the agent as its own distinct identity, checks the requested action against policy, authorizes only what's scoped for that specific task, executes using short-lived credentials generated for that moment, and logs the result. Nothing about that pattern is exotic. It's the same discipline organizations have applied to service-to-service authentication for years, applied now to an actor that reasons about what to do next rather than following a fixed script. This time, the actor reading untrusted input and deciding what to do with it is exactly the reason the discipline can't be optional anymore.