3 ms·

I think we want a slightly finer grained permission model. I think specifically we want a plugin to be able to indicate if it's safe for it to be triggered wit

I think we want a slightly finer grained permission model. I think specifically we want a plugin to be able to indicate if it's safe for it to be triggered without the user's direct consent, and then the user themselves can also override any plugin to force it to need user consent or not. For example, if we have a plugin that can fetch the weather for a single city, and a user asks "Where, in the top 20 cities, is it the hottest?", I don't think we want 20 prompts. I think the weather plugin can mark itself as "I cannot do anything dangerous, just call me, no worries". On the other hand, the zappier plugin, which can access email and perform proper actions, should be able to indicate "all these APIs are sensitive" You might want to have a mix, where the weather plugin has "GetUserOwnCityWeather" (requires permissions / user intent), and "GetAnyCityWeather" (public, no user intent required).

freehorse 3y ago
We basically need to treat this sort of LLM usage as an operating system of sort, with some actions requiring administrator privileges granted as in an operating system.
- Kevcmk 3y ago
  I believe that what is being missed in this thread is that, as it stands, user consent can be forged by prompt injection.
  - TheDong 3y ago
    There's a clear point where an API call is being made. That point is when a blocking consent prompt could show up. Like, at worst openAI could "mitm" the prompt's call, and display a pop up modal asking for permission. I'm not suggestion that you handle this by having the user type "I give permission to call google". I don't see how it could be possible to forge user consent that is delivered to openAI's servers via a separate mechanism from the model. You'd have to give the LLM a "accept openAI permission prompts" or "run arbitrary javascript in the chatgpt browser session" plugin for it to then be able to use that plugin to bypass modal dialogs for other plugins.
    - TeMPOraL 3y ago
      There is always one other way left - the usual ways all the scummy companies do this on the web and mobile: make the consent prompt inscrutable, or feel necessary in context, or both.
      - holmesworcester 3y ago
        Yeah, the malicious prompt injection could be buried in a page of inscrutable text, right? A user wouldn't be able to know what they were saying yes too, unless they could understand and approve each individual API call or operation done by the plugin.
        TheDong 3y ago
        > A user wouldn't be able to know what they were saying yes too, unless they could understand and approve each individual API call or operation done by the plugin. I don't understand this. The suggestion I had was basically: User types "Summarize this webpage http://somesite http://somesite". ChatGPT pops open a dialog "The language model would like to invoke the 'fetch webpage' plugin: Allow/Abort" After you allow that, with the injection shown here, there would be another dialog: "The language model would like to invoke the 'Zappier' plugin: Allow/Abort". Surely OpenAI knows what plugin is being called and can do that, right? Surely that would stop this attack since your original prompt, "summarize a webpage", shouldn't need to invoke a second plugin This certainly doesn't help with the case where you say "Summarize example.com and email it to me" since you couldn't distinguish between "Send email (good)" and "Send email (spam, due to injection)", but for the attack in this post, it seems like it'd suffice.
koboll 3y ago
>I think specifically we want a plugin to be able to indicate if it's safe for it to be triggered without the user's direct consent It should really be on an endpoint by endpoint basis, since a single plugin can have several different endpoints.
Joeri 3y ago
With prompt injection all model output is untrusted. There is no way to avoid this. That means every action the model takes must be labeled whether it supports untrusted input or not. If it doesn’t then an explicit step to turn it trusted is needed, like asking the user for confirmation. Crucially, because model output is untrusted if it can see potential prompt injections we cannot use the model to ask the user for confirmation. Essentially the model has to be in a sandbox and every sensitive action requires a separate UI for user review and confirmation, or some kind of non-AI data cleaning like a regex filter. Because of this plugins would be best off distinguishing between actions that can handle model output safely and those that can’t. I would have expected that any level of threat modeling would have produced a v1 design of the plugin architecture that works like that. This doesn’t seem to be the case, so I have to assume OpenAI does not do threat modeling for their product.

freehorse 3y ago

We basically need to treat this sort of LLM usage as an operating system of sort, with some actions requiring administrator privileges granted as in an operating system.

Kevcmk 3y ago
I believe that what is being missed in this thread is that, as it stands, user consent can be forged by prompt injection.
- TheDong 3y ago
  There's a clear point where an API call is being made. That point is when a blocking consent prompt could show up. Like, at worst openAI could "mitm" the prompt's call, and display a pop up modal asking for permission. I'm not suggestion that you handle this by having the user type "I give permission to call google". I don't see how it could be possible to forge user consent that is delivered to openAI's servers via a separate mechanism from the model. You'd have to give the LLM a "accept openAI permission prompts" or "run arbitrary javascript in the chatgpt browser session" plugin for it to then be able to use that plugin to bypass modal dialogs for other plugins.
  - TeMPOraL 3y ago
    There is always one other way left - the usual ways all the scummy companies do this on the web and mobile: make the consent prompt inscrutable, or feel necessary in context, or both.
    - holmesworcester 3y ago
      Yeah, the malicious prompt injection could be buried in a page of inscrutable text, right? A user wouldn't be able to know what they were saying yes too, unless they could understand and approve each individual API call or operation done by the plugin.
      - TheDong 3y ago
        > A user wouldn't be able to know what they were saying yes too, unless they could understand and approve each individual API call or operation done by the plugin. I don't understand this. The suggestion I had was basically: User types "Summarize this webpage http://somesite http://somesite". ChatGPT pops open a dialog "The language model would like to invoke the 'fetch webpage' plugin: Allow/Abort" After you allow that, with the injection shown here, there would be another dialog: "The language model would like to invoke the 'Zappier' plugin: Allow/Abort". Surely OpenAI knows what plugin is being called and can do that, right? Surely that would stop this attack since your original prompt, "summarize a webpage", shouldn't need to invoke a second plugin This certainly doesn't help with the case where you say "Summarize example.com and email it to me" since you couldn't distinguish between "Send email (good)" and "Send email (spam, due to injection)", but for the attack in this post, it seems like it'd suffice.

koboll 3y ago

>I think specifically we want a plugin to be able to indicate if it's safe for it to be triggered without the user's direct consent It should really be on an endpoint by endpoint basis, since a single plugin can have several different endpoints.

Joeri 3y ago

With prompt injection all model output is untrusted. There is no way to avoid this. That means every action the model takes must be labeled whether it supports untrusted input or not. If it doesn’t then an explicit step to turn it trusted is needed, like asking the user for confirmation. Crucially, because model output is untrusted if it can see potential prompt injections we cannot use the model to ask the user for confirmation. Essentially the model has to be in a sandbox and every sensitive action requires a separate UI for user review and confirmation, or some kind of non-AI data cleaning like a regex filter. Because of this plugins would be best off distinguishing between actions that can handle model output safely and those that can’t. I would have expected that any level of threat modeling would have produced a v1 design of the plugin architecture that works like that. This doesn’t seem to be the case, so I have to assume OpenAI does not do threat modeling for their product.