8 ms·

CISA Admin Leaked AWS GovCloud Keys on GitHub

478 points by LelouBil 5mo ago

Ember_Wipe 5mo ago
[flagged]
- glitchcrab 5mo 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.
aicivilization 5mo ago
[flagged]
deleted 5mo ago
[deleted]
epistasis 5mo 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.
- philipwhiuk 5mo ago
  Sure but like, no AI was needed here. Regular human stupidity is still pretty potent.
  - mooreds 5mo 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 5mo 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.
- mooreds 5mo 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. 0: https://station.railway.com/feedback/allow-for-integration-with-aws-using-rol-f37b8e64 https://station.railway.com/feedback/allow-for-integration-w...
  - mixologic 5mo ago
    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 5mo ago
      Yeah... the railway that has just had a multi-hour outage because they looked like a spam account to Google Cloud!
- giancarlostoro 5mo 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.
  - cyanydeez 5mo ago
    most of that is context guard rails, and as context grows, they become guard jello until itll just do whatevers most immediate.
  - epistasis 5mo 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.
- doctoboggan 5mo 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 5mo 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 5mo 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 5mo 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.
- cozzyd 5mo 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...
  - cyanydeez 5mo ago
    seems crazier someone would tie their entire development platform to a cloud run by business interests
  - epistasis 5mo 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 5mo ago
      People happily run AI Desktop agents or whatever on their main user acounts commingled with ssh keys and who knows how many tokens.
      - epistasis 5mo 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.
      - forgotaccount3 5mo 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.
- yieldcrv 5mo 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 5mo 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 5mo ago
      dotenv launched as2 (agentic secret storage), for example advertising it directly in the command line for people that were already using the package
- nrub 5mo 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.
  - epistasis 5mo 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.)
  - theozero 5mo 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 5mo 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 5mo ago
        Nah you can get machine creds automatically via the metadata service when running inside AWS. Nothing need be on disk.
        Sohcahtoa82 5mo ago
- theozero 5mo ago
  Get everything out of plaintext! Varlock is a great and flexible way to do this.
- doctorpangloss 5mo 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 5mo 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 5mo 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 5mo 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.
- j0ej0ej0e 5mo ago
  [Cursor appears to at least be trying...](https://cursor.com/docs/reference/ignore-file#why-ignore-files https://cursor.com/docs/reference/ignore-file#why-ignore-fil...) > 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 https://antigravity.google/docs/strict-mode]
  - epistasis 5mo ago
    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.
- nijave 5mo 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.
- jonnyasmar 5mo ago
  [flagged]
  - sincerely 5mo ago
    LLM spam account
- strbean 5mo ago
  Plug for my buddy's project: http://agentsh.org/ http://agentsh.org/ Block agents from misbehaving at the OS level instead of asking them to behave.
debarshri 5mo ago
They also uploaded sensitive docs in chatgpt [1] [1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumukkala-chatgpt-00749361 https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...
- doodlebugging 5mo ago
  Reading that article makes it look like Trump/Noem filled positions with foreign moles. One day the American people will have an accounting.
  - tristor 5mo 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 5mo 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.
    - deleted 5mo ago
      [deleted]
- isubkhankulov 5mo 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.
wnevets 5mo ago
> but this administration clearly had no idea what they were getting themselves into and did not plan accordingly.
ttul 5mo ago
Yet another argument for the death of the API key. Replacements abound; let's get on with it.
- LelouBil 5mo ago
  Do you have any examples ? It's the first time I hear about replacing API keys
  - leoooodias 5mo 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.
  - jpalawaga 5mo 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 5mo 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 5mo 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.
    - XorNot 5mo ago
      At that point you've just reinvented Kerberos tickets really...
john_strinlai 5mo ago
>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 5mo ago
  The word you're looking for is "gross negligence"
  - john_strinlai 5mo ago
    "crazy crazy" gets the same point across
    - binkHN 5mo ago
      Yeah, but the words gross negligence is legal for you're going to be sued for a whole lot of money.
      - sandeepkd 5mo 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 5mo ago
foofyter 5mo ago
[flagged]
- duckkg5 5mo ago
  This is Hacker News, not Reddit or truth social
- buellerbueller 5mo 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
farceSpherule 5mo ago
[dead]
exabrial 5mo ago
Looks like someone needs to go take 27 training modules. That'll fix it.
dcrazy 5mo 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.
bilekas 5mo ago
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.
snihalani 5mo ago
Do they not believe in encrypted files?
passive 5mo 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 https://bsky.app/profile/andylevy.net/post/3m6ivhnthts2o I want to believe...
- EdwardDiego 5mo 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.
  - doginasuit 5mo ago
    It is real: https://www.yahoo.com/news/articles/fact-check-iwona-b-horyn-234711922.html https://www.yahoo.com/news/articles/fact-check-iwona-b-horyn...
tedggh 5mo ago
This seems like an act of sabotage disguised as incompetence.
deleted 5mo ago
[deleted]
itintheory 5mo 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?
deleted 5mo ago
[deleted]
chrismarlow9 5mo ago
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 5mo 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)
deleted 5mo ago
[deleted]
protastus 5mo ago
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 5mo ago
  Good thing we fired every competent person in government!
- red-iron-pine 5mo 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 5mo 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 5mo 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 5mo 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.
cestith 5mo ago
It looks like CISA should employ a CISA. https://www.cisa.gov/ https://www.cisa.gov/ https://www.isaca.org/credentialing/cisa https://www.isaca.org/credentialing/cisa
morpheuskafka 5mo 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 5mo 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 5mo 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"
nijave 5mo 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
dantiberian 5mo 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 5mo ago
  I would expect this to work in accordance with Github uptime.... so take it for what its worth
deleted 5mo ago
[deleted]
jameson 5mo 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

478 points by LelouBil 5mo ago

Ember_Wipe 5mo ago

[flagged]

glitchcrab 5mo 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.

aicivilization 5mo ago

[flagged]

deleted 5mo ago

[deleted]

epistasis 5mo 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.

philipwhiuk 5mo ago
Sure but like, no AI was needed here. Regular human stupidity is still pretty potent.
- mooreds 5mo 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 5mo 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.
mooreds 5mo 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. 0: https://station.railway.com/feedback/allow-for-integration-with-aws-using-rol-f37b8e64 https://station.railway.com/feedback/allow-for-integration-w...
- mixologic 5mo ago
  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 5mo ago
    Yeah... the railway that has just had a multi-hour outage because they looked like a spam account to Google Cloud!
giancarlostoro 5mo 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.
- cyanydeez 5mo ago
  most of that is context guard rails, and as context grows, they become guard jello until itll just do whatevers most immediate.
- epistasis 5mo 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.
doctoboggan 5mo 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 5mo 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 5mo 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 5mo 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.
cozzyd 5mo 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...
- cyanydeez 5mo ago
  seems crazier someone would tie their entire development platform to a cloud run by business interests
- epistasis 5mo 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 5mo ago
    People happily run AI Desktop agents or whatever on their main user acounts commingled with ssh keys and who knows how many tokens.
    - epistasis 5mo 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.
    - forgotaccount3 5mo 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.
yieldcrv 5mo 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 5mo 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 5mo ago
    dotenv launched as2 (agentic secret storage), for example advertising it directly in the command line for people that were already using the package
nrub 5mo 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.
- epistasis 5mo 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.)
- theozero 5mo 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 5mo 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 5mo ago
      Nah you can get machine creds automatically via the metadata service when running inside AWS. Nothing need be on disk.
      - Sohcahtoa82 5mo ago
