2 ms·

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

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

simonw 4y ago
People have hooked up shells running commands already. A few days ago someone managed to extract an OpenAI API key from an environment variable because someone was running prompt output through an eval() function: https://twitter.com/ludwig_stumpp/status/1619701277419794435 https://twitter.com/ludwig_stumpp/status/1619701277419794435 Developers who don't understand prompt injection will continue to make nasty mistakes like that.
- juberti 4y ago
  I agree caution is needed here. We have taken a few steps: - 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.

simonw 4y ago

People have hooked up shells running commands already. A few days ago someone managed to extract an OpenAI API key from an environment variable because someone was running prompt output through an eval() function: https://twitter.com/ludwig_stumpp/status/1619701277419794435 https://twitter.com/ludwig_stumpp/status/1619701277419794435 Developers who don't understand prompt injection will continue to make nasty mistakes like that.

juberti 4y ago
I agree caution is needed here. We have taken a few steps: - 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.