If you're going to give a LLM-driven program the ability to execute functions that can change state in the world you need to understand prompt injection, so you don't accidentally build something that you really shouldn't have built.

The first public prompt injection vulnerability was a Twitter bot which started spam-mentioning people and threatening the president. https://arstechnica.com/information-technology/2022/09/twitt...

Sure. But also, so? Seems like a storm in a tea cup. "Our twitter got hacked", the end. There are countless such examples that have nothing to do with prompt injections. If anything the phrase "all publicity is good publicity" comes to mind.

I remember in the mesozoic era of the internet (early 00's) there was something like a KFC promo website where they put a guy in a chicken suit and had him respond to chat suggestions directly from users 24/7. Hilarity, as you can imagine, ensued. Shenanigans even.

If some user submitted content (even if it is sieved via a model) ends up "inappropriate" you can just delete it and move on.

I probably wouldn't hook it up to a shell running commands but the same generic advice as with all untrusted input applies..

Developers who don't understand prompt injection will continue to make nasty mistakes like that.

- Rate limits are enforced to provide caps on agent and function usage.

- Execution depth is capped to prevent the LLM from getting into loops.

- Function output is sanitized to prevent corruption of LLM state.

- Functions execute in a completely separate environment from the rest of the service, including the LLM, to reduce the impact from bad functions.

Note that this doesn't entirely prevent against "; DROP TABLES"-type hacks against the implementation of the function, but that problem isn't unique to us. It may however be possible for the LLM to look at function inputs and flag overtly malicious ones.