theozero 5mo ago
Get everything out of plaintext! Varlock is a great and flexible way to do this.
doctorpangloss 5mo 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 5mo 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 5mo 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 5mo 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.
j0ej0ej0e 5mo ago
[Cursor appears to at least be trying...](https://cursor.com/docs/reference/ignore-file#why-ignore-files https://cursor.com/docs/reference/ignore-file#why-ignore-fil...) > 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 https://antigravity.google/docs/strict-mode]
- epistasis 5mo ago
  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.
nijave 5mo 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.
jonnyasmar 5mo ago
[flagged]
- sincerely 5mo ago
  LLM spam account
strbean 5mo ago
Plug for my buddy's project: http://agentsh.org/ http://agentsh.org/ Block agents from misbehaving at the OS level instead of asking them to behave.

debarshri 5mo ago

They also uploaded sensitive docs in chatgpt [1] [1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumukkala-chatgpt-00749361 https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...

doodlebugging 5mo ago
Reading that article makes it look like Trump/Noem filled positions with foreign moles. One day the American people will have an accounting.
- tristor 5mo 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 5mo 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.
  - deleted 5mo ago
    [deleted]
isubkhankulov 5mo 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.

wnevets 5mo ago

> but this administration clearly had no idea what they were getting themselves into and did not plan accordingly.

ttul 5mo ago

Yet another argument for the death of the API key. Replacements abound; let's get on with it.

LelouBil 5mo ago
Do you have any examples ? It's the first time I hear about replacing API keys
- leoooodias 5mo 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.
- jpalawaga 5mo 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 5mo 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 5mo 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.
  - XorNot 5mo ago
    At that point you've just reinvented Kerberos tickets really...

john_strinlai 5mo ago

>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 5mo ago
The word you're looking for is "gross negligence"
- john_strinlai 5mo ago
  "crazy crazy" gets the same point across
  - binkHN 5mo ago
    Yeah, but the words gross negligence is legal for you're going to be sued for a whole lot of money.
    - sandeepkd 5mo 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 5mo ago

foofyter 5mo ago

[flagged]

duckkg5 5mo ago
This is Hacker News, not Reddit or truth social
buellerbueller 5mo 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

farceSpherule 5mo ago

[dead]

exabrial 5mo ago

Looks like someone needs to go take 27 training modules. That'll fix it.

dcrazy 5mo 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.

bilekas 5mo ago

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.

snihalani 5mo ago

Do they not believe in encrypted files?

passive 5mo 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 https://bsky.app/profile/andylevy.net/post/3m6ivhnthts2o I want to believe...

EdwardDiego 5mo 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.
- doginasuit 5mo ago
  It is real: https://www.yahoo.com/news/articles/fact-check-iwona-b-horyn-234711922.html https://www.yahoo.com/news/articles/fact-check-iwona-b-horyn...

tedggh 5mo ago

This seems like an act of sabotage disguised as incompetence.

deleted 5mo ago

[deleted]

itintheory 5mo 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?

deleted 5mo ago

[deleted]

chrismarlow9 5mo ago

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 5mo 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)

deleted 5mo ago

[deleted]

protastus 5mo ago

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 5mo ago
Good thing we fired every competent person in government!
red-iron-pine 5mo 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 5mo 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 5mo 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 5mo 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.

cestith 5mo ago

It looks like CISA should employ a CISA. https://www.cisa.gov/ https://www.cisa.gov/ https://www.isaca.org/credentialing/cisa https://www.isaca.org/credentialing/cisa

morpheuskafka 5mo 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 5mo 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 5mo 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"

nijave 5mo 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

dantiberian 5mo 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 5mo ago
I would expect this to work in accordance with Github uptime.... so take it for what its worth

deleted 5mo ago

[deleted]

jameson 5mo 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