The AWS Keys in Your Dotfiles

Open your ~/.aws/credentials file. The access key in it is probably older than the laptop it's sitting on. You know it's a risk. So does everyone else with a laptop. But it still slides to next quarter, every quarter.

Nobody chose this on purpose

This is the fourth post in our build-versus-buy series. The earlier pieces looked at real systems teams stood up themselves: the SSH bastion, the secrets script, the homegrown audit log. This one is different. Almost no one sat down and decided that static keys on laptops were the architecture.

You meant to set up federated, short-lived credentials the right way. Then something was on fire, and the fire won every sprint for two years. So thee keys are still on the laptops.

That changes the buy case. There's no broken system to replace here, just a gap you documented two years ago and never had a spare quarter to close.

What the keys cost you

For the engineer, a key in a dotfile travels. It ends up in shell history, in a backup, in a screen share or in a repo you swore was private. Once it leaks it works from anywhere, for as long as it stays valid. For most static keys, that's forever. There’s no session to expire and no identity to trace it back to.

For the person who owns the budget and the audit, the cost shows up later and stings more. When an assessor asks who had access to production cloud accounts last March and what they did with it, “we issued keys and hoped people rotated them” is not an answer that passes. You can’t produce a clean access trail for credentials that live on machines you don’t control.

The version you meant to build

The design is actually quite simple, the problem is that it's never been anyone's top priority.

Access to the cloud console and CLI runs through a broker. The engineer signs in with your existing identity provider, gets a time-bound, just-in-time grant to a federated role, and starts working. The actual cloud credential is never handed to them. Their CLI traffic is proxied through a local loopback, and the credential gets injected at the last mile, right before the request reaches the cloud provider.

So the engineer runs aws s3 ls and it works, with no key to copy, no key to leak and nothing sensitive in ~/.aws/credentials. Access is scoped to who they are and expires when the session does. Every action lands in one audit trail across AWS, Azure and Google Cloud. You get the federated, short-lived model you sketched out running this month, without staffing a project to write it and keep it alive.

Your scripts and agents use the same door

Static keys were never only a human problem. Every quarter, less of the traffic hitting your cloud APIs comes from a person. Cron jobs, continuous integration pipelines and now agentic tools all reach APIs, and they’ve historically done it the way people did: with a long-lived key baked into a config file or an environment variable.

Last-mile injection doesn’t care whether a person or a script is on the other end. A pipeline or an AI agent gets a brokered, time-bound identity and the credential injected at the point of use, exactly like an engineer typing a command by hand. The same policy engine and the same audit trail cover both. Most teams can name every engineer with cloud access, but few can name every pipeline.

Where this stops

This covers access to your cloud consoles and CLIs: getting the right identity into the right session with the right credential, and recording what happened.

It isn't cloud posture management or IAM governance. It won’t map your entitlement graph or flag which IAM policy is over-permissive. It brokers the access, not the cloud IAM sitting behind it. If someone tells you one product does both, read the fine print. The keys are on the laptops today.

See how last-mile credential injection works in a 10-minute walkthrough.