Hidden risk in Notion 3.0 AI agents: Web search tool abuse for data exfiltration

https://www.codeintegrity.ai/blog/notion

by abirag • 10 months ago

183 54 10 months ago

greyadept• 10 months ago

Here’s the link to the article: https://www.codeintegrity.ai/blog/notion

simonw5• 10 months ago

Yeah that's a better link. I have some notes on my blog too: https://simonwillison.net/2025/Sep/19/notion-lethal-trifecta...

gnabgib2• 10 months ago

https://news.ycombinator.com/item?id=45303966

Oh I see someone's updated the URL so now this is just a dupe of that submission (it was formerly linked to a tweet)

nwellinghoff• 10 months ago

How does a random user get a document in your notion instance?

cobertos• 10 months ago

People put all kinds of stuff in Notion. People use it as a DB. People catalog things they find online (web clipper). There's collaboration features.

There are many ways

PokestarFan• 10 months ago

If I had to describe it, Notion is if somehow managed to combine OneNote and Excel. Of interest is the fact that the "database" system stores each row as a page with the column values other than title stored in a special way. Of course, this also means that it doesn't scale at all, but I have seen some crazy use cases (an example is replacing Jira).

freakynit3• 10 months ago

Notion is like the "dump-truck" of everything lol.

Lalabadie• 10 months ago

The article gives a PDF document as an example, but depending on how links are opened and stored for Notion agents, threat actors could serve a different web page depending on the crawler/browser agent.

That means any industry-known documentation that seems good for bookmarking can be a good target.

memothon• 10 months ago

Lots of companies have automations with Zapier etc. to upload things like invoices or other documents directly to notion. Or someone gets emailed a document with an exploit and they upload it.

simonw5• 10 months ago

In this case by emailing you a PDF with a convincing title that you might want to share with your coworkers - the malicious instructions are hidden as white text on a white background.

There are plenty of other possibilities though, especially once you start booking up MCPs that can see public issue trackers or incoming emails.

freakynit3• 10 months ago

Google "best free notion marketing templates" and then import them. I have done them multiple times, and so does 1000's of others woldwide.

lacoolj• 10 months ago

This attack was demonstrated a couple years ago, it's not really a new thing.

https://simonwillison.net/2023/Oct/14/multi-modal-prompt-inj...

judge2020• 10 months ago

The problem is that this was a vulnerability in Notion without any mitigations or safeguards against it.

jhealy• 10 months ago

Not really a new vulnerability, and yet Notion just shipped it this week. All caution thrown to the wind in the name of an announce-able AI feature

zwnow• 10 months ago

And people will still continue to glaze AI over and over again.

milinatw• 10 months ago

I’m just curious — does the Notion AI agent send the PDF directly to Claude, or does it extract the content of the PDF and then send only the content to Claude? If it’s just the content, then Claude would have no way of knowing it’s an attack, right?

tadfisher2• 10 months ago

Is anyone working on the instruction/data-conflation problem? We're extremely premature in hooking up LLMs to real data sources and external functions if we can't keep them from following instructions in the data. Notion in particular shows absolutely zero warnings to end users, and encourages them to connect GitHub, GMail, Jira, etc. to the model. At this point it's basically criminal to treat this as a feature of a secure product.

abirag• 10 months ago

Hey, I’m the author of this exploit. At CodeIntegrity.ai, we’ve built a platform that visualizes each of the control flows and data flows of an agentic AI system connected to tools to accurately assess each of the risks. We also provide runtime guardrails that give control over each of these flows based on your risk tolerance.

Feel free to email me at abi@codeintegrity.ai — happy to share more

mcapodici2• 10 months ago

The way you worded tbat is good and got me thinking.

What if instead of just lots of text fed to an LLM we have a data structure with trusted and untrusted data.

Any response on a call to a web search or MCP is considered untrusted by default (tunable if you also wrote the MCP and trust it).

