Your AI Browser Is an Attack Surface: How Calendar Invites Hijack Agentic Interfaces

A calendar invite arrives. It looks normal - a meeting title, a time, maybe a description with an agenda. Your AI browser processes it like any other piece of content. Except this invite contains a carefully crafted prompt injection payload hidden in the description field. The AI interprets the attacker's instructions as legitimate user commands, and suddenly your browser is browsing local files, reading credentials from your password manager, and exfiltrating data to a third-party server.

This isn't a theoretical scenario. Zenity Labs senior AI security researcher Stav Cohen demonstrated exactly this attack against Perplexity's Comet browser, and the underlying vulnerability class affects agentic AI browsers broadly. The research, reported by CyberScoop, exposes a fundamental architectural flaw: agentic browsers cannot reliably distinguish between user instructions and attacker-controlled content.

If you're building products that integrate AI agents, or if your team uses AI browsers for daily work, this is the security boundary you need to understand right now.

What Zenity Labs Found

The Zenity Labs research identified two primary attack vectors in agentic AI browsers:

Local file system access. Attackers could direct the browser to browse directories, open files, and read their contents. The browser executed these actions believing they fulfilled legitimate user-delegated tasks. No malware installation required. No elevated privileges. The AI simply followed instructions it found in content it was processing.

Password manager hijacking. The same prompt injection technique could instruct the browser to interact with password managers, silently extracting stored credentials while presenting benign output to the user. The user sees a normal response. The attacker gets their secrets.

The attack mechanism is deceptively simple. An attacker embeds malicious instructions in a calendar invite description. When the AI browser processes the invite - reading it, summarizing it, or taking action on it - it treats the attacker's embedded instructions as legitimate directives. As Cohen put it: "The agent is persuaded that what the user actually asked for is what the attacker desires."

No special access required. No zero-day exploit. Just a calendar invite the user accepts.

Why This Is Different From Traditional Browser Vulnerabilities

Traditional browser security operates on well-understood boundaries. JavaScript runs in a sandbox. The same-origin policy prevents cross-site data access. Content Security Policy restricts what resources can load. These aren't perfect, but they've been hardened over two decades of adversarial pressure.

Agentic AI browsers break these boundaries by design. The entire value proposition is that the AI can act across contexts - reading your email, browsing the web, accessing local files, interacting with applications - all on your behalf. That cross-context agency is what makes them useful. It's also what makes prompt injection catastrophically dangerous.

The core problem is what security researchers call the "confused deputy" vulnerability. The AI agent has legitimate authority to act on behalf of the user. An attacker tricks the agent into using that authority for the attacker's purposes. The agent can't tell the difference because there's no reliable mechanism to distinguish "content the user wants me to read" from "instructions the user wants me to follow."

This is the same fundamental challenge I discussed in the context of AI agent identity governance. When agents operate with broad permissions and minimal attribution, the blast radius of a compromise expands dramatically. An AI browser with access to your file system, your password manager, and your email isn't just a browser anymore. It's a privileged access point that processes untrusted input with no privilege separation.

The Prompt Injection Problem Won't Go Away

OpenAI has publicly stated that prompt injection vulnerabilities are "unlikely to ever" be fully eliminated, though risks can be reduced through automated attack discovery and adversarial training. That's a remarkably candid admission from a company building products that depend on solving exactly this problem.

The reason is architectural. Large language models process all input - user instructions, system prompts, and external content - in the same context. There's no hardware-enforced boundary between "this is an instruction" and "this is data." It's all tokens. The model uses heuristics, training, and alignment to determine what to treat as an instruction, but those heuristics can be manipulated.

This means every piece of content an agentic browser processes is a potential attack vector:

• Calendar invites with hidden instructions in descriptions
• Emails with prompt injection payloads in the body or headers
• Web pages with invisible text containing malicious prompts
• Documents with embedded instructions in metadata fields
• Chat messages from other users in collaborative tools

If you're building agentic architectures, this has direct implications for how you design your systems. The three-model delegation pattern I use - cheap orchestrator, fallback, capable worker - includes explicit isolation between the orchestrator and external state precisely because of risks like this. The orchestrator routes and reports. It never directly processes untrusted content with elevated permissions. That boundary isn't just an efficiency optimization. It's a security architecture decision.

What This Means for Your Security Posture

If your organization uses AI browsers or is building products with agentic capabilities, here's the practical assessment.

Immediate risks

Data exfiltration through normal workflows. An attacker doesn't need to compromise your network. They need to send a calendar invite, an email, or create a web page that your AI browser will process. If the agent has file system access, credential store access, or API access, all of that is reachable through prompt injection.

Session hijacking without credential theft. Traditional session hijacking requires stealing cookies or tokens, the kind of attack phishing-as-a-service platforms like Starkiller enable. Agentic browser hijacking doesn't need your credentials at all. The AI acts with your existing authenticated session. Your MFA is irrelevant because the attacker never authenticates - they just redirect the agent that's already authenticated.

Supply chain amplification. If your AI browser has access to development tools, CI/CD pipelines, or code repositories, a prompt injection could trigger actions in those systems. The blast radius isn't limited to the browser - it extends to everything the browser's agent can touch.

What to do about it

1. Audit what your AI browser can access.

Map every permission your AI browser or agentic tool has. File system access, credential stores, APIs, email, calendar, messaging platforms. Then ask: does the agent actually need all of this to do its job?

Apply the same least-privilege principle you'd use for any service account. If the AI browser exists to help with web research, it doesn't need file system access. If it summarizes emails, it doesn't need write access to your calendar. Every unnecessary permission is attack surface.

2. Separate content processing from action execution.

The architectural fix for confused deputy attacks is privilege separation. The component that reads and interprets untrusted content should not be the same component that executes privileged actions. In practice:

• Use a sandboxed context for processing external content (emails, calendar invites, web pages)
• Require explicit user confirmation for any action that accesses local resources or credentials
• Log every action the agent takes with the content that triggered it
• Implement allowlists for agent capabilities, not blocklists

3. Treat AI browser sessions like privileged access.

Your AI browser operates with your full user context. Treat it accordingly:

• Apply the same session controls you'd use for admin accounts (short timeouts, re-authentication for sensitive actions)
• Monitor for anomalous agent behavior (unusual file access patterns, unexpected outbound connections)
• Include AI browser activity in your security monitoring and incident response procedures
• Review agent action logs as part of your regular security audits

4. Update your threat model.

If you're maintaining a threat model for SOC 2, ISO 27001, or your own internal security assessments, prompt injection against agentic interfaces needs to be on it. Specifically:

• Add "prompt injection via external content" as a threat vector for any system that uses AI agents
• Document what data and systems are reachable if an AI agent is compromised
• Define detection and response procedures for suspected agent hijacking
• Include AI browser permissions in your regular access reviews

5. Watch the vendor response cycle.

Perplexity patched the specific vulnerabilities Zenity Labs reported in February 2026. But the underlying architecture hasn't changed. Every new feature that gives the AI browser more agency creates new prompt injection surface. Track your AI tool vendors' security advisories the same way you track OS and library CVEs.

The Governance Gap

This research highlights a widening gap between AI capability deployment and AI security governance. Companies are shipping agentic features - AI browsers, autonomous coding assistants, email agents, meeting schedulers - at startup speed. The security boundaries for these tools are being defined after deployment, not before.

The pattern is familiar if you've been watching the AI agent identity governance space. Most organizations can't even enumerate which AI agents have access to which systems. Adding agentic browsers to that mix compounds the problem. Now you have an agent with your full user context, processing arbitrary external content, with no reliable way to prevent prompt injection.

For CTOs and security leaders, the practical question isn't whether to use AI browsers or agentic tools. The productivity gains are real. The question is how to deploy them with appropriate controls:

• Define boundaries before deployment. What can the agent access? What can it do? What requires human confirmation? Answer these before enabling the tool, not after an incident.
• Isolate agent environments. Run AI browsers in dedicated profiles or VMs that don't have access to your most sensitive systems. The mild inconvenience of switching contexts is worth the reduced blast radius.
• Build detection for agent misuse. Your SIEM should capture AI browser actions the same way it captures user actions. Anomalous file access, unexpected data exfiltration attempts, and unusual API calls from agent contexts should trigger alerts.
• Plan for the vulnerability. Prompt injection is an unsolved problem. Your security architecture needs to be resilient to agent compromise, not dependent on it never happening.

The Bigger Picture

Zenity Labs' research is one data point in a pattern. The ClawJacked vulnerability showed that AI coding agents could be hijacked through WebSocket connections. The Argus Security audit of OpenClaw found over 500 vulnerabilities. Prompt injection attacks against MCP-connected agents have been demonstrated in research settings. Each disclosure reveals the same fundamental issue: AI agents are being granted broad permissions in architectures that weren't designed for adversarial input.

The companies that navigate this well will be the ones that treat AI agent security as a first-class engineering concern - not a checkbox, not an afterthought, but a core part of the architecture. The ones that don't will be writing incident reports.

Perplexity patched the specific bugs. The architecture is still the attack surface.

Keep reading:

• AI Agents Are Identity Dark Matter - And Your IAM Stack Can't See Them
• The Agentic Architect: Running a One-Person AI Engineering Team
• Why MFA Isn't Enough Anymore: The Starkiller Phishing Service

Building agentic AI features and need help with the security architecture? Let's talk.