Veteran digital-rights advocate Danny O'Brien argues that today's AI security crisis is, at root, a social engineering crisis — for people and for large language models — in a November 11, 2026 Oblomovka essay that spread through security circles the next day.
His piece lands while maintainers are drowning in AI-assisted vulnerability reports (VulnCheck's November Glasswing update) and while agent harnesses connect models to shells, browsers, and payment rails. If injection is socially engineered persuasion, then tool privilege and human approval habits matter as much as the next safety fine-tune.
TL;DR
| Question | Short answer |
|---|---|
| What is new? | O'Brien's essay, not a product launch — a framing piece tying Vulnpocalypse-era discovery to prompt injection and capability security. |
| Core claim | Attackers smuggle instructions into trusted channels; models obey like humans obey fake managers on support calls. |
| Technical fix he highlights | Capability-based security (CHERI, Capsicum, WASI, OCapN) to stop confused-deputy abuse. |
| What it does not fix | Humans approving OAuth, pasting secrets, or trusting the wrong email — the original social engineering target. |
| Builder takeaway | Treat untrusted text like untrusted people: separate channels, least-privilege tools, execution monitors. |
What O'Brien published
Illustration from the November 2026 Oblomovka essay on AI security and social engineering
Image: Oblomovka
O'Brien writes from a long arc in civil-liberty technology: he held several leadership roles at the Electronic Frontier Foundation from the mid-2000s through 2021, alongside colleague Peter Eckersley, who co-created Privacy Badger and Let's Encrypt before his death in 2022. O'Brien left EFF in 2021 to focus on capability-based security advocacy and now backs Spritely Institute work on object capabilities and the OCapN networking layer.
In the November essay he makes four linked moves:
- Recall Peter Eckersley's prediction that near-superintelligent systems would scour the ecosystem for exploitable flaws — a prediction O'Brien says arrived with the 2026 AI-driven vulnerability wave he nicknames ongoing tribulation after prior "Black October" reporting.
- Name prompt injection as a new failure mode where instructions hide inside content the model must read.
- Compare injection to human social engineering — fake urgency, impersonated authority, slow trust expansion — arguing LLMs re-learn the same tricks on silicon.
- Pitch capability-based security as necessary but not sufficient: it limits software blast radius; humans still need better process.
The essay is opinionated infrastructure politics, not a peer-reviewed paper. It is still primary text for what O'Brien believes builders should prioritize.
Social engineering for humans, replayed on models
Classic social engineering tricks humans into misusing legitimate access: a caller plays a crying baby to rush a technician, a phisher poses as an executive, a fraudster claims to be the victim's bank.
Agent permission boundary metaphor for prompt injection social engineering defenses
Indirect prompt injection replays the pattern for agents:
- The model must read email, web pages, tickets, or PDFs to be useful.
- An attacker embeds instructions in that content: exfiltrate data, run a shell command, approve a refund.
- The harness treats model-chosen tool calls as authorized because the session already holds API keys.
O'Brien's line — "prompt injection is the art of social engineering silicon" — matches how security researchers describe confused deputy problems in MCP deployments: the agent is the deputy; the injection is the social script.
Meta's Muse agent stack, covered in our Sentinel VM launch write-up, independently points toward deterministic policy checks outside the model — the same architectural instinct O'Brien voices from a capability-security tradition.
Agents that act on your behalf need rules. See how explainx helps secure your agents →
The vulnerability-discovery wave is the other half
O'Brien opens with AI-accelerated bug discovery, not injection alone. That matches measurable 2026 news:
- Anthropic Project Glasswing and partner scanners flooded maintainers with findings; VulnCheck tracked hundreds of credited CVEs but a low ledger fix rate and heavy duplicate volume.
- Maintainers across curl, PostgreSQL, and other core packages report bulk AI scanner queues — useful for defense, noisy for triage.
O'Brien's optimism — that AI may help rebuild safer systems — does not contradict the triage crisis. It says defenders should use discovery throughput to fund deeper architectural moves, not only patch queues.
For agents, the lesson is parallel: faster bug finding in dependencies does not remove your prompt-injection surface. If your coding agent installs packages or hits APIs, you inherit both trends.
Capability-based security in plain language
Capability-based security grants each program a minimal set of keys instead of the user's full master keyring.
O'Brien cites real projects:
| Layer | Examples he names | What they try to do |
|---|---|---|
| CPU / hardware | CHERI (Cambridge, ARM collaborations) | Pointer bounds and permissions in hardware |
| OS experiments | Google Fuchsia, FreeBSD Capsicum | Capabilities as default process rights |
| Serialization | Cap'n Proto (Kenton Varda) | Capability-friendly object passing |
| Edge compute | Cloudflare Workers | Isolated, limited APIs per worker |
| Decentralized stack | Spritely / OCapN | Object-capability networking in free software |
Narrow tool scope as capability-based security for AI agents
The valet-key metaphor in the essay is the confused-deputy antidote: even if an attacker sweet-talks the program, the program cannot open capabilities it never held.
Readers who run agents on full-user laptops today are far from this world. Most harnesses inherit user-grade shell, filesystem, and browser rights — the opposite of valet keys.
Our Bedrock AgentCore hijack analysis shows the confused-deputy shape in cloud agents: SSRF-like tool abuse when networks are not segmented. Capability thinking says: the weather tool should not carry credentials that reach internal admin APIs.
What capability security cannot solve alone
O'Brien ends with a blunt split:
- Capabilities stop software from exceeding its ticketed authority when tricked.
- Humans still authorize OAuth consent, MCP installs, and "run this script" prompts.
That mirrors 2026 operational incidents:
- United Airlines moved against third-party booking agents — a business response to untrusted automation in customer channels.
- Claude Cage and similar sandboxes narrow network and filesystem reach for coding agents — partial capability thinking without rewriting the OS.
No single vendor ships O'Brien's full greenfield vision tomorrow. Builders can still approximate capabilities in harness design.
Practical moves for agent builders
Think in two audiences — the model and the human operator — because O'Brien's essay treats both as social-engineering targets.
For the model and harness
- Separate trusted system prompts from untrusted retrieval. Fetch web and mail into labeled blocks; never let untrusted text rewrite system instructions without a human gate.
- Default tools to read-only. Add write, shell, and payment tools only with scoped tokens — the MCP security guide checklist is the starting point.
- Enforce execution-time policy. Classifiers and deterministic checks outside the model — the pattern Meta describes for Muse and researchers discuss under names like capability-aware prompt isolation — belong before irreversible actions.
- Log and alert on tool escalation. If a session that only queried files suddenly requests a refund API, treat it as you would a staff laptop calling payroll at 3 a.m.
For the human operator
- Treat agent consent screens like bank MFA. Read scopes; reject broad "full account" grants.
- Rotate keys when an agent read untrusted repos. Supply-chain and typo-squatting risks rise when agents browse freely; our November 2026 attack tracker lists recent agent-adjacent incidents to watch.
- Run high-risk flows in disposable environments — VMs, dedicated cloud accounts, no corporate SSO on the same profile.
How to protect yourself and your stack
O'Brien's essay is not a product manual, but the protection section for readers shipping agents is straightforward:
- Assume injection will eventually succeed in any harness that reads the open web or shared documents.
- Shrink blast radius with least-privilege tools, network isolation, and human approval for spend or data export.
- Monitor execution, not only prompts — post-hoc transcript review misses fast tool loops.
For teams that want execution-time blocking when an agent attempts a dangerous command or exfiltration path, AgentBeam — the agent security platform from the explainx.ai team — sits in that layer: it evaluates tool calls before they run, complementary to capability-style scoping.
Pair tooling with process: security training already teaches staff not to wire-transfer on a phone call; agent operators need the same skepticism when a model "urgently" asks to disable a guardrail.
What skeptics and optimists both get right
Skeptics say framing injection as social engineering risks understating formal undefinability results and the lack of a patch for "the model read English." Fair — metaphors are not proofs.
Optimists say the framing unblocks policy: CISOs already fund anti-phishing; agents inherit that budget line. O'Brien's capability pitch gives architects a multi-year roadmap (CHERI hardware, WASM sandboxes, OCapN federation) instead of waiting for a single magic safety model.
explainx.ai's read: use the metaphor operationally, invest in valet-key tool design now, and track hardware and OS capability projects as they mature — without pretending humans leave the attack surface.
Related reading
- What is indirect prompt injection? — untrusted content in agent loops
- MCP Security Guide (2026) — confused deputy, scopes, logging
- VulnCheck Glasswing November ledger — AI CVE volume versus fixes
- Meta Muse Sentinel VM security stack — deterministic checks outside the model
- United Airlines blocks third-party booking agents — business pushback on untrusted automation
- Claude Cage VM sandbox for Claude Code — network isolation pattern
Security framing and third-party project status are accurate as of November 12, 2026.