It's not that the tool itself is inherently insecure - it's more about how users are encouraged to use it.
Nearly all workflows built using N8n that I've seen face some kind of prompt injection vulnerability. This is primarily because, in most cases, you configure the LLM by directly inserting external data into the system prompt. As many of you know, the system prompt has the highest execution priority, meaning instructions placed there can heavily influence how the LLM interacts with its tools.
While this isn't exploitable in every situation, it can often be exploited rather generically: by embedding prompts in your social media bio, website, or other locations from where these workflows pull data. Recently, I've managed to use this technique to prompt a random LinkedIn bot to email me back a list of their functions. That's not overly exciting in itself, but it clearly demonstrates the potential for malicious use.
This issue is not specific to N8n. Other tools do it too. But it seems to me there is little to no awareness that this is in fact a problem.
There is a better, safer way to incorporate external data into LLM prompts without jumping through hoops, but unfortunately, that's not how things are currently done with N8n, at least as of today.
As somebody working in AI Security: There isn't one currently. If you're feeding untrusted inputs into an LLM (today), you have to treat the entire prompt as radioactive.
That means:
- Limit the potential for a malicious prompt to do anything bad
- Scope permissions to the lowest level you can
There are some other mitigations (moderation APIs using a 2nd LLM), but in general they're not 100% solutions. You really need to design your systems around accepting this limitation today.
A- Limit the capabilities of users.
B- Help users limit the capabilities that they to their sub-users, whether they be per-program capabilities or per dependency capabilities.
I think B is the path forward, if you give a user access to emails and files and ChatGPT, then he can give ChatGPT access to emails and files and do damage that way.
With B you can give the user access to ChatGPT and email and a file system, but help him configure fine grained permissions for their experiments.
I prefer to have my flow hard-coded, with specific data input/output between steps, and have the calls be done through n8n connections instead of letting the AI call the tools with arbitrary data.
It's not that the tool itself is inherently insecure - it's more about how users are encouraged to use it.
Nearly all workflows built using N8n that I've seen face some kind of prompt injection vulnerability. This is primarily because, in most cases, you configure the LLM by directly inserting external data into the system prompt. As many of you know, the system prompt has the highest execution priority, meaning instructions placed there can heavily influence how the LLM interacts with its tools.
While this isn't exploitable in every situation, it can often be exploited rather generically: by embedding prompts in your social media bio, website, or other locations from where these workflows pull data. Recently, I've managed to use this technique to prompt a random LinkedIn bot to email me back a list of their functions. That's not overly exciting in itself, but it clearly demonstrates the potential for malicious use.
This issue is not specific to N8n. Other tools do it too. But it seems to me there is little to no awareness that this is in fact a problem.
There is a better, safer way to incorporate external data into LLM prompts without jumping through hoops, but unfortunately, that's not how things are currently done with N8n, at least as of today.