Hacker News

Sometimes I feel like it's a cover for some other org actually just wanting to steal the data and this being the excuse.

"crazy crazy" gets the same point across

I think willfully not reporting this is gross negligence, but also other things.

Complaining about gutting, during examples of gross negligence is kind of a sympathy destroyer for me.

That's why we don't listen to rhetoric.

> ...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

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.

Machine Head - Struck A Nerve

The more things change, the more they stay the same.

Wise words, lovely song.

Which DOGE employee put this file on GitHub?

Yes, DOGE invented storing lists of text passwords and uploading them somewhere. What a monumental cost savings innovation, surely never been done before!

>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.

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.

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.

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.)

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.

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.

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.

seems crazier someone would tie their entire development platform to a cloud run by business interests

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.

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.

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.

most of that is context guard rails, and as context grows, they become guard jello until itll just do whatevers most immediate.

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!

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.

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.

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.

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"

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.

Turns out those standards writers knew something!

0: https://fusionauth.io/blog/securing-your-api

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.

This can be done in Azure using Entra (OAuth). I don't have API keys, or passwords of any kind, anywhere in the stack.

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 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.