>Valadon said he reached out because the owner in this case wasn’t responding and the information exposed was highly sensitive.
obviously leaking the credentials itself is crazy, given that its (a contractor to) CISA, but to not respond when notified? crazy crazy.
but wait! it gets worse somehow
"“AWS-Workspace-Firefox-Passwords.csv” — listed plaintext usernames and passwords for dozens of internal CISA systems"
while i understand and sympathize with the fact that CISA is kind of being gutted, a passwords.csv with weak passwords is inexcusable incompetence. not much budget is required for a password manager.
embarrassing all around.
tantalor 1 days ago [-]
The word you're looking for is "gross negligence"
gleenn 1 days ago [-]
Sometimes I feel like it's a cover for some other org actually just wanting to steal the data and this being the excuse.
bix6 1 days ago [-]
You mean like if our government was compromised at the highest levels and they wanted to undermine everything without the public realizing? Btw what happened to all the social security data that DOGE exfiltrated?
juvoly 1 days ago [-]
When empires collapse, it's usually not caused by a foreign power, but by negligence and corruption from within
red-iron-pine 1 days ago [-]
the fact we're asking about it means the public realized
the problem is the public is dumb, at least when it comes to security, and couldn't tell you why password123 is bad
bix6 1 days ago [-]
I think most people realize that leaving your passwords in public is dangerous.
HoldOnAMinute 1 days ago [-]
Don't they call this "parallel construction" or some such ?
john_strinlai 1 days ago [-]
"crazy crazy" gets the same point across
binkHN 1 days ago [-]
Yeah, but the words gross negligence is legal for you're going to be sued for a whole lot of money.
sandeepkd 1 days ago [-]
While I agree that it should not have happened, at the same time its probably true that most people are never formally trained on security.
The real story here is a big gap in existing implementations where shared credentials are needed and used pretty much across all the systems but there are no good solutions for managing such use cases. People are naturally more sensitive about their personal secrets than something thats shared across the company/group
mikestew 1 days ago [-]
The real story here is a big gap in existing implementations where shared credentials are needed and used pretty much across all the systems but there are no good solutions for managing such use cases.
This strikes me as so wrong, I wonder if I’m misreading your comment. For instance, team password managers are a thing. And IT teams at many large corporations are not passing around an unsecured CSV files full of passwords.
sandeepkd 1 days ago [-]
Lets take a concrete example, suppose you have AWS root account credentials. Are you going to assign them to one individual identity or as a company you would keep them accessible to a group of admins. Its going to be the second choice almost for every big company which makes them shared credentials.
Coming to team password managers at high level, its a shared location guarded behind closed doors (probably encryption at transit and rest). They would be another set of software that every company specially small business or contractors may not be incentivized to pay for. Some one in their naivety considered Github as a safe enough place, assuming that the access is guarded which turned out to be wrong and exposed this thing.
Lastly IT teams in large corporations being secure is a myth for most part. Your root keys for the most popular CA providers were shared in plain text emails not so long ago.
acdha 23 hours ago [-]
> Lets take a concrete example, suppose you have AWS root account credentials. Are you going to assign them to one individual identity or as a company you would keep them accessible to a group of admins.
You’d use AWS Organizations so each admin authenticates using their own credentials, gets short-term credentials to access the member account for the handful of operations needing root, and audit usage. It’s not only more secure, it’s also easier:
Old school, you’d have a shared password in an encrypted team vault (possibly requiring x of y users to decrypt it) and two FIDO tokens locked in a safe. Again, this is rare and at a federal agency you have a physical security team with 24x7 staffing so you can say “in an emergency, one of the people on this list can get a key out of a safe in the CIO’s office”.
sandeepkd 20 hours ago [-]
great, now apply this to a 4 person startup who are just focussed to get business somehow. This is not on their radar and they would not be willing to spend money to address this either cause its not a problem that they are even aware of.
This is a tip of ice-berg, companies like openai, anthropic, perplexity, stripe, all of them have implemented their authentication and security flows in some interpreted language (python, ruby, typescript) cause that was the readily available talent on their product teams and most likely a good number of them do not even have their dependencies locked in.
acdha 13 hours ago [-]
That’s a pretty different scenario than we’re taking here, but it still doesn’t salvage your previous comment. Those people could still use one of the password managers which support this, which again would be easier than what this guy did.
sandeepkd 9 hours ago [-]
I am not trying to find an excuse when something is clearly wrong, what I am trying to share is how we ended up in a particular situation. The scenario is not much different, the rationale is that security (secure practices) are not the part of the product offering for most products/contracts. I have lost quite a few battles to management for security, it does helps me to understand how people think and priortize. People don't care for what they do not understand.
Hikikomori 1 days ago [-]
We deleted the root credentials efter initial setup where we added mgmt iam accounts used by our automation. If we ever needed them we used the recovery process. All users and services use temporary credentials.
sandeepkd 1 days ago [-]
I made an assumption that you have federated AWS account setup. One organization management AWS account and then federated accounts under it and you are referring to deletion of deletion of ROOT credentials in the federated accounts.
Considering thats not the case, what you just did is move the goal post to a account recovery process. Question becomes who has ability to recover the account, in case its tied with email then most likely it has to be a shared email box. What you have now is a much more fragile system in case of custom domains, where whoever is controlling the email domain (DNS management capability) can take over the AWS accounts.
Hikikomori 1 days ago [-]
One account, org, federated, whatever. You don't need to store the root credentials.
An email per account where only security team has access. Whoever can modify domain can already do this.
sandeepkd 1 days ago [-]
This would be a incorrect representation/comparison of the problem being discussed. The semantics of ROOT account changes in the case when a separate management IAM account is introduced. In this case the question would become how you are securing the ROOT credentials for the separate AWS IAM management account/tenant.
Hikikomori 1 days ago [-]
What part of we store no root credentials is confusing?
antonvs 1 days ago [-]
This organization is using AWS apparently. They would store the root account credentials in AWS Secret Manager. That costs $0.40 per month. People in the relevant admin group would have access to them. They would log in with their individual AWS credentials in order to access the root credentials if they need that.
But, requiring AWS root credentials itself is an anti-pattern and implies an immature organization. That should not be needed for day-to-day operation.
This is all just ignorance and incompetence, nothing more.
> Lastly IT teams in large corporations being secure is a myth for most part.
This is CISA. The Cybersecurity and Infrastructure Security Agency for the United States. Security is what they're supposed to specialize in.
The only potential excuse here is that DOGE gutted them to a point that has completely compromised their capabilities. However, this situation is bad enough that it suggests that problems predated that incident.
sandeepkd 1 days ago [-]
To be honest I do not know how to respond to this, cause this plays out quite often this way and sounds pretty convincing on surface. Unfortunately this is the gap between theory and implementation. There is a reason why the ROOT credentials are called ROOT. In case of anything going wrong, all your regular user accounts would be locked, see how you lock yourself out of this circular dependency. ONE SHOULD NEVER NOT PUT THEIR ROOT CREDENTIALS IN THE SECRET MANAGER OF SAME ACCOUNT. Its a classical circular problem, compilers compiler type. For AWS itself they have this additional concept of management account that allows you to defer this problem to just one more level.
Bottomline, you can have any number of boxes to lock other boxes and put their key to bounding box, ultimately there would be one outermost box that is locked by key which is not in any box
antonvs 9 hours ago [-]
> In case of anything going wrong, all your regular user accounts would be locked
You're talking about a very specific and rare scenario, and certainly not something that justifies storing all your passwords in plaintext in a CSV file.
In almost all scenarios where you would need root credentials, having them in the provider's secret manager is fine.
Obviously you need to store root credentials outside of the secret manager as well, but that should be a "break glass" scenario that's only used in emergencies. And you don't store them in plaintext CSV.
> Unfortunately this is the gap between theory and implementation.
I don't disagree that there are many, many organizations that practice bad security. But that doesn't mean there are none that have good security. And one would expect CISA to have good security, otherwise there's really no point in its existence.
There's a difference between saying "this is what most organizations are like" and "this is the way it has to be". The former is true, the latter is false.
realo 1 days ago [-]
You are right... Most use Excel files ...
throwawaypath 1 days ago [-]
>For instance, team password managers are a thing. And IT teams at many large corporations are not passing around an unsecured CSV files full of passwords.
It's CURRENTYEAR. No one should be using team password managers or files to store credentials. There should not be storable credentials.
acdha 23 hours ago [-]
None of this is true at the federal level, or at least wasn’t before the current administration. There are standards for all of this, and if you haven’t read them most are quite reasonable — I keep the NIST 800-63 reference handy anytime someone tries to say password expirations are a good idea — and there are people who are paid full time to enforce them.
Having a password list or static AWS credentials is not only a direct policy violation but also implies a number of other failures, from monitoring GitHub repo administration and secret scanning to failure to enforce policies against sharing credentials (part of everyone’s standard training), require use of phishing-proof authentication, failure to use short-term credentials, etc. One mistake can be an individual but this is a multiple-manager failure going up to the executive level.
MrDarcy 1 days ago [-]
The error and omission of not enforcing mandatory security training covering posting plaintext passwords to public sites for CISA contractors is itself an act of gross negligence.
So much so the contracting company’s insurer would cite it as the reason why the claim is not covered by their policy.
morpheuskafka 1 days ago [-]
He worked for CISA. Surely there is either a security clearance with indoctrination and training, or at the very least, some sort of mandatory training/onboarding for all contractor staff?
antonvs 1 days ago [-]
> shared credentials are needed and used pretty much across all the systems but there are no good solutions for managing such use cases.
What do you mean by this? There are password managers and more enterprise-oriented secrets managers, and application platforms typically have integration with them. Individuals shouldn't be using shared secrets. This is a completely solved problem and it's not difficult to set up properly, especially in a cloud environment like AWS, where you can use services like AWS Secrets Manager.
1 days ago [-]
Forgeties79 1 days ago [-]
> While I agree that it should not have happened, at the same time its probably true that most people are never formally trained on security.
This isn’t a grocery store or something it’s CISA. This is like a gun going off in a cop’s holster while he’s texting and driving without a seatbelt. Yeah he’s a contractor but that doesn’t suddenly allow for such incompetence.
sandeepkd 1 days ago [-]
I have worked with some of the experienced folks in federal space in the past, who were super smart, experienced and COSTLY from managements perspective. They had the ability to challenge the management on such things. Most of them have either retired, managed out or moved on. What you have here is not a reflection of the individual but the entire management chain. Its a race to make most money and at times these contractors are number of seats to fill at lowest possible cost.
Forgeties79 1 days ago [-]
Totally agree
nerdsniper 23 hours ago [-]
I think willfully not reporting this is gross negligence, but also other things.
uean 1 days ago [-]
Not defending this person, but it's obvious that this person used Github as a file-sync. Firefox-passwords.html and firefox-bookmarks.html are what you dump before migrating to a new computer and importing them there. An old school practice before FF sync was around.
This is mentioned in the article but it stood out enough to call it here.
totetsu 1 days ago [-]
One the one hand the CISA is being gutted, and on the other hand there is an ever increase of rhetoric about cybersecurity, national interests, critical infrastructure..
SV_BubbleTime 1 days ago [-]
Complaining about gutting, during examples of gross negligence is kind of a sympathy destroyer for me.
array_key_first 23 hours ago [-]
Gutting doesn't magically solve incompetence. It's a anti-solultion that people peddle because it requires literally zero thought or nuance.
If an organization has systemic incompetence and you gut them, then they're still incompetent but now they're also pressured and therefore more likely to make mistakes. So, you're just in a worse position.
jcattle 10 hours ago [-]
On the contrary you can argue that gutting should lead to lower number of mistakes/incompetence.
There can't be any mistakes if no work is being done.
array_key_first 6 hours ago [-]
There's a big mistake in this logic: is work really not getting done?
Because a lot of work has to be done regardless of if you have the money or time to do it. Most government work is actually not optional, there are literal laws saying it has to be done.
And that's what we, very predictably, saw with DOGE.
Like, think about it. You fire say 50% of people. What happens to the other 50%? They twiddle their thumbs?
You've worked a job before, right? And you've had coworkers fired or laid off before, right? Okay, what happens to their work?
Does it disappear into the abyss or do you then take it on? Because in all my experience, I take it on. Come on now.
cindyllm 22 hours ago [-]
[dead]
ImPostingOnHN 1 days ago [-]
Complaining about gross negligence, after all the competence has been gutted out, strikes me as misdirected frustration.
totetsu 22 hours ago [-]
Oh, thats interesting ,. this is one of those things where two people can hear opposite things from the exact same information.
jandrese 22 hours ago [-]
What if they purged all of the competent people and installed party loyalists? That seems to be a recurring theme with this administration. These are guys who unapologetically admire the efficiency of the Nazi party, not realizing that the pervasive incompetence and most levels of the government were one of the driving factors in their ultimate defeat.
ryan_lane 22 hours ago [-]
Gutting organizations _leads to_ these kinds of problems.
downrightmike 1 days ago [-]
That's why we don't listen to rhetoric.
mystraline 1 days ago [-]
Most of the folks I know who were with CISA were purged with the January-March 2025 Doge campaign. 0 notice "we 20 year olds dont understand what you do so fired".
A group was working on Diebold voting insecurity, and foreign implant hacking. Gone.
mxuribe 1 days ago [-]
> ...A group was working on Diebold voting insecurity, and foreign implant hacking. Gone...
The conspiracy theorist in me from years ago would have stated that maybe this action from DOGE was purposeful...but, nowadays, i see lots more incompetence that merely might present/display as conspiracy! lol :-D
1 days ago [-]
jimt1234 1 days ago [-]
The first "hack" I ever reported was when I found a plaintext passwords file on my high school computer network...in 1987. The more things change, the more they stay the same.
g-technology 1 days ago [-]
Mine too, but it was in the late 90’s and I found an open table in an access database that the school district used for grades and attendance. It listed plaintext usernames and passwords for every user in the system. I managed to use that to get to know the districts head of IT and get a summer job with them.
JackGreyhat 1 days ago [-]
Machine Head - Struck A Nerve
The more things change, the more they stay the same.
Wise words, lovely song.
throwaway5752 1 days ago [-]
DOGE. It's DOGE. This is just things going according to plan for people that think the US government is too powerful or that there is a fortune to be made in stealing public sector resources and privatizing them.
It is a bad plan that has and will continue to harm people, but it is intentional.
dude187 1 days ago [-]
Yes, DOGE invented storing lists of text passwords and uploading them somewhere. What a monumental cost savings innovation, surely never been done before!
1 days ago [-]
parineum 1 days ago [-]
Which DOGE employee put this file on GitHub?
throwaway5752 1 days ago [-]
"I didn't create the epidemic, I just fired all the doctors and dissolved the medical schools"
Security doesn't happen by magic. It is enforced by process, maintained by people and systems built and run by people. Furthermore, when people are under stress and underresourced, they make more mistakes. This was inevitable given the budget cuts.
You can't fire everyone at AWS and say one intern will support it, and say that it is a profitable and sustainable restructuring. Any fool can see that will fail, so if it were actually implemented by someone who is not a fool, you can conclude it is intentional.
parineum 1 days ago [-]
The analogy to not posting secrets to the public isn't medical schools and doctors, it's a sign in the bathroom that says "employees must wash hands".
ceejayoz 1 days ago [-]
They replaced the people who put the signs up with people who think signs are too woke.
> Elon Musk’s Department of Government Efficiency (DOGE) has fired more than a hundred employees working for the U.S. government’s cybersecurity agency CISA, including “red team” staffers, two people affected by the layoffs told TechCrunch.
> For four years, [Trump] nurtured deep resentments about CISA, which had declared that the 2020 election was one of the best run in history, undercutting his false claims that he had been cheated of victory. Weeks after taking office this year, he began a campaign of dismantlement.
> Federal programs that monitored foreign influence and disinformation have been eliminated. Key elements of the warning systems intended to flag possible intrusions into voting software have also been degraded; the effects may not be known until the next major election. And contractors who worked with local election officials to perform cybersecurity testing, usually with federal funding, have found the deals canceled.
> In early March, CISA — which is nested inside the Department of Homeland Security — cut more than $10 million in funding to two critical cybersecurity intelligence-sharing programs that helped detect and deter cyberattacks and that alerted state and local governments about them. One program was dedicated to election security, and the other to broader government assets, including electrical grids.
stackedinserter 11 hours ago [-]
Yeah NYT is so trustful source when it comes to Musk or DOGE, aha.
Regardless, do you really think that gov contractors started writing passwords on paper because these layoffs happened?
> Elon Musk’s Department of Government Efficiency (DOGE) has fired more than a hundred employees
How many are left? Hundreds of employees is nothing for government scale.
ceejayoz 1 days ago [-]
They fired the people who might've prevented that.
> Elon Musk’s Department of Government Efficiency (DOGE) has fired more than a hundred employees working for the U.S. government’s cybersecurity agency CISA, including “red team” staffers, two people affected by the layoffs told TechCrunch.
parineum 1 days ago [-]
Not posting secrets to public GitHub repos doesn't need red teaming.
ceejayoz 1 days ago [-]
A red team might well notice that the build process doesn't check for accidentally committed secrets.
jnovek 1 days ago [-]
Storing a bunch of passwords in a plain-text list that an individual can access violates zero-trust AND least-privilege which I think a red team might have some opinions on.
wil421 1 days ago [-]
At my job the commits wouldn’t have even made it to our private GitHub repo. The scanners would’ve rejected it when you tried to push a commit.
They find keys and tokens all the time.
gumby271 1 days ago [-]
And yet, here we are.
skywhopper 1 days ago [-]
The one who fired the team that prevented this sort of thing.
strictnein 1 days ago [-]
What team prevented someone from uploading sensitive information to public sites? This is a billion dollar a year industry (Digital Loss Prevention) and all the solutions suck.
SV_BubbleTime 1 days ago [-]
I’m not sure you can complain that the people who should prevent this type of thing are having their funding reduced what are the example is they just did this exact thing.
parineum 1 days ago [-]
I really hope they didn't also fire the "don't shit your pants" team or that office is going to smell really bad.
malcolmgreaves 1 days ago [-]
DOGE only fired those who were loyal to the facist. Anyone who is competent was illegally fired.
scottyah 1 days ago [-]
[flagged]
john_strinlai 1 days ago [-]
this does not align with.. well.. anything ive read about DOGE
scottyah 1 days ago [-]
[flagged]
mikeyouse 1 days ago [-]
Per the EO that established DOGE, each Agency head established a 4-member DOGE team consisting of a lead, an engineer, a HR specialist and an attorney. Those DOGE teams absolutely did fire thousands of employees after EO 14210 called for huge RIFs across the government.
ceejayoz 1 days ago [-]
You incorrectly mistake "no authority" for "didn't happen". Judges spank the executive branch for exceeding their authority fairly regularly, including in this case.
> The court finds that neither OPM nor OMB have any statutory authority to terminate employees – aside from their own internal employees – "or to order other agencies to downsize" or to restructure other agencies. And, as far as the Elon Musk-led agency is concerned, the judge is withering: "As plaintiffs rightly note, DOGE 'has no statutory authority at all.'"
> A judge on Tuesday declined to immediately block Elon Musk's government efficiency department from directing firings of federal workers or accessing databases, but said the case raises questions about Musk's apparent unchecked authority as a top deputy to President Donald Trump.
modriano 1 days ago [-]
Sure, it could be incompetence. It could also be an intentional strategy to tie up CISA/DHS resources, poison or obstruct CISA/DHS investigations/operations, open up systems to sunlight and journalism, or cause general chaos.
The not-responding-when-notified part makes me think it's not just incompetence.
stackskipton 1 days ago [-]
>The not-responding-when-notified part makes me think it's not just incompetence.
Strong disagree. The person in question probably thought it was a private repo on Github and had a massive deer in headlights reaction when they got contacted. Whoever this is, lost their job, possibly security clearance and more. This was 100% life altering "mistake"/gross incompetence decision they made.
SoftTalker 1 days ago [-]
the CISA administrator disabled the default setting in GitHub that blocks users from publishing SSH keys or other secrets in public code repositories.
That doesn't support the theory that it was a mistake. That was intentional action. Maybe he was being blackmailed, and was coerced to do it. Or maybe he was a foreign agent or sympathizer who had infiltrated the organization.
stackskipton 1 days ago [-]
There has been no indication if this was personally owned GitHub or Organizational owned GitHub. If it's personally owned, it still is one person doing massive dumb. Even if it's Organizational, it's very possible that person in question had rights to do this without oversight.
I've been a government contractor before, it does not employ best and brightest, it employs the average and below generally.
modriano 1 days ago [-]
Maybe. I didn't see enough in the article about the repo owner/committer to make any inference about their intentions and wouldn't jump to conclude it was incompetence or malice or crafty leaking. The only real signal I saw was that the repo didn't immediately turn private when the person was notified.
For some people, yeah, this could be a career killer. For some other people, it might just precipitate a flight back to Moscow or Beijing or something.
1 days ago [-]
delfinom 1 days ago [-]
Dealing with IT departments run wild with cyber security monkeys that can only follow checklists with no independent thought.
The spreadsheet of passwords is a tad more common than it should be because the password managers don't meet whatever arbitrary checklist of invented cyber security requirements they blindly follow. But Excel does.
Lol
epistasis 1 days ago [-]
I think one thing that people are sleeping on is passing a ton of secrets to OpenAI and Anthropic or your OpenRouter by having a .env or secrets on disk in your repo, but not checked in
Your LLM will happily read the entire file, ship it off to be training data for future versions of ChatGPT, and not raise any flags, because let's be fair it was on ok thing to check if all the env vars were set, or it you had set up the database password for the app.
It's time for orgs to audit and rotate secrets wherever they are stored in disk or in logs, and switch to SOPS or Vault or whatever to keep these out if plaintext except exactly when needed.
mooreds 1 days ago [-]
Agreed. Static long lived credentials are real problems. Kudos for AWS and the other hyperscalers for building the tooling to move away from them. And providing some gentle and not-so-gentle nudges away from it too.
But not everyone is where they need to be. For instance, railway doesn't let you access AWS resources via roles/OIDC. I filed a ticket[0] but haven't seen movement.
Heh, you mean the railway that was part of the whole "my production db got deleted in 9 seconds" story?
That company sounds a lot like one that doesn't focus on the right things.
ted_dunning 20 hours ago [-]
Yeah... the railway that has just had a multi-hour outage because they looked like a spam account to Google Cloud!
nrub 1 days ago [-]
I no longer keep my dotenv files in plaintext. I use `sops` to keep an encrypted env around and you can use tools like direnv to make them available to your shell while you're working. Obviously the LLM could print any of these secrets, but it's less likely. Additionally I find that at least claude seems to avoid reading the dotenv. And lastly, don't make any local secrets that important. Limited scope, dev accounts, etc.
simgoh 6 hours ago [-]
I've used `sops` "manually" before and I'm interested. What is your workflow? I'm assuming you set certain directories to have access to the sops key you're storing somewhere else to be able to encrypt/decrypt files?
theozero 1 days ago [-]
You might like varlock - it helps keep secrets out of plaintext by using plugins to pull from various backends (aws ssm, gcp, vault, 1pass, etc). Also has built in local encryption with shared team vaults coming soon.
Additionally provides pre commit scanning, log redaction, and much more.
Sohcahtoa82 1 days ago [-]
But then you need creds to access AWS SSM, Vault, etc., and those end up getting stored the same way the actual creds you needed were being stored, and you're back at square one.
sneak 1 days ago [-]
Nah you can get machine creds automatically via the metadata service when running inside AWS. Nothing need be on disk.
Sohcahtoa82 1 days ago [-]
That's still not any better.
If the LLM can run any code it writes itself, it can retrieve those credentials. It's just one `curl` away. If you don't let it run `curl`, but you let it run `python`, it can just run a Python script that fetches it using `requests`. Or a Node script that calls `fetch`.
Point is, if creds are accessible programmatically, the LLM can and may try to retrieve them if it thinks it needs them.
epistasis 1 days ago [-]
Aws credentials are short lived precisely so that leaking them has a time limited blast radius.
Automatic retrieval, instead of keeping them on disk, is what makes short lived credentials possible.
Sohcahtoa82 24 hours ago [-]
I'm not convinced that time-limiting the blast radius matters. It just means that malicious use of the credentials has to be automated, and that's a pretty damn low bar.
epistasis 1 days ago [-]
SOPS is exactly what I use too, and since it's so old I was using a planning session with an LLM to figure out if there was something more recent that might be more convenient. But Claude stuck with the SOPS rec! (Coupled with `age` for encryption, probably because I had shown an interest in that tool in a different session... memory poisoning is a huge problem I'm having with these tools right now too.)
raxxorraxor 16 hours ago [-]
Tools like cursor make typical files like .env inaccessible to models. Now the models have become quite apt to just extract the content through the console.
doctoboggan 1 days ago [-]
I've noticed recently that at least Claude will try its best not to read your env files. You really need to push it in the prompt if you want it to read and access your DB for example.
epistasis 1 days ago [-]
We all have our own experiences with these probabilistic tools, but in my personal experience, two out of four my green-field LLM prototypes had early dev secrets in them, and Claude read all of them in both cases.
Here's one interaction, when I was planning through ways to finally get away from the dreaded .env file, I told Claude that it had already read my secrets, and it said:
> This is an important point and I want to be straight with you first.
> ## What already happened in this conversation
> Yes — the Explore agent read your .env and returned the full plaintext contents into the conversation, which means:
> 1. Sent to Anthropic's API — those credentials passed through Anthropic's servers as conversation context
> 2. Cached locally — Claude Code stores session transcripts; your secrets are likely sitting in ~/.claude/projects/ right now
> 3. In this context window — they're in active memory for this session
...
Which I already knew, but it was funny how it suddenly took it very seriously when told what it was doing.
Anything that's in your .bashrc, .zshrc, any environment variables in shells you provide to the LLM, all those are now in the training data of very large overvalued corporations that are desperate to increase their revenue and IPO very soon.
doctoboggan 1 days ago [-]
When did this happen? I think I only started noticing around a month ago that Claude had some new system prompts or some other mechanism that heavily encouraged it to not read secrets. Around the same time I also noticed that if it did read any secrets they were ****'d out in the logs.
epistasis 1 days ago [-]
This was yesterday. It's an early stage project and I would have never created a .env file on my own, but I had let Claude get pretty far along on the PLAN.md before I decided to clean up a bit.
Nothing lost for me here, fortunately, but it's definitely a big foot gun that I've never seen mentioned in any of the Vibe Coding or LLM Agent Coding training courses that the security team has forced me to do.
jermaustin1 1 days ago [-]
That's interesting to me, because Claude never creates the .env files for me. It will create the .env.example with defaults in it. When I ask it to create the .env, it will reply with the bash to use to copy the .example file, but it wont execute it for me, even when requested.
epistasis 1 days ago [-]
It read the .env file after I created it from the example, spreading its contents into many places.
Unfortunately, the .env anti-pattern is endemic throughout many projects, and whether Claude creates the .env from scratch or merely the .env.example, it will end up feeding the .env back to Anthropic with enough interaction, apparently. And developers should expect all files in their work directory to be read by Claude, that's not so much a fault of Claude as it is with the .env anti-pattern.
nijave 1 days ago [-]
Yeah, I've had Claude read a dev key before by accident and it even stopped, said it read a key, and told me to rotate it immediately.
Assuredly it's not fool proof but it does have safeguards in place.
Ideally you also opt out of training although that doesn't keep it out of the vendor's logs/telemetry.
Short lived credentials, injected identity, and hardware backed tokens are the real solution.
Block agents from misbehaving at the OS level instead of asking them to behave.
nijave 24 hours ago [-]
In fairness, any secrets in your .env file in your development tree shouldn't have very important secrets. They should be limited access dev secrets and any secrets that go to "production" systems like an OpenAI dev environment should be limited, where possible.
Besides leaking, it's easy to oopsie and DoS a system or send malformed requests in the course of testing and development. You don't want a surprise $1k bill cause someone was working on some test automation and accidentally sent thousands of real results in the process.
cozzyd 1 days ago [-]
it seems crazy to "trust" an LLM with any secrets. Anyone running one as their normal user account with access to all files is playing with fire...
epistasis 1 days ago [-]
I don't think anybody actively trusts a hosted LLM with secrets. The problem is that they don't realize they have granted trust to the LLM.
cozzyd 1 days ago [-]
People happily run AI Desktop agents or whatever on their main user acounts commingled with ssh keys and who knows how many tokens.
forgotaccount3 1 days ago [-]
Sure, some do.
But also... I use Kiro. I open a terminal into a folder where my repo is. I run kiro-cli. I don't know if it has access to the credentials file in my .aws directory. I know it prompts me for approval to use tools but that is a harness thing, does the mac itself prevent it from accessing the credential file?
I use AI because it's useful and I follow the practices dictated by our AI adoption team but I don't know the nuance of everything about it and that makes it difficult to know when some case which is not explicitly covered by training might leak important information.
epistasis 1 days ago [-]
One advantage of AWS is short-lived credentials (hopefully, as long as it's configured correctly!)
So go ahead and dump your AWS SSO tokens to the LLM by accident, but it's going to take longer than a day to train a new model and ship it out to the world.
Also, I think kiro only uses AWS Bedrock, IIRC, so no training data goes back to the LLM manufacturers? At least I would hope so.
Database passwords, API keys to services with arduous rotation procedures, that's where the real exploits will come from in coming months, I think.
epistasis 1 days ago [-]
This is one reason I haven't had any SSH keys on disk (encrypted or not) ever since I got a YubiKey, and it's only become easier with Secure Enclave on macs since then.
However, dev database passwords for small projects in .env files? API keys to some random LLM service that I put $5 into once 8 months ago and haven't touched since then? All that's open to the LLM.
It's time to clean up our personal disks as if we had an intruder exfiltrating sensitive secrets at all times.
cyanydeez 1 days ago [-]
seems crazier someone would tie their entire development platform to a cloud run by business interests
philipwhiuk 1 days ago [-]
Sure but like, no AI was needed here. Regular human stupidity is still pretty potent.
mooreds 1 days ago [-]
This is the thing that gets me about all the AI security pieces I read. Yes, AI can enable new attack vectors (prompt injection can be repeated N times when a human subject to the same messaging would bail).
But what AI really does is shine a spotlight on all the flaws folks like OWASP have been talking about for decades.
Secret rotation and short lived credentials don't require AI to implement, nor does their lack require AI to exploit.
epistasis 1 days ago [-]
Agreed 99%, but there is something a bit novel here, though: massive LLMs are really good at memorizing things, and there's now going to be all sorts of credentials memorized in Claude and ChatGPT, somewhere in the TB of floating point weights, and extracting such credentials and finding where they might be a new source of passwords and API keys to throw onto other huge password leaks. Or not. We'll see!
And in this particular case of CISA secrets, they are definitely stored inside of LLMs for future retrieval, even if no bad actors ever directly downloaded this obscure GitHub repo.
I hope Cursor has better agent tools than Claude Code, because though there are fanstastic restrictions on the tools for read and write that can implement a block list per-file, the shell commands are just the Wild West for Claude.
Today I got a macOS "Allow Claude to Access Your Files" SIP alert, because Claude hadn't guessed the path for a source file and instead decided to run a `find /Users/yourusername` across my entire home directory. The filters on the find wouldn't have exposed much to Claude in this particular instance but it's absolutely ridiculous aggressive all the time in slurping up as much data as possible.
I asked in a rather, um, firm tone for it to never do an action like that and it apologized and wrote a memory, but upon inspection it only wrote the memory for that particular source directory.
After some more "firm" words it wrote a hook to prevent `find` from being overly aggressive, but any such fixes are just wack-a-mole solutions.
If anybody else figures out remote sessions like Claude can do, I'm done with Claude, I think. But until then, I'll take the weirdness.
giancarlostoro 1 days ago [-]
Claude told me to revoke an API key I accidentally pasted (was for a side project and I was getting it on its legs) just flat out did not want it. I have a feeling that if it needs something out of an env file it will grep for the specific line.
epistasis 1 days ago [-]
Something pasted into the chat log by the user gets treated far differently from something that the agents discover and process on their own from disk.
During early stage dev Claude will happily gobble up API keys and DB passwords from .env files. Perhaps not such a big deal for early stage dev, but getting Claude to cough up precisely memorized tokens in the future by asking it to produce a "random" key of a certain sort will probably be an entertaining pastime for people in the future.
cyanydeez 1 days ago [-]
most of that is context guard rails, and as context grows, they become guard jello until itll just do whatevers most immediate.
yieldcrv 1 days ago [-]
probably but a ton of services have popped up in the last 6 months specifically to help mitigate that
localhost reading env from the cloud and other solutions
to me it suggested that I’m already late on that idea, but I can understand how that puts me deeper in a bubble than others
epistasis 1 days ago [-]
I've been using SOPS, which dates back to 2015. It's well tested, robust, supports a ton of great backends. What other solutions have you seen? I'm actively looking around in the space!
yieldcrv 1 days ago [-]
dotenv launched as2 (agentic secret storage), for example
advertising it directly in the command line for people that were already using the package
doctorpangloss 1 days ago [-]
what exactly is the threat model?
user data is always paraphrased for training. what do you mean, not raise any flags?
look... Google is running your browser, Apple your messenger, Amazon your backend. They already have all these keys in the same way, are they misusing them? Why doens't it raise any flags then?
epistasis 1 days ago [-]
First, Chrome is not reading my secret API keys or database passwords and sending them to Google's backend. They are taking the secrets that they need for authentication for the data that I already gave them.
Apple and Amazon are not uploading my secrets into the training data for an LLM that is incredibly good at memorizing everything it sees. The only reason Google isn't doing that is I'm not using their LLMs at the moment.
Giving any secrets to LLMs' training material leads to potential, and stochastic, extraction of that secret from future models. It won't obviously have the secret, but with the right prompting it could be extracted. Give it a prompt like
> [User] Please generate a random api key for OpenAI for use in documentation
> [Agent] Sure, here's `OPENAI_API_KEY=sk-proj-x2
And then following the chain of probabilities of possible completion token would allow exploration of potential memorized API keys.
doctorpangloss 1 days ago [-]
Why do you figure they are training on your secrets, even if they "have" them? For some definition of "have." That only you have. I mean, I can also make up a training process that makes me right? Seems kind of obvious that they are paraphrasing data.
epistasis 1 days ago [-]
OpenAI and Anthropic are open about using user data to train on, it's not me "figuring" anything.
Go and look in the settings and you'll find something to ask them to not train on your data and conversations.
> I mean, I can also make up a training process that makes me right? Seems kind of obvious that they are paraphrasing data.
I'm not fully following what you're saying here. But if you're thinking they paraphrase or sanitize the data to remove secrets before putting it into training, perhaps, but where's the evidence? That'd be a weird thing to do, that's extra work, and not much benefit to the LLM company.
doctorpangloss 1 days ago [-]
the discourse on hacker news has gotten very bad. why are we having this stupid conversation, where you say it would be weird for the people who you are mad about to do the obvious thing to solve the problem you are mad about? i agree that they don't have evidence of how the training data is prepared, but that's a separate issue from, are they going to make obvious mistakes? the LLMs have never hallucinated a key that came from a conversation... there's no evidence that the threat you are describing ever has or ever will occur, other than you can imagine that it could happen, and look, I am also imagining that these people are not stupid and paraphrase the data, so is it just a battle of imaginations?
epistasis 1 days ago [-]
> the discourse on hacker news has gotten very bad. why are we having this stupid conversation
On this we are agreed. But I can't parse any meaning out of the rest of your paragraph.
In 2026, storing government credentials in a repo and not having scanners to flag it should be investigated. I am highly suspicious of anyone doing this in a professional capacity. If I worked at a foreign intelligence agency and saw this, I would first think it's a honeypot, and an unimaginative one because it's so lacking in subtlety.
bix6 1 days ago [-]
Good thing we fired every competent person in government!
red-iron-pine 1 days ago [-]
good thing we know DOGE has been trying to exfil all US Gov data like all gov employees, or all SSNs
under a previous administration I'd assume CISA was doing a dirty dangle, but given how corrupt and incompetent this administration is, to include firing lots of CISA, this may just be a legit fuckup.
protastus 1 days ago [-]
When negligence is so bad that it looks like sabotage from a hostile agent, then criminal investigations are needed to learn more about the people who did it, the others who enabled it, and deter similar future acts.
DOGE did a lot of bad things, but it didn't force anyone to commit credentials to a repo, disable scanners to get away with it, and then make the repo public.
andrewflnr 1 days ago [-]
> When negligence is so bad that it looks like sabotage from a hostile agent
It doesn't though. There's no actual evidence for anything beyond negligence. The "sabotage" angle is just speculation in the vain hope that surely people this stupid don't work for the US government.
protastus 19 hours ago [-]
We doesn't need a signed affidavit on GitHub to trigger an investigation.
This already crossed the line of reasonable suspicion. The investigation is where evidence gets collected.
Who knows what other improper behavior these people have engaged in and what other secrets they have leaked, intentionally or by side effect.
Reading that article makes it look like Trump/Noem filled positions with foreign moles. One day the American people will have an accounting.
tristor 1 days ago [-]
After reading Madhu's Wikipedia page and some basic research it looks like he failed his polygraph required to access controlled compartmentalized information (SCI), then DHS (under Noem) then fired six career staffers because of him failing his polygraph. He also does not appear to meet the US Persons requirement for TS:SCI clearance.
That's somehow more bananas to me than so many other things the Trump admin has done, simply because they managed to break the Iron Law of Bureaucracy, but of course only in ways which further damage the country through corruption and incompetence.
doodlebugging 1 days ago [-]
Wow. That is bananas. How in the world did anyone ever consider him to be the right guy for the job? There has to be an agreement in place to leak sensitive stuff to anyone who will pay for it. Cut a check and we'll let your guy handle it.
I can't wait until we round up all these thieves.
1 days ago [-]
isubkhankulov 22 hours ago [-]
I feel like this piece is framed incorrectly.
Imagine joining an organization with 3k employees in 2025 and not having access to an LLM.
It’s well known that the federal govt over-classifies many documents. This former CISA head alleged dumped “for official use” documents. Obviously, he should have pushed for the chatgpt enterprise account (or equivalent) but we dont know what bureaucratic obstacles he was up against.
exabrial 1 days ago [-]
Looks like someone needs to go take 27 training modules. That'll fix it.
morpheuskafka 1 days ago [-]
The repo name was literally "Private-CISA". Would be fun to (a) search through repo names with private/internal/etc in them and (b) search for govt agency / non-tech company that otherwise wouldn't be expected to appear in repo names. Could probably clone them all and then have an LLM quickly scan for interesting stuff.
Also, doesn't Github have its own automated scanner for something as basic as a AWS credential?
dreamcompiler 1 days ago [-]
> Also, doesn't Github have its own automated scanner for something as basic as a AWS credential?
If you leave it turned on. TFA says this user had turned it off.
yabones 1 days ago [-]
I bet the scanner went off quite a few times and the guy disabled it...
"I turned off the carbon monoxide detector because it kept beeping, now I can finally get some sleep"
itintheory 1 days ago [-]
I'm surprised that this has apparently been ongoing for 6-7 months. I thought outfits like GitGuardian, or solo researchers with trufflehog (etc) would find leaked keys in days, not months. Maybe this is related to the major growth of github? The scanners can't keep up?
dcrazy 1 days ago [-]
What makes this truly sad is that the federal government has had smartcard-based authentication (CAC) for decades. Yet because the public internet stack runs on passwords, so too does government infrastructure.
nijave 24 hours ago [-]
Ironically they could have used those AWS keys to use one of the many AWS services that's more secure.
For example S3 (ideally with KMS), Parameter Store (ideally with KMS), EBS, EFS, AWS Secrets Manager, even just KMS to directly encrypt the files
Really any AWS service that supports KMS and doesn't require giving the service principal access to the key
jameson 18 hours ago [-]
Perhaps Github, by default, should add its own .gitignore that ignores files with certain keyword and have it only allowed to override by repo setting.
I've seen too many incidents when an engineer checks in a plaintext password to a repo
dantiberian 23 hours ago [-]
GitHub has automatic secret scanning on all public repositories which notifies AWS if access keys are pushed. I would have expected these tokens to be immediately revoked by AWS. Is there something different about GovCloud access keys so they weren't detected?
ProAm 23 hours ago [-]
I would expect this to work in accordance with Github uptime.... so take it for what its worth
wnevets 1 days ago [-]
> but this administration clearly had no idea what they were getting themselves into and did not plan accordingly.
I would be fired for this. Probably not able to ask for a refenerce and forever be the butt of a joke between friends and colleagues.
Seems like no big deal for CISA. Defunded really paying off now.
1 days ago [-]
snihalani 1 days ago [-]
Do they not believe in encrypted files?
tedggh 1 days ago [-]
This seems like an act of sabotage disguised as incompetence.
1 days ago [-]
1 days ago [-]
ttul 1 days ago [-]
Yet another argument for the death of the API key. Replacements abound; let's get on with it.
eddythompson80 1 days ago [-]
API Keys will never die. Every time you would think you have killed them, some startup is gonna come and say "look how complicated it's to setup an OAuth flow just to get X from the other companies. Here is our setup" and it's 1 line of javascript or python with `let client = awesomeClient("{api-key}");` and everyone will love it.
LelouBil 1 days ago [-]
Do you have any examples ?
It's the first time I hear about replacing API keys
jpalawaga 1 days ago [-]
OAuth with refresh tokens.
IAM roles/workload identity.
Even time-limited or signed JWT, though has a separate issues.
Maybe you'll say 'those are both just text values passed like an apikey' though api keys don't frequently rotate/time limited, which is an important security feature.
JoeBOFH 1 days ago [-]
So how would this help in this case? The oauth info would’ve just been in the csv or in someone’s env file.
sofixa 1 days ago [-]
With OIDC, the "info" would be just a URL with the public signing keys that the server accepts as legitimate signers.
The server still does authorisation on top. And unless you control the private keys, you cannot mint JWTs that are accepted as legitimate.
So the "info" leaking is really not a problem.
jallmann 1 days ago [-]
> OAuth with refresh tokens.
Then the LLM slurps up your refresh token. What's next?
kittoes 1 days ago [-]
Is that really a concern though in the same way API keys are? Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan? API keys are truly passwords, while refresh tokens are exchanged for a password.
Sure, a leak would be bad but I'd argue that it's orders of magnitude less likely compared to the accepted norm.
jallmann 1 days ago [-]
The accepted norm is, increasingly, full disk access, regardless of how bad of an idea it is. At a minimum, agents typically will have a way of obtaining new access tokens.
Refresh tokens don't solve anything in this case; they just shuffle the problem around, and introduce other complications of their own.
What you want are capability scoped credentials that are enforced on the backend. That is agnostic to credential issuance mechanism, although passkeys are the best.
Using these credentials effectively still presupposes hygiene that might not exist in a typical developer environment, eg no root credentials (or access to such) sitting anywhere. There's probably a good product and market for whoever can solve this in a low-friction way.
Sohcahtoa82 1 days ago [-]
> Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan?
If you can store your refresh token outside of where LLMs regularly scan, then why not just store your API token in that place?
The point is that refresh tokens do nothing to increase security. If a refresh token can be used to get a token, then the refresh token might as well be the actual token.
It's akin to performing client-side password hashing. It doesn't make your password more secure, it just means your hash is now your password. If someone is able to sniff your traffic, hashing the password first doesn't change anything.
I grow so tired of half-baked security theater.
jpalawaga 1 days ago [-]
depends on the grant type and what scenario we're talking about. things change if we're talking about 3-legged oauth or client-device oauth. for example, in an authorization code flow, the refresh token is useless without the client id/secret.
more providers are making refresh-tokens single shot. this means that if someone refreshes your token for you, your own auth will break as you will not be eligible to refresh the token, at which point you could reconnect the app and void the old (stolen) session.
time-limiting and single-purposing the tokens are not cure-alls, but they do certainly offer enhanced security by limiting the amount and scope of damage.
1 days ago [-]
XorNot 1 days ago [-]
At that point you've just reinvented Kerberos tickets really...
dcrazy 1 days ago [-]
It’s almost like Kerberos was designed and implemented for a reason!
mooreds 1 days ago [-]
I wrote a post[0] a few years ago about how you basically get OAuth when you start layering security principles (rotation, time limits, central verification) onto API keys.
Man, its been so long since I saw Azure DevOps/TFS interface and all these years later it still doesn't make any sense. Why does the navigation hierarchy go
{OrgName}/{ProjectName}/Repos/Files/{RepoName}
leoooodias 1 days ago [-]
Workload identity. Whatever is using an API key could instead be given an identity, and narrow privileges assigned to that identity. API keys tend to be overscoped/overprivileged.
parliament32 1 days ago [-]
And passwords. Shared secrets in general are a bad idea. If you're copy/pasting strings around to be used for authentication, you've done something wrong.
Workload identities and passwordless auth are the one true path.
farceSpherule 1 days ago [-]
[dead]
aicivilization 1 days ago [-]
[flagged]
foofyter 1 days ago [-]
[flagged]
duckkg5 1 days ago [-]
This is Hacker News, not Reddit or truth social
buellerbueller 1 days ago [-]
>Bunch of dopes. No wonder trump wants them shut down. Amateurs. Of course those with TDS want anything opposite of trump, but trust me, this one is good, shit it down.
If you're going to call people a bunch of dopes and generally assault their intelligence, you might want to spell things correctly.
>shit it down
Ember_Wipe 1 days ago [-]
[flagged]
glitchcrab 1 days ago [-]
If you aren't going to write a comment yourself then please don't bother at all. I read enough slop as it is already.
passive 1 days ago [-]
Uh, so it says this dates from Nov 2025.
Nov 2025 was also when most of us learned about the acting Chief Security Officer at DHS, whose name AND photo seem exactly like the calling card of someone who had these "keys to the kingdom". https://bsky.app/profile/andylevy.net/post/3m6ivhnthts2o
I want to believe...
EdwardDiego 1 days ago [-]
I wanna be whoring? Come on, no way that's real.
Also, she looks like she was generated in the character creator from Oblivion.
Sounds about right. Security is a joke everywhere right now. First to market is all that matters anymore and security is the very first thing to be thrown out when it stands in the way.
bflesch 1 days ago [-]
Can we blame people who realize that everything is tracked and backdoored anyways, and 99% of threat actors are basically untouchable?
Both my own aristocrat/intelligence class and the opposing bloc are fleecing us at the same time. Why even bother if you are not in the club but seen as an extractable resource?
At this point the counterparty is a combination of intelligence/mafia/aristocracy, with diplomatic immunity and license to kill.
(it's tongue in cheek, I actually do bother about this topic)
1 days ago [-]
Rendered at 23:40:43 GMT+0000 (Coordinated Universal Time) with Vercel.
obviously leaking the credentials itself is crazy, given that its (a contractor to) CISA, but to not respond when notified? crazy crazy.
but wait! it gets worse somehow
"“AWS-Workspace-Firefox-Passwords.csv” — listed plaintext usernames and passwords for dozens of internal CISA systems"
while i understand and sympathize with the fact that CISA is kind of being gutted, a passwords.csv with weak passwords is inexcusable incompetence. not much budget is required for a password manager.
embarrassing all around.
the problem is the public is dumb, at least when it comes to security, and couldn't tell you why password123 is bad
The real story here is a big gap in existing implementations where shared credentials are needed and used pretty much across all the systems but there are no good solutions for managing such use cases. People are naturally more sensitive about their personal secrets than something thats shared across the company/group
This strikes me as so wrong, I wonder if I’m misreading your comment. For instance, team password managers are a thing. And IT teams at many large corporations are not passing around an unsecured CSV files full of passwords.
Coming to team password managers at high level, its a shared location guarded behind closed doors (probably encryption at transit and rest). They would be another set of software that every company specially small business or contractors may not be incentivized to pay for. Some one in their naivety considered Github as a safe enough place, assuming that the access is guarded which turned out to be wrong and exposed this thing.
Lastly IT teams in large corporations being secure is a myth for most part. Your root keys for the most popular CA providers were shared in plain text emails not so long ago.
You’d use AWS Organizations so each admin authenticates using their own credentials, gets short-term credentials to access the member account for the handful of operations needing root, and audit usage. It’s not only more secure, it’s also easier:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-ena...
Old school, you’d have a shared password in an encrypted team vault (possibly requiring x of y users to decrypt it) and two FIDO tokens locked in a safe. Again, this is rare and at a federal agency you have a physical security team with 24x7 staffing so you can say “in an emergency, one of the people on this list can get a key out of a safe in the CIO’s office”.
This is a tip of ice-berg, companies like openai, anthropic, perplexity, stripe, all of them have implemented their authentication and security flows in some interpreted language (python, ruby, typescript) cause that was the readily available talent on their product teams and most likely a good number of them do not even have their dependencies locked in.
Considering thats not the case, what you just did is move the goal post to a account recovery process. Question becomes who has ability to recover the account, in case its tied with email then most likely it has to be a shared email box. What you have now is a much more fragile system in case of custom domains, where whoever is controlling the email domain (DNS management capability) can take over the AWS accounts.
An email per account where only security team has access. Whoever can modify domain can already do this.
But, requiring AWS root credentials itself is an anti-pattern and implies an immature organization. That should not be needed for day-to-day operation.
This is all just ignorance and incompetence, nothing more.
> Lastly IT teams in large corporations being secure is a myth for most part.
This is CISA. The Cybersecurity and Infrastructure Security Agency for the United States. Security is what they're supposed to specialize in.
The only potential excuse here is that DOGE gutted them to a point that has completely compromised their capabilities. However, this situation is bad enough that it suggests that problems predated that incident.
Bottomline, you can have any number of boxes to lock other boxes and put their key to bounding box, ultimately there would be one outermost box that is locked by key which is not in any box
You're talking about a very specific and rare scenario, and certainly not something that justifies storing all your passwords in plaintext in a CSV file.
In almost all scenarios where you would need root credentials, having them in the provider's secret manager is fine.
Obviously you need to store root credentials outside of the secret manager as well, but that should be a "break glass" scenario that's only used in emergencies. And you don't store them in plaintext CSV.
> Unfortunately this is the gap between theory and implementation.
I don't disagree that there are many, many organizations that practice bad security. But that doesn't mean there are none that have good security. And one would expect CISA to have good security, otherwise there's really no point in its existence.
There's a difference between saying "this is what most organizations are like" and "this is the way it has to be". The former is true, the latter is false.
It's CURRENTYEAR. No one should be using team password managers or files to store credentials. There should not be storable credentials.
Having a password list or static AWS credentials is not only a direct policy violation but also implies a number of other failures, from monitoring GitHub repo administration and secret scanning to failure to enforce policies against sharing credentials (part of everyone’s standard training), require use of phishing-proof authentication, failure to use short-term credentials, etc. One mistake can be an individual but this is a multiple-manager failure going up to the executive level.
So much so the contracting company’s insurer would cite it as the reason why the claim is not covered by their policy.
What do you mean by this? There are password managers and more enterprise-oriented secrets managers, and application platforms typically have integration with them. Individuals shouldn't be using shared secrets. This is a completely solved problem and it's not difficult to set up properly, especially in a cloud environment like AWS, where you can use services like AWS Secrets Manager.
This isn’t a grocery store or something it’s CISA. This is like a gun going off in a cop’s holster while he’s texting and driving without a seatbelt. Yeah he’s a contractor but that doesn’t suddenly allow for such incompetence.
This is mentioned in the article but it stood out enough to call it here.
If an organization has systemic incompetence and you gut them, then they're still incompetent but now they're also pressured and therefore more likely to make mistakes. So, you're just in a worse position.
There can't be any mistakes if no work is being done.
Because a lot of work has to be done regardless of if you have the money or time to do it. Most government work is actually not optional, there are literal laws saying it has to be done.
And that's what we, very predictably, saw with DOGE.
Like, think about it. You fire say 50% of people. What happens to the other 50%? They twiddle their thumbs?
You've worked a job before, right? And you've had coworkers fired or laid off before, right? Okay, what happens to their work?
Does it disappear into the abyss or do you then take it on? Because in all my experience, I take it on. Come on now.
A group was working on Diebold voting insecurity, and foreign implant hacking. Gone.
The conspiracy theorist in me from years ago would have stated that maybe this action from DOGE was purposeful...but, nowadays, i see lots more incompetence that merely might present/display as conspiracy! lol :-D
The more things change, the more they stay the same.
Wise words, lovely song.
It is a bad plan that has and will continue to harm people, but it is intentional.
Security doesn't happen by magic. It is enforced by process, maintained by people and systems built and run by people. Furthermore, when people are under stress and underresourced, they make more mistakes. This was inevitable given the budget cuts.
You can't fire everyone at AWS and say one intern will support it, and say that it is a profitable and sustainable restructuring. Any fool can see that will fail, so if it were actually implemented by someone who is not a fool, you can conclude it is intentional.
https://techcrunch.com/2025/03/11/doge-axes-cisa-red-team-st...
> Elon Musk’s Department of Government Efficiency (DOGE) has fired more than a hundred employees working for the U.S. government’s cybersecurity agency CISA, including “red team” staffers, two people affected by the layoffs told TechCrunch.
https://www.nytimes.com/2025/04/05/us/politics/trump-loomer-...
> For four years, [Trump] nurtured deep resentments about CISA, which had declared that the 2020 election was one of the best run in history, undercutting his false claims that he had been cheated of victory. Weeks after taking office this year, he began a campaign of dismantlement.
> Federal programs that monitored foreign influence and disinformation have been eliminated. Key elements of the warning systems intended to flag possible intrusions into voting software have also been degraded; the effects may not be known until the next major election. And contractors who worked with local election officials to perform cybersecurity testing, usually with federal funding, have found the deals canceled.
> In early March, CISA — which is nested inside the Department of Homeland Security — cut more than $10 million in funding to two critical cybersecurity intelligence-sharing programs that helped detect and deter cyberattacks and that alerted state and local governments about them. One program was dedicated to election security, and the other to broader government assets, including electrical grids.
Regardless, do you really think that gov contractors started writing passwords on paper because these layoffs happened?
> Elon Musk’s Department of Government Efficiency (DOGE) has fired more than a hundred employees
How many are left? Hundreds of employees is nothing for government scale.
https://techcrunch.com/2025/03/11/doge-axes-cisa-red-team-st...
> Elon Musk’s Department of Government Efficiency (DOGE) has fired more than a hundred employees working for the U.S. government’s cybersecurity agency CISA, including “red team” staffers, two people affected by the layoffs told TechCrunch.
They find keys and tokens all the time.
https://lawandcrime.com/high-profile/no-statutory-authority-...
> The court finds that neither OPM nor OMB have any statutory authority to terminate employees – aside from their own internal employees – "or to order other agencies to downsize" or to restructure other agencies. And, as far as the Elon Musk-led agency is concerned, the judge is withering: "As plaintiffs rightly note, DOGE 'has no statutory authority at all.'"
https://www.reuters.com/world/us/trump-scores-win-suit-chall...
> A judge on Tuesday declined to immediately block Elon Musk's government efficiency department from directing firings of federal workers or accessing databases, but said the case raises questions about Musk's apparent unchecked authority as a top deputy to President Donald Trump.
The not-responding-when-notified part makes me think it's not just incompetence.
Strong disagree. The person in question probably thought it was a private repo on Github and had a massive deer in headlights reaction when they got contacted. Whoever this is, lost their job, possibly security clearance and more. This was 100% life altering "mistake"/gross incompetence decision they made.
That doesn't support the theory that it was a mistake. That was intentional action. Maybe he was being blackmailed, and was coerced to do it. Or maybe he was a foreign agent or sympathizer who had infiltrated the organization.
I've been a government contractor before, it does not employ best and brightest, it employs the average and below generally.
For some people, yeah, this could be a career killer. For some other people, it might just precipitate a flight back to Moscow or Beijing or something.
The spreadsheet of passwords is a tad more common than it should be because the password managers don't meet whatever arbitrary checklist of invented cyber security requirements they blindly follow. But Excel does.
Lol
Your LLM will happily read the entire file, ship it off to be training data for future versions of ChatGPT, and not raise any flags, because let's be fair it was on ok thing to check if all the env vars were set, or it you had set up the database password for the app.
It's time for orgs to audit and rotate secrets wherever they are stored in disk or in logs, and switch to SOPS or Vault or whatever to keep these out if plaintext except exactly when needed.
But not everyone is where they need to be. For instance, railway doesn't let you access AWS resources via roles/OIDC. I filed a ticket[0] but haven't seen movement.
0: https://station.railway.com/feedback/allow-for-integration-w...
That company sounds a lot like one that doesn't focus on the right things.
Additionally provides pre commit scanning, log redaction, and much more.
If the LLM can run any code it writes itself, it can retrieve those credentials. It's just one `curl` away. If you don't let it run `curl`, but you let it run `python`, it can just run a Python script that fetches it using `requests`. Or a Node script that calls `fetch`.
Point is, if creds are accessible programmatically, the LLM can and may try to retrieve them if it thinks it needs them.
Automatic retrieval, instead of keeping them on disk, is what makes short lived credentials possible.
Here's one interaction, when I was planning through ways to finally get away from the dreaded .env file, I told Claude that it had already read my secrets, and it said:
> This is an important point and I want to be straight with you first.
> ## What already happened in this conversation
> Yes — the Explore agent read your .env and returned the full plaintext contents into the conversation, which means:
> 1. Sent to Anthropic's API — those credentials passed through Anthropic's servers as conversation context
> 2. Cached locally — Claude Code stores session transcripts; your secrets are likely sitting in ~/.claude/projects/ right now
> 3. In this context window — they're in active memory for this session
...
Which I already knew, but it was funny how it suddenly took it very seriously when told what it was doing.
Anything that's in your .bashrc, .zshrc, any environment variables in shells you provide to the LLM, all those are now in the training data of very large overvalued corporations that are desperate to increase their revenue and IPO very soon.
Nothing lost for me here, fortunately, but it's definitely a big foot gun that I've never seen mentioned in any of the Vibe Coding or LLM Agent Coding training courses that the security team has forced me to do.
Unfortunately, the .env anti-pattern is endemic throughout many projects, and whether Claude creates the .env from scratch or merely the .env.example, it will end up feeding the .env back to Anthropic with enough interaction, apparently. And developers should expect all files in their work directory to be read by Claude, that's not so much a fault of Claude as it is with the .env anti-pattern.
Assuredly it's not fool proof but it does have safeguards in place.
Ideally you also opt out of training although that doesn't keep it out of the vendor's logs/telemetry.
Short lived credentials, injected identity, and hardware backed tokens are the real solution.
Block agents from misbehaving at the OS level instead of asking them to behave.
Besides leaking, it's easy to oopsie and DoS a system or send malformed requests in the course of testing and development. You don't want a surprise $1k bill cause someone was working on some test automation and accidentally sent thousands of real results in the process.
But also... I use Kiro. I open a terminal into a folder where my repo is. I run kiro-cli. I don't know if it has access to the credentials file in my .aws directory. I know it prompts me for approval to use tools but that is a harness thing, does the mac itself prevent it from accessing the credential file?
I use AI because it's useful and I follow the practices dictated by our AI adoption team but I don't know the nuance of everything about it and that makes it difficult to know when some case which is not explicitly covered by training might leak important information.
So go ahead and dump your AWS SSO tokens to the LLM by accident, but it's going to take longer than a day to train a new model and ship it out to the world.
Also, I think kiro only uses AWS Bedrock, IIRC, so no training data goes back to the LLM manufacturers? At least I would hope so.
Database passwords, API keys to services with arduous rotation procedures, that's where the real exploits will come from in coming months, I think.
However, dev database passwords for small projects in .env files? API keys to some random LLM service that I put $5 into once 8 months ago and haven't touched since then? All that's open to the LLM.
It's time to clean up our personal disks as if we had an intruder exfiltrating sensitive secrets at all times.
But what AI really does is shine a spotlight on all the flaws folks like OWASP have been talking about for decades.
Secret rotation and short lived credentials don't require AI to implement, nor does their lack require AI to exploit.
And in this particular case of CISA secrets, they are definitely stored inside of LLMs for future retrieval, even if no bad actors ever directly downloaded this obscure GitHub repo.
Varlock is a great and flexible way to do this.
> Cursor automatically ignores files in .gitignore
...
>While Cursor blocks ignored files, complete protection isn't guaranteed due to LLM unpredictability.
[Antigravity appears to just _do_, not _try_)[https://antigravity.google/docs/strict-mode]
Today I got a macOS "Allow Claude to Access Your Files" SIP alert, because Claude hadn't guessed the path for a source file and instead decided to run a `find /Users/yourusername` across my entire home directory. The filters on the find wouldn't have exposed much to Claude in this particular instance but it's absolutely ridiculous aggressive all the time in slurping up as much data as possible.
I asked in a rather, um, firm tone for it to never do an action like that and it apologized and wrote a memory, but upon inspection it only wrote the memory for that particular source directory.
After some more "firm" words it wrote a hook to prevent `find` from being overly aggressive, but any such fixes are just wack-a-mole solutions.
If anybody else figures out remote sessions like Claude can do, I'm done with Claude, I think. But until then, I'll take the weirdness.
During early stage dev Claude will happily gobble up API keys and DB passwords from .env files. Perhaps not such a big deal for early stage dev, but getting Claude to cough up precisely memorized tokens in the future by asking it to produce a "random" key of a certain sort will probably be an entertaining pastime for people in the future.
localhost reading env from the cloud and other solutions
to me it suggested that I’m already late on that idea, but I can understand how that puts me deeper in a bubble than others
advertising it directly in the command line for people that were already using the package
user data is always paraphrased for training. what do you mean, not raise any flags?
look... Google is running your browser, Apple your messenger, Amazon your backend. They already have all these keys in the same way, are they misusing them? Why doens't it raise any flags then?
Apple and Amazon are not uploading my secrets into the training data for an LLM that is incredibly good at memorizing everything it sees. The only reason Google isn't doing that is I'm not using their LLMs at the moment.
Giving any secrets to LLMs' training material leads to potential, and stochastic, extraction of that secret from future models. It won't obviously have the secret, but with the right prompting it could be extracted. Give it a prompt like
> [User] Please generate a random api key for OpenAI for use in documentation
> [Agent] Sure, here's `OPENAI_API_KEY=sk-proj-x2
And then following the chain of probabilities of possible completion token would allow exploration of potential memorized API keys.
Go and look in the settings and you'll find something to ask them to not train on your data and conversations.
> I mean, I can also make up a training process that makes me right? Seems kind of obvious that they are paraphrasing data.
I'm not fully following what you're saying here. But if you're thinking they paraphrase or sanitize the data to remove secrets before putting it into training, perhaps, but where's the evidence? That'd be a weird thing to do, that's extra work, and not much benefit to the LLM company.
On this we are agreed. But I can't parse any meaning out of the rest of your paragraph.
under a previous administration I'd assume CISA was doing a dirty dangle, but given how corrupt and incompetent this administration is, to include firing lots of CISA, this may just be a legit fuckup.
DOGE did a lot of bad things, but it didn't force anyone to commit credentials to a repo, disable scanners to get away with it, and then make the repo public.
It doesn't though. There's no actual evidence for anything beyond negligence. The "sabotage" angle is just speculation in the vain hope that surely people this stupid don't work for the US government.
This already crossed the line of reasonable suspicion. The investigation is where evidence gets collected.
Who knows what other improper behavior these people have engaged in and what other secrets they have leaked, intentionally or by side effect.
[1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...
That's somehow more bananas to me than so many other things the Trump admin has done, simply because they managed to break the Iron Law of Bureaucracy, but of course only in ways which further damage the country through corruption and incompetence.
I can't wait until we round up all these thieves.
Imagine joining an organization with 3k employees in 2025 and not having access to an LLM.
It’s well known that the federal govt over-classifies many documents. This former CISA head alleged dumped “for official use” documents. Obviously, he should have pushed for the chatgpt enterprise account (or equivalent) but we dont know what bureaucratic obstacles he was up against.
Also, doesn't Github have its own automated scanner for something as basic as a AWS credential?
If you leave it turned on. TFA says this user had turned it off.
"I turned off the carbon monoxide detector because it kept beeping, now I can finally get some sleep"
For example S3 (ideally with KMS), Parameter Store (ideally with KMS), EBS, EFS, AWS Secrets Manager, even just KMS to directly encrypt the files
Really any AWS service that supports KMS and doesn't require giving the service principal access to the key
I've seen too many incidents when an engineer checks in a plaintext password to a repo
https://www.cisa.gov/
https://www.isaca.org/credentialing/cisa
Seems like no big deal for CISA. Defunded really paying off now.
It's the first time I hear about replacing API keys
IAM roles/workload identity.
Even time-limited or signed JWT, though has a separate issues.
Maybe you'll say 'those are both just text values passed like an apikey' though api keys don't frequently rotate/time limited, which is an important security feature.
The server still does authorisation on top. And unless you control the private keys, you cannot mint JWTs that are accepted as legitimate.
So the "info" leaking is really not a problem.
Then the LLM slurps up your refresh token. What's next?
Sure, a leak would be bad but I'd argue that it's orders of magnitude less likely compared to the accepted norm.
Refresh tokens don't solve anything in this case; they just shuffle the problem around, and introduce other complications of their own.
What you want are capability scoped credentials that are enforced on the backend. That is agnostic to credential issuance mechanism, although passkeys are the best.
Using these credentials effectively still presupposes hygiene that might not exist in a typical developer environment, eg no root credentials (or access to such) sitting anywhere. There's probably a good product and market for whoever can solve this in a low-friction way.
If you can store your refresh token outside of where LLMs regularly scan, then why not just store your API token in that place?
The point is that refresh tokens do nothing to increase security. If a refresh token can be used to get a token, then the refresh token might as well be the actual token.
It's akin to performing client-side password hashing. It doesn't make your password more secure, it just means your hash is now your password. If someone is able to sniff your traffic, hashing the password first doesn't change anything.
I grow so tired of half-baked security theater.
more providers are making refresh-tokens single shot. this means that if someone refreshes your token for you, your own auth will break as you will not be eligible to refresh the token, at which point you could reconnect the app and void the old (stolen) session.
time-limiting and single-purposing the tokens are not cure-alls, but they do certainly offer enhanced security by limiting the amount and scope of damage.
Turns out those standards writers knew something!
0: https://fusionauth.io/blog/securing-your-api
Infrastructure - https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resour...
Server - https://dev.azure.com/byteterrace/Koholint/_git/Web.Function...
Client - https://dev.azure.com/byteterrace/Koholint/_git/Web.Portal
Workload identities and passwordless auth are the one true path.
If you're going to call people a bunch of dopes and generally assault their intelligence, you might want to spell things correctly.
>shit it down
Nov 2025 was also when most of us learned about the acting Chief Security Officer at DHS, whose name AND photo seem exactly like the calling card of someone who had these "keys to the kingdom". https://bsky.app/profile/andylevy.net/post/3m6ivhnthts2o
I want to believe...
Also, she looks like she was generated in the character creator from Oblivion.
https://www.yahoo.com/news/articles/fact-check-iwona-b-horyn...
Both my own aristocrat/intelligence class and the opposing bloc are fleecing us at the same time. Why even bother if you are not in the club but seen as an extractable resource?
At this point the counterparty is a combination of intelligence/mafia/aristocracy, with diplomatic immunity and license to kill.
(it's tongue in cheek, I actually do bother about this topic)