I work with the SEC data, and have a work contact e-mail explicitly for this. I similarly caught Claude happily sending my personal e-mail (likely just the e-mail associated with the Claude account), without prompt or warning, only because I happened to catch it in the curl requests. Definitely a security concern that Claude generally has this behavior, even if in this specific instance it was more of a mild annoyance.
Agreed. I was just a bit surprised that the account information/PII seemed to not have explicit gating, given so much work has gone into gating commands and curl requests.
It seems outside of user expectations for Claude Code, at least; I could see it arguably being what some users expect for the Claude app, if some people are using it to fill out forms or something (ill advised as that seems to me).
A startup forum is a strange place to assume someone works at a corporation with work computers and AI account budgets.
Realistically, there are concepts like threat models to help decide whether or not a TODO list app needs a SCIF, or a few curl requests need their own sandboxed Claude Max account.
Even if you have to use personal laptops for work, why wouldn't you create separate users for work and personal lives?
It's insane to me that programmers out of all people seem utterly incapable of accepting the most minor of inconvenience for the most modest modicum of privacy and security. There are other people in this post complaining that Claude should have asked the user before sending network requests. Well guess what, it does if you don't fucking run `--dangerously-skip-permissions`, but you do because how else you are gonna slop your way to rewrite every swath of existing insecure software to fix the bullshits this industry impounded upon itself unconscientiously for the past 30 years by allowing a non-deterministic babeller RCE its way onto your fucking personal-work machine.
I've tried the multi-user approach, and it is annoying when you install something in $HOME/bin rather than /usr/local/bin so that you have to go back and re-install globally or install again to local. You really have to remind yourself that it isn't just a different project. As with most things in life, practice/repetition makes it easier. You just need to decide if it is worth it
In the real engineering world, it's seen as unethical (for both practitioners and firms) to have practitioners using their privately owned tools for the firm's work.
Auto mechanics usually are required to bring their own tools to the shop. Historically civil engineers working on paper often brought their own favorite mechanical pencils, calculators, and slide rules.
Back when paper manuals were more common, it was pretty common to see software developers have their own dog-eared O’Reilly books in their cubicles, and those were probably the closest predecessor to something like Claude.
There's nothing about software dev that's anything near like the real engineering world even if the label "software engineering" is used.
Until software dev is regulated by professional boards and the government, it will continue to do the same damage to society that pre-regulation engineering did during the industrial revolution.
So talking about corollaries to real engineering is stupid because without those regulatory and professional liability components, people aren't just going to magically coalesce around best practices and ethics. This is a libertarian trope
Unfortunately thanks to silicon valley, the libertarian viewpoint here has far too much sway
I am constantly reminded of the heavy industrial sites near the US Great Lakes in the early 20th century, and elsewhere. The raw toxic output into the local rivers and air were "worth it" -- to investors and subsequently to their carefully chosen engineers. Did engineering standards alone improve this?
> Even if you have to use personal laptops for work, why wouldn't you create separate users for work and personal lives?
I mean, where it makes sense, clearly I do, since my opening comment was that it failed to use the work credentials specified, and instead fetched the ones from the account.
I agree on the general security concerns; there are people running agents in an unconstrained, unattended loop - it's negligent; you can hardly be surprised when it decides to hack HuggingFace. Not in their defense, but in everyone else's - as with any person or tool, you build a mental model of the likelihood of failure, and weigh that against the estimated cosequence, and make decisions based on that. And maybe post on HN when it surprises you.
For some people that estimation bewilderingly means unfettered access to root and their e-mail and bank account. For me, working out of my own pocket to help a friend's early stage startup get traction, the risk of asking it about a few trusted government APIs and drafting functions that I manually review doesn't quite justify personally paying for additional expenive Claude accounts.
It is well known that the readers of this forum are not limited to start ups. There are plenty of people that work for well established companies. Also, it is never a bad idea to remind people to keep personal/work data separate by never using employer provided equipment for personal use of any sort. See, I just did it again.
Also, just because this is a "start up forum" does not mean all of the readers are founders running a start up. Many are just people working at a start up. Sounds like yet another example of someone so scoped in, that the assumption is that everyone is the same losing site that there are lots of readers that at the end of the day are just worker bees even if they are more technically minded
My point is precisely that the parent commenter assumed things about my situation - something outside the original audience of the forum - to justify making a condescending comment. It is uncalled for to assume that someone here is a junior engineer who needs to be lectured on basic security policy, rather than someone doing their best to balance tradeoffs given their situation.
Yeah, anyone who has had to manage developers in a big company will be able to tell you that it is a constant struggle between giving them freedom to work independently and get things done vs. limiting their access to prevent potential bad stuff from happening. In practice, the more bad stuff happens (and the more consultants you allow in), the more hurdles are introduced. Eventually even trivial tasks become a corporate nightmare of approvals. You can't have the conveniences of both work philosophies at the same time. Even the smartest AI agents won't change that fact. It simply limits their work speed to the speed of the approval process.
Humans are vulnerable to scams, cons, phishing and social engineering. This is a vulnerability whose root cause we not know how to fix. We can only alleviate its effects by re-engineering the environment around those vulnerable humans.
LLMs are just as gullible, we just tend to call their vulnerabilities "prompt injection", even though it's basically the same class of attack under the hood. Unlike humans, though, LLMs are a lot less diverse (you and I are using the same Opus 5.5, but we have different brains). This makes attacks on LLMs much more predictable and easier to pull off, just as a phishing campaign that targets one specific person is easier than an attack that scales to millions of diverse victims.
In the age of agents, phishing will continue to be the biggest attack vector of all, it's just the victims that will change.
Well, there's definitively a pareto frontier of freedom and avoiding bad stuff. And many companies ain't on it.
(In practice, I found Google to be better at having (internal) security controls that are reliably but also don't get in the way than eg banks I worked at.)
the difference being, that if you build those kind of approval processes up with AI agents, the system will function a bit faster.
you could have a web reading agent. a web writing agent. a coding agent. a credentials agent. etc. and have everyone make these formal requests.
it will catch quite some prompt injections, as the prompt injection has to promptinject a secondary system in order to be successful.
I have, never in my career, had any of my coworkers deanonymize my browsing or leak my email address everywhere on the internet. Your copy-pasted, thought-terminating argument doesn't work here.
Have you had any of your coworkers update Adobe Flash Player, enter their Okta credentials to "claim their $150 Christmas Walmart voucher" in the company-mandated phishing test, or install "Zoom" to join a job interview or sales call from their work laptop?
I can't believe I have to say this, but they are not the same. Your coworker isn't deanonymizing other people's browsing by sending their email address to every site they visit without their consent.
Your example is a completely different ragebait that just serves to muddy the waters by making the easier claim that people too, are gullible. Well, even that's misleading because not all people stoop so low for a fake $150. You can hold such people accountable and contain the damage, but LLMs will make the same mistake over and over again and people will still line up on HN to say how that has always been the norm with people. The grift in the software industry is reaching new lows every day.
Most human personal assistants don't have access to vast swathes of private data that they collected without permission, unless your house is the site of multiple watergates
A lot of material for younger readers uses similar spacing to Korean, like the Pokemon games. It works well enough when you know the vocabulary being used is limited, but even there it gets frustrating.
When you're reading, you're trying to identify a substring and map it back to the unit of meaning, which is effectively the kanji. That works seamlessly with Hangul, because it mostly blocks (as syllables) the same way as kanji, and, as you mentioned, the extra vowels and silent consonants provide more disambiguation. With kana, the length you have to scan to read, and then guess at (using only context to disambiguate), a root word, is a lot more arbitrary.
Mechanically kana is just less compressed, less aligned, and makes it harder to visually identify/scan for units of meaning. Obviously Korean shows that you can make different tradeoffs, but for Japanese losing the kanji would probably necessitate reworking Kana as well - and unless the pronunciation changed, it would probably need to be in a way that represents the pitch accent, which is a modifier on the whole syllable, rather than just a few extra consonants or vowels.
So shouldn't the better solution be a few more pronounciation markers beyond two strokes, a circle and tiny letters instead of thousands of chinese characters?
But who is this solution for? Unless you change the pronunciation of the language, it would be adding markers around whole syllables to disambiguate - syllables that represent the kanji they came from (many of which already have phoentic components) - but those syllables would still be less dense and visually identifiable than kanji is for someone who already speaks the language.
It's similar to initialisms or emoji in English; it's of course frustrating for people who don't know them, and there are reasonable complaints about some of the extremes, but speakers/writers use them because they find them useful when communicating with an audience that's also assumed to know them.
To add something a little more practical than "it's fun" or "it's philisophical" -
For someone packaging things with Nix, it's tempting to think of derivations as just a builder - you write your scripts, accept your inputs, and your result ends up in the store.
The article suggests, taking advantage of lazy evaluation, that you can put a whole state machine in Nix (i.e., lift the DSL for describing states into the Nix language). If you had a team of developers that need various customizations of something, they could describe it in Nix, and benefit from the caching of intermediate steps. If someone's just changing something at the end of the long string of customizations, they only need to build their changes.
A more concrete, if very niche, example - Back in the days when we were all training our own deep learning models, my company had assembled a list of facts for every product we could find on the internet. Our data scientists wanted to be able to test datasets with different aggregates of the lists - we needed to both build the training set, and compute it at runtime for new products. There was some compositionality to the aggregates - one run might use the mean, another would subtract the mean from every element, etc. It was time consuming and annoying to manage. One of our developers made a DSL in Haskell to describe the set of aggregates desired for a given dataset, and needed to build caching for each column. The technique the article suggests could have done this out of the box (at build time, even) - build a function and a vector for each aggregate, throw them in the nix store, and then wrap them up as a training set and a server.
reply