This is exactly what you get

Why it matters

A long-lived AWS access key ID sits next to its secret in almost every leak, and together they grant programmatic access to the account. Public repositories are scanned for the AKIA prefix within minutes of a push. Attackers use found keys to spin up compute for crypto mining, read S3 data, or pivot deeper into the account.

How to fix it

Move the key ID and secret out of source and read them from the environment or an instance role. For local use keep them in ~/.aws/credentials or an untracked .env; in production prefer IAM roles over static keys entirely. Then deactivate and delete the exposed key in the IAM console, because git history still holds it.

Example locations shown. Your real scan points at your own files.

Remove the hardcoded AWS access key ID (and any adjacent secret access key) at src/lib/aws-client.ts:14, scripts/deploy.ts:47. Replace each with a read from the environment (process.env in Node, os.environ in Python) or, better, note where an IAM role should be used instead of static keys. Add the variable names to .env.example with placeholder values and do not commit real values. Do not change the AWS SDK calls or region config. In your summary, list every exposed key ID so I can deactivate it in IAM, since removing it from code does not revoke it, so it still has to be rotated with the provider. Verify by grepping tracked files for AKIA and finding no matches.