I've had the opportunity to deploy LLMs for a variety of commercial use cases, and at least in these instances, I'd have to do something truly stupid for prompt

I've had the opportunity to deploy LLMs for a variety of commercial use cases, and at least in these instances, I'd have to do something truly stupid for prompt injection to pose an actual threat to users (e.g., failing to isolate user sessions, allowing the model to run arbitrary code, allowing the model to perform privileged actions without user confirmation, and so on). Moreover, if the user is the one doing the "prompt injection," I would just call that "advanced usage." I'm deploying these services as tools meant to, well, serve my clients. If they want to goof off with some erotic roleplay instead of summarizing their incoming emails, that's their prerogative. If the person emailing them wants them to do that without their consent, well, that's an organizational problem at best and an unrelated technical problem at worst (i.e., traditional email filtering should do the trick, and I'm happy to implement that without blaming the LLM). Cybersecurity problems around LLMs seem to arise most often when people treat these models as if they are trustworthy human-like expert agents rather than stochastic information prediction engines. Hooking an LLM up to an API that allows direct manipulation of privileged user data and the direct capability to share that data over a network is a hilarious display of cybersecurity idiocy (the Bard example you shared downthread comes to mind). If you wouldn't give a random human plucked off the street access to a given API, don't give it to an LLM. Instead, unless you can enforce some level of determinism through traditional programming and heuristics, limit the LLM to an API which shares its request with the user and blocks until confirmation is given.