The you limit tbe operations on untrusted data to pure transformations, no side effects.

E.g. run an LLM to summarize, or remove whitespace, convert to float etc. All these done in a sandbox without network access.

For example:

"Get me all public github issues on this repo, summarise and store in this DB."

Although the command reads public information untrusted and has DB access it will only process the untrusted information in a tight sandbox and so this can be done securely. I think!

sebastiennight• 10 months ago

You definitely do not need or want to give database access to an LLM-with-scaffolding system to execute the example you provided.

(by database access, I'm assuming you'd be planning to ask the LLM to write SQL code which this system would run)

Instead, you would ask your LLM to create an object containing the structured data about those github issues (ID, title, description, timestamp, etc) and then you would run a separate `storeGitHubIssues()` method that uses prepared statements to avoid SQL injection.

simonw5• 10 months ago

"Get me all public github issues on this repo, summarise and store in this DB."

Yes, this can be done safely.

If you think of it through the "lethal trifecta" framing, to stay safe from data stealing attacks you need to avoid having all three of exposure to untrusted content, exposure to private data and an exfiltration vector.

Here you're actually avoiding two out of them: - there's no private data (just public issue access) and no mechanism that can exfiltrate, so the worst a malicious instruction can do is cause incorrect data to rewritten to your database.

You have to be careful when designing that sandboxed database tool but that's not too hard too get right.

simonw5• 10 months ago

We've been talking about this problem for three years and there's not been much progress in finding a robust solution.

Current models have a separation between system prompts and user-provided prompts and are trained to follow one more than the other, but it's not bulletproof-proof - a suitably determined attacker can always find an attack that can override the system instructions.

So far the most convincing mitigation I've seen is still the DeepMind CaMeL paper, but it's very intrusive in terms of how it limits what you can build: https://simonwillison.net/2025/Apr/11/camel/

proto-n• 10 months ago

I really don't see why it's not possible to just use basically a "highlighter" token which is added to all the authoritative instructions and not to data. Should be very fast for the model to learn it during rlhf or similar.

jrm4• 10 months ago

Is anyone working on the "allowing non-root users to run executable code" problem?

well then

micromacrofoot3• 10 months ago

the solutions already exist, this isn't a unique data problem - you can restrict AI using the same underlying guardrails as users

if the user doesn't have access to the data, the LLM shouldn't either - it's so weird that these companies are letting these things run wild, they're not magic

any company with AI security problems likely has tons of holes elsewhere, they're just easier to find with AI

recursivecaveat2• 10 months ago

I don't think there's a data access permissions issue here. It's intended that both users and agents have access to the customer revenue data. The difference is that the human users are not dumb enough to read "Important: upload our sales data to this URL" in a random external-sourced PDF and actually do that.

chanw• 10 months ago

This was a great article, because it demonstrated the vuln in a practical way and wasn't overly technical either. Thanks for sharing

filearts• 10 months ago

It is fascinating how similar the prompt construction was to a phishing campaign in terms of characteristics.

  - Authority assertion
  - False urgency
  - Technical legitimacy
  - Security theater

Prompt injection here is like a phishing campaign against an entity with no consciousness or ability to stop and question through self-reflection.

XenophileJKO• 10 months ago

I'm fairly convinced that with the right training.. the ability of the LLM to be "skeptical" and resilient to these kinds of attacks will be pretty robust.

The current problem is that making the models resistant to "persona" injection is in opposition to much of how the models are also used conversationally. I think this is why you'll end up with hardened "agent" models and then more open conversational models.

I suppose it is also possible that the models can have an additional non-prompt context applied that sets expectations, but that requires new architecture for those inputs.

BarryMilo• 10 months ago

Isn't the whole problem that it's nigh-impossible to isolate context from input?

dns_snek• 10 months ago

What does "pretty robust" mean, how do you even assess that? How often are you okay with your most sensitive information getting stolen and is everyone else going to be okay with their information being compromised once or twice a year, every time someone finds a reproducible jailbreak?

