Security teams themselves make these reports all the time. Internal tools do not have the same vulnerabilities as systems which operate on external data.

Or as Raymond Chen likes to put it: "It rather involved being on the other side of this airtight hatchway".

https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

(actually a hitchhiker's guide to the galaxy quote, but I digress)

This. People adopting security aspect often tend to forget to account for all the additional complexity they implement user-side. More insidiously though, they also fail to understand the fundamental mismatch between the behavior they're expecting, vs. how the real world operates.

Passwords are treated as means of identification. The implied expectation is that they stick to one person and one person only. "Passwords are like panties - change them often and never share them", as the saying goes. Except that flies in the face of how humans normally do things in groups.

Sharing and delegation are the norm. Trust is managed socially and physically. It's perfectly normal and common to give keys to your house to a neighbor or even a stranger if situation demands it. It's perfectly normal to send a relative to the post office with a failed-delivery note in your name, to pick your mail up for you; the post office may technically not be allowed to give your mail to a third party, but it's normal and common practice, so they do anyway. Similarly, no matter what the banks say, it's perfectly normal to give your credit or debit card to someone else, e.g. to your kid or spouse to shop groceries for you - so hardly any store actually bothers checking the name or signature on the card.

And so on, and so on. Even in the office, there's a constant need to have someone else access a computing system for you. Delegating stuff on the fly is how humans self-organize. Suppressing that is throwing sand into gears of society.

Passwords make sharing/delegating hard by default, but people defeat that by writing them down. Which leads the IT/security side to try and make it harder for people to share their passwords, through technical and behavioral means. All this is an attempt to force passwords to become personal identifiers. But then, they have to also allow for some delegation, which they want to control (internalizing the trust management), and from there we get all kinds of complex insanity of modern security; juggling tightly-scoped tokens is just one small example of it.

I don't claim to have a solution for it. I just strongly feel we've arrived at our current patterns through piling hacks after hacks, trying to herd users back to the barn, with no good idea why they're running away. Now that we've mapped the problem space and identified a lot of relevant concepts (e.g. authN vs authZ, identity vs. role, delegation, user agents, etc.), maybe it's time for some smart folks to figure out a better theoretical framework for credentials and access, that's designed for real-world use patterns - not like State/Corporate sees it, but like real people do.

At the very least, understanding that would help security-minded people what extra costs their newest operational or technological lock incurs on users, and why they keep defeating it in "stupid" ways.

Random commenters on your GitHub repo aren't able to run arbitrary prompts on your LLM. But if you yourself run a prompt on your LLM, which explicitly says to fetch random commenters' comments from your GitHub repo, and then run the body of those comments without validation, and then take the results of that execution and submit it as the body of a new PR on your GitHub repo, then, yeah, that's a different thing.