I rotated a leaked AWS access key at 2 AM last year. A contractor had pushed a workflow that printed environment variables for "debugging," GitHub's secret scanner caught it about four minutes later, and by the time I'd revoked the key and audited CloudTrail, I'd lost an hour of sleep I still resent. That was the night I went all-in on OIDC for GitHub Actions. If you're still using long-lived AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in your repo secrets, this post is for you. I'll walk through what OIDC actually does, why static keys are a rake to be stood on, and exactly how to wire it up — IAM trust policy, workflow YAML, all of it. The Problem With Static Access Keys Let's be honest about what an AWS access key in GitHub Secrets really is: a permanent credential sitting in a system you don't fully control . A few things go wrong in practice: They never rotate. I've audited orgs with five-year-old keys still in use. Nobody wants to be the person who breaks a deploy by rotating the wrong one. They leak.…