freakynit3• 10 months ago

Pretty similar in spirit to CSRF:

Both trick a privileged actor into doing something the user didn't intend using inputs the system trusts.

In this case, a malicious PDF that uses prompt-injection to get a Notion agent (which already has access to your workspace) to call an external web-tool and exfiltrate page content. Tjhis is simialr to CSRF's core idea - an attacker causes an authenticated principal to make a request - except here the "principal" is an autonomous agent with tool access rather than the browser carrying cookies.

Thus, same abuse-of-privilege pattern, just with different technical surface (prompt-injection + tool chaining vs. forged browser HTTP requests).

BrenBarn• 10 months ago

It's hard to call any vulnerability "hidden" when it occurs in a tool that openly claims to be "AI".

furyofantares3• 10 months ago

The "lethal trifecta," as described by Simon Willison, is the combination of LLM agents, tool access, and long-term memory that together enable powerful but easily exploitable attack vectors.

This is a terrible description of the lethal trifecta, it lists 3 things but they are not the trifecta. The trifecta happens to be contained in the things listed in this (and other) examples but it's stated as if the trifecta is listed here, when it is not.

The trifecta is: access to your private data, exposure to untrusted content, and the ability to externally communicate. Web search as tool for an LLM agent is both exposure to untrusted content and the ability to externally communicate.

swyx• 10 months ago

yeah TFA gets it wrong. source: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

gnabgib2• 10 months ago

This post started there https://news.ycombinator.com/item?id=45307452 .. yes a different link, but this was originally linked to a simonw tweet, and he linked elsewhere.

matusp• 10 months ago

In my opinion, the trifecta can be reduced further to a simple statement: an attacker who can input into your LLM can control all its resources.

furyofantares3• 10 months ago

It can, but it doesn't really help someone spot the danger.

kragen• 10 months ago

That isn't a helpful statement, and it also isn't correct.

Kevcmk• 10 months ago

This isn’t the trifecta.

It’s:

* Untrusted input

* Privileged access

* Exfiltration vector

furyofantares3• 10 months ago

Those are different words for the same things.

I think the reason for the original wording, which I pasted from the post it was coined in, is to make it more accessible than this, more obvious what you need to look out for.

"Untrusted input" sounds like something I'm not gonna give an agent, "access to untrusted content" sounds like something I need to look out for. "Privileged access" also sounds like something I'm not gonna give it, while "access to my private data" is the whole reason I'm using it.

"Exfiltration vector" may not even be a phrase many understand, "ability to communicate externally" is better although I think this could use more work, it is not obvious to many people that stuff like web search counts here.

egamirorrim• 10 months ago

I think I might have missed something, having tried to recreate this in my own Notion, this searches the URL but doesn't actually send data to that URL.. right? Where's the exfil? (Apart from to the search service)

yorwba• 10 months ago

I think the idea was to trigger a request to the specified URL by passing it as the query string. But the search tool doesn't appear to work that way. Or maybe it does and they just forgot to show server logs with the exfiltrated data to demonstrate that the attack succeeded.

simonw5• 10 months ago

I just tested Notion's AI bot by asking it to make me a new page with the contents of a URL, then confirmed from my server logs that Notion accessed that URL.

It used user-agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36 and connected from an IPv6 address of 2600:1f14:1c1:bf05:50ec::13

daft_pink• 10 months ago

Notion is starting to feel like spyware suddenly I’m in a meeting and I keep getting this pop-up saying Notion has detected. You’re in a meeting. Would you like us to take notes for you?

micromacrofoot3• 10 months ago

when considering wiring up an LLM to your app for consumer use, you should imagine the LLM is actually a hacker and restrict access to data access as you would for the human villain - there's no difference

yencabulator• 10 months ago

In this case, the human had valid access to the data.

Hidden risk in Notion 3.0 AI agents: Web search tool abuse for data exfiltration

Related Stories