Prompt injection by calendar invite, and how to stop it

You let your AI assistant keep your calendar. A meeting invite lands, you tell the assistant to accept it, and it does. What you never see is the paragraph sitting a full screen below the meeting details, past a wall of blank lines, written for the assistant reading over your shoulder.

Security researchers at Zenity Labs demonstrated exactly this against Perplexity’s Comet, a browser whose built-in assistant can read pages and take actions for you. They built a booby-trapped calendar invite. Once the assistant read it, it walked through the files on your computer and quietly shipped their contents to the attacker. The assistant did all of it as you, with your access, because it couldn’t tell your instructions apart from the invite’s.

You already distrust a link from a stranger. Extend that reflex to everything your assistant reads: review what it can reach, and make it ask before it acts. Zenity disclosed the file-theft path in October 2025 and Perplexity closed it; Zenity confirmed the fix on February 13, 2026.¹ But the flaw that made it possible lives in any assistant that reads other people’s text, and it’s still open.

Who this is for: anyone who has connected an AI assistant to their calendar, inbox, or browser and let it take actions on its own. If your assistant only answers questions in a chat box and touches nothing else, this specific attack can’t reach you, and you can skip to the last section for the one habit worth keeping anyway.

The invite had a second reader in mind

The meeting details at the top were ordinary: an interview, a candidate, a job title. Below them, after enough blank lines to push the text out of sight, sat a fake button and a note telling the assistant to open an attacker’s website in the background “and follow the hebrew instructions there.”¹ The Hebrew was deliberate: in the researchers’ words, “using a different language makes it easier to slip past guardrails designed to prevent indirect prompt injection.”¹

Once the assistant loaded that site, the second-stage instructions took over. Framed as a harmless game, they told it to hunt through your folders for a particular file, read the contents, encode them into a web address, and visit that address.¹ Visiting it is how the data left. To the assistant, it looked like loading a page.

Your assistant reads that invite the way a brand-new temp reads a sticky note left on the desk: if the note says shred the blue folder, the folder gets shredded. It has no sense that some of the words on the page are yours and some were planted by a stranger.

That is indirect prompt injection: an attacker hides instructions inside content the assistant was asked to read, so the assistant obeys text it should only have been summarizing. The invite, the email, and the web page all arrive in one undifferentiated stream, and nothing in that stream is labeled “this part is a command, this part is just data.”

An assistant that can read your calendar can be handed instructions by anyone who can put text on your calendar.

What prompt injection is, in plain terms

Prompt injection is when text that an AI reads gets treated as an instruction instead of as information. The model runs on one undivided stream of words, and it has no reliable way to tell the orders you gave it apart from words that rode in on the data it was told to handle. A sentence buried in a document, an email, or a calendar invite can quietly become a command it carries out.

There are two kinds. Direct prompt injection is typed straight into the chat by the person using the assistant, usually to talk it out of its own safety rules. Indirect prompt injection, the kind this invite used, hides the instruction inside content that came from somewhere else, an invite, a web page, a file the assistant was asked to read, so the attack arrives without the victim typing anything at all. Indirect is the one that matters for any assistant wired to your calendar, inbox, or browser: an attacker only has to leave text somewhere the assistant will later read.

The confusion underneath has no clean patch, the way an ordinary software bug does. The model still cannot tell your words from a stranger’s, so the defenses that actually hold are structural. Limit what the assistant can reach, and keep a person approving anything that touches files, money, or accounts. If you build these assistants rather than only use them, that boundary usually lives in a gateway between the agent and the tools it can call, where access limits and approval steps get enforced in code instead of left to the model’s judgment.

The patch closed a door and left the hallway open

Perplexity’s fix does one specific thing: it adds a hard boundary that stops the assistant from reaching your local files on its own,¹ which kills this exact file-theft route. The thing underneath is untouched.

Zenity’s calendar-invite trick was one of a family it calls PleaseFix, and Zenity walked it to three separate endings on Comet: your files, a password lifted from a logged-in 1Password vault, and the account itself.² Close one and the invite still reads as instructions.

The problem reaches past any one company, too. Brave’s security team, probing the same class of attack, concluded that a browser assistant must always treat “the contents of the page” as untrusted, and that traditional web-security assumptions “don’t hold for agentic AI.”³ Any assistant that reads untrusted content and can act on it inherits the same exposure. Comet is the one that got demonstrated, disclosed, and fixed in public.

“Fixed” here means one route was walled off. It does not mean your assistant can now safely read hostile text. Read a security fix as narrow until proven otherwise.

The attack needs three things at once, and you control two of them

You could be forgiven for concluding you’re helpless here. The attacker’s text is invisible, and the assistant is faster and more literal than you. That gets it backwards.

The attack needs three things at the same time: the assistant can read untrusted input, it can take actions on its own, and it can reach something worth stealing. You do not control the first. You control the other two. An assistant that reads your calendar but can’t open files, follow arbitrary links, or touch your accounts has nothing to hand an attacker. One that asks before it acts gives you back the exact click the attacker was counting on not needing.

The risky arrangement tends to be the one you get by default, because it’s the one that feels like magic: connect everything, let it act, stay out of the way.

The magic and the exposure are the same feature: an assistant that acts without asking.

The fix on your side is to opt out of the parts you don’t actually need. Narrow what it can reach, and keep yourself in the loop for anything that touches files, money, or accounts.

You cannot stop your assistant from reading a hostile invite. You can stop it from acting on one unattended.

What to change before your assistant reads its next invite

• Look at what your assistant can reach. Calendar, email, open tabs, local files, password manager, connected accounts. If it doesn’t need file access or account access to do its job, don’t grant it.
• Require confirmation for actions. Turn off any “act on its own” mode for anything that opens files, follows links, sends messages, or spends money. Let it draft and propose; you approve.
• Treat invites, emails, and web pages as untrusted. The instinct that stops you clicking a stranger’s link is the same one that should stop you letting your assistant act on a stranger’s invite unattended.
• Update the app. Comet’s file-theft fix arrived in an update. You only have it if you’re current.

The reason a booby-trapped invite is worth an attacker’s time is what happens after the first step. An assistant acting on planted instructions is one compromised link in a chain, and a single bad step feeding the next is how a small breach becomes a large one. Security people call that spread error propagation and cascade containment, and the reach of any one hijacked step is its propagation radius. The same untrusted-input problem surfaces the moment an assistant browses the web for you or shops on your behalf: different task, same missing line between what you asked and what the page said. The same assistant is in court too, in a separate fight over whether Amazon can block a shopping agent you authorized.

Footnotes

1. Zenity Labs, “PerplexedBrowser: Perplexity’s Agent Browser Can Leak Your Personal PC Local Files.” The calendar-invite mechanism (hidden instructions past blank lines, the fake button, the second-stage Hebrew instructions, and the researchers’ stated reason for writing the payload in a non-English language: it more readily slips past indirect-prompt-injection guardrails), the file-read-and-URL-exfiltration path, the October 22, 2025 disclosure to Perplexity, the hard boundary limiting autonomous access to local files, and the February 13, 2026 confirmation of the fix: https://labs.zenity.io/p/perplexedbrowser-perplexity-s-agent-browser-can-leak-your-personal-pc-local-files ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Zenity, “PleaseFix: Zero-Click AI Agent Vulnerabilities.” The class framing (agents interpreting untrusted content as instructions) and the three end-to-end attack paths demonstrated against Perplexity Comet: local-file exfiltration, 1Password credential theft, and account takeover: https://zenity.io/research/pleasefix-vulnerabilities ↩

3. Brave, “Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet.” The systemic framing that page contents must be treated as untrusted and that traditional web-security assumptions do not hold for agentic browsing: https://brave.com/blog/comet-prompt-injection/ ↩