A new class of AI-powered browsers (OpenAI’s ChatGPT Atlas, Perplexity’s Comet, others) can read all the text on a page—including text you can’t see—and then take actions on your behalf. Malicious instructions hidden in that content can hijack the assistant and, through your logged-in session, reach email, banking, or cloud data. OWASP now ranks prompt injection as the #1 emerging risk for LLM apps; even OpenAI’s CISO calls it an “unsolved frontier.” This isn’t theoretical—Brave’s researchers have already shown working exploits.

What “hidden prompt injection” actually is

Hidden prompt injection embeds instructions inside web content—CSS-hidden text, HTML comments, faint text inside images, even base64 blobs—that an AI assistant reads as part of its task. Because current LLMs process “instructions + data” together, the agent can’t reliably distinguish the user’s intent from the page’s “intent,” and may obey the page instead. OWASP’s LLM Top 10 documents both direct (user-supplied) and indirect (content-supplied) variants, with likely impacts ranging from data exfiltration to unauthorized actions across connected tools.

Why agentic browsers amplify the blast radius

Agentic modes hand the model three ingredients at once: navigation tools, your authenticated cookies, and a natural-language control channel. Once an agent accepts hidden instructions from a page, classic browser defenses like same-origin policy or CORS no longer apply—the agent is acting as you. Brave’s security team showed that a single malicious Reddit comment could steer Comet to fetch a one-time passcode from Gmail and leak it off-site, all triggered by a simple “summarize this page” request. No exploit kits, no downloads—just words.

Proof points

• Comet (Perplexity). Brave’s August disclosure described “indirect prompt injection” that scripted Comet to (1) retrieve the user’s email, (2) trigger an OTP flow, (3) read the OTP in Gmail, and (4) exfiltrate it—kicked off by summarizing a booby-trapped post. Their October follow-up showed “unseeable” prompts hidden in screenshots that Comet’s OCR happily read as commands.

• Fellou & peers. The same Brave research mapped navigation-based paths in other AI browsers, again demonstrating cross-domain actions once the agent trusts page content as instructions.

• “CometJacking.” LayerX researchers documented a link-only vector where crafted URL parameters nudged Comet into consulting memory/connectors (Gmail, Calendar) and exfiltrating results—payloads encoded to slip past filters.

• Atlas (OpenAI). Independent testers pulled off benign but real prompt-injection pranks (forcing Atlas to output “Trust No AI,” change window chrome). During the Atlas launch briefing, OpenAI’s CISO, Dane Stuckey, admitted prompt injection remains a “frontier, unsolved security problem”, even with red-teaming, logged-out mode, and watch mode defenses.

What OpenAI and Perplexity say they’re doing

• OpenAI Atlas. Stuckey highlights layered mitigations: extensive red-teaming, training data tuned to ignore malicious instructions, logged-out mode (no privileged cookies), watch mode (keeps focus on sensitive sites), and additional guardrails. Yet OpenAI still frames prompt injection as an active, unsolved risk.

• Perplexity Comet. Perplexity’s security update outlines a defense-in-depth plan: prompt-injection classifiers, clearer separation between user intent and untrusted content, tool-level guardrails, and user notifications when the agent attempts risky actions. They likewise concede the problem is industry-wide and ongoing.

The stakes for companies and government

• Security. Hidden prompts let a third-party page steer an agent carrying your identity, bypassing human judgment and traditional browser boundaries. That’s a novel cross-site risk class.

• Governance. OWASP’s LLM Top 10 now places prompt injection at LLM01; their guidance stresses separating trusted instructions from untrusted content, enforcing least privilege, and keeping humans in the loop.

• Public trust. Vendors are disclosing mitigations, but the consensus—including from those shipping these products—is cautious: treat agentic browsing as dangerous until enforceable controls exist.

What to do now (practical, layered playbook)

For individuals & teams

1. Isolate sessions. Separate profile/VM (don’t try it on your corporate work laptop); keep sensitive accounts logged out when using agent features.

2. Least privilege. Don’t grant file system, email, or cloud-drive access unless essential; disable auto-actions.

3. Require approvals. Manual confirm for any cross-site/account action; prefer watch/confirm modes.

4. Assume hostile content. Avoid summarizing user-generated pages/screenshots while logged into sensitive services.

5. Harden identities. Use phishing-resistant MFA; monitor sessions; rotate credentials if you previously enabled connectors.

6. Track patches. Follow Brave/OpenAI/Perplexity advisories; update aggressively.

For developers building with agents

• Separate roles. Never merge user intent and page content into one prompt. Treat page content as untrusted; validate actions against stated goals.

• Constrain capabilities. Origin-scoped cookies, per-site creds, time-boxed tokens; human-in-the-loop for money/email/data edits.

• Filter in & out. Detect hidden/encoded prompts (CSS spans, HTML comments, base64, Unicode tricks). Use output policy checks to block cross-origin/out-of-scope actions.

• Design for failure. Log tool calls; add kill-switches and safe defaults; surface what the agent plans before it acts.

Agentic browsing is promising—and not ready for interesting work. Evidence shows hidden prompts can still steer assistants beyond the user’s intent, and long-standing web boundaries cannot contain the blast radius once the agent acts with your identity. Until the ecosystem matures, run agentic browsers with strict isolation and least privilege. Treat every page as untrusted input, because that is what it is. As OpenAI’s CISO put it, prompt injection remains a “frontier, unsolved” problem;

In short, lots of people are trying and they love vibe coding. You type, hit Enter, and watch your codebase materialize. It's fast, it's seductive, and it feels incredibly productive.

But here's the catch—it's also a trap.

The Trap: Illusion vs. Reality

AI-generated code isn't inherently problematic. In fact, it’s impressively capable. What’s dangerous is its uncanny ability to fool you into thinking you're fully in control, when in reality, you're often just approving confident-sounding spaghetti code.

Tools like Cursor and Claude deliver functionality rapidly, but they lack genuine understanding. They replicate patterns they've seen but can't truly invent or innovate. As a result, you might find yourself stuck debugging code nobody truly understands—including the AI that wrote it.

Additionally, vibe coding can inadvertently introduce security vulnerabilities, as AI-generated code often neglects critical security considerations, potentially leaving applications exposed to breaches.

Grounded Approach: How to Use AI

Despite these risks, AI tools are undeniably powerful when used thoughtfully. In my experience, they're fantastic for:

• Proof-of-concept work

• Developing small components in unfamiliar languages

• Understanding new concepts from existing codebases

The secret is to never fully outsource your critical thinking to AI. Every line of AI-generated code must pass rigorous review. You must understand the underlying logic, the potential pitfalls, and the architectural implications.

The introduction of these AI tools also signals a shift in what it means to be a software engineer. Specialization in a single domain like frontend or iOS is no longer sufficient. Developers need broader awareness—spanning APIs, backend infrastructure, networking, operating systems, and even hardware. AI demands greater breadth of knowledge, not less.

Programmers Are Not Going Anywhere

The recent attempted acquisition of Windsurf, a startup claiming "fully autonomous software development," is a prime example of why human developers remain relevant.

Instead, the reality is clear: AI tools are great copilots. They enhance your productivity but also heighten the need for judgment, responsibility, and comprehensive understanding across the tech stack.

Ultimately, vibe coding feels great, but only if you remember to keep your feet firmly planted on the ground—and your eyes wide open.

DeepSeek positions R1 as a competitor to other large language models, similar to OpenAI’s “o1.” I won’t dive into the nitty-gritty of how DeepSeek R1 was built (that’d be a longer read), but if you’re curious to try it out on your own machine—especially for privacy or experimentation reasons—read on.

Why Run DeepSeek R1 Locally?

1. No Rate Limits: No messing around with API quotas or billing.

2. Privacy: Your queries stay on your own hardware.

3. Experimentation: Tweak and test to your heart’s content without needing a server connection.

Why Distilled?

Right off the bat, I’m using a distilled version of DeepSeek R1. Why? Because the full-blown 671B-parameter model needs 6 NVIDIA A100 80GB GPUs (and for the “real deal,” you might need up to 16 of those monsters). With each A100 going for 17k–20k USD, that’s roughly 100k–120k in GPU gear alone—so you’re practically flirting with the cost of a nice house down payment just to run the original. Yeah… maybe next time.

Step 1: Install Ollama

Head to ollama.com and download the installer for macOS, Linux or Windows.

Step 2: Pull the DeepSeek R1 Model

DeepSeek R1 is huge, so if you’re on a laptop, you will run a distilled model (more on that in a second).

ollama run deepseek-r1:8b

If you haven’t got it locally, Ollama will download it for you (my download stalled a few times, but re-running picked up where it left off).

Smaller models typically run faster—and play nicer with laptops like my M1 Pro MacBook (32GB RAM). You can find a complete list of distilled models and their requirements here. But basically, the bigger, the better AI.

# Full model (requires significant resources)
ollama run deepseek-r1:671b

# Distilled models (more practical for local use)
ollama run deepseek-r1:1.5b  # DeepSeek-R1-Distill-Qwen-1.5B
ollama run deepseek-r1:7b    # DeepSeek-R1-Distill-Qwen-7B
ollama run deepseek-r1:8b    # DeepSeek-R1-Distill-Llama-8B
ollama run deepseek-r1:14b   # DeepSeek-R1-Distill-Qwen-14B
ollama run deepseek-r1:32b   # DeepSeek-R1-Distill-Qwen-32B
ollama run deepseek-r1:70b   # DeepSeek-R1-Distill-Llama-70B

Step 3: Open Web UI

For the Web Chat GUI you’ll need Docker running, then pop open a terminal and run:

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Once that finishes, head to

http://localhost:3000

in your browser to interact with DeepSeek’s model. Everything stays on your machine: no surprise rate limits, no prying eyes on your prompts.

DeepSeek R1 (distilled versions, at least) is a fun playground for tech/AI enthusiasts who want to tinker locally. It’s not going to beat the absolutely massive GPUs-and-jet-fuel version, but it’s a heck of a lot cheaper than shelling out 100k on hardware.

If you’ve been itching to test out a local LLM, do yourself a favor and give DeepSeek R1 distills a whirl. No HPC cluster required, no eye-watering GPU budget—and still plenty of stuff under the hood.

Thanks for reading my first post here. We’re all just figuring this stuff out. Cheers!