It is obviously an individual’s mistake, but I believe that it might reveal internal practices.

Understatement and a half. People storing a bunch of passwords insecurely and leaking them is one thing, but this thing in my opinion implies at least:

• System specific user accounts, rather than SSO based on user permissions (with authenticating proxies where necessary if theres no native software support). Realistically for internal use one person should only have a few user accounts total for the entire org (if you want to separate the regular office work account and management accounts for the people who need it)

• Not using hardware based auth with things like FIDO2 or PIV, no reason for password use except in exceptional circumstances in 2026. Smart card SSO is old news by now.

• Access tokens stored anywhere outside a secret vault which provisions them directly to services without human read access after creation (or highly monitored and audited access if write only is not possible) and automatic creation in cases of internal systems where everything can be generated and provisioned automatically. Of course if in this case the supposed important aws tokens are actually just strictly scoped dev tokens it might be understandable, but based on my reading of the article it wasn't.

• External service accounts stored anywhere outside a monitored, audited and strictly scoped secret vault, with strict policies forbidding local long term storage (say for things like a vendor account management dashboards used for billing and such)

There's probably more.

In general the poor state of secrets management in organizations is quite sad. Even in supply chain attacks its always "developer got malware and had full permission API tokens on his dev machine to take over all his repositories and packages"

This reads to me as "startup starring a man, a .env file, docker and a dream" levels of security.