AI agents stopped being chatbots. Production systems now combine a language model with tools: a code interpreter for math and data work, a real browser for the modern web, memory stores, and connectors into mail, calendars, clouds, and internal APIs. That combination is powerful, and it collapses decades of browser, sandbox, and identity lessons into a single confused boundary.

Black Hat USA 2026 made the risk concrete. Researchers showed credential exfiltration from managed agent platforms, interactive shells on enterprise AI assistants, agentic browsers tricked by page content, and even physical robots steered by audio/visual “prompts.” For online technical audiences, security engineers, platform owners, AppSec leads, this is the rare topic that is both brand-new and immediately operational.

Mental model: the agent is a privileged user with bad eyesight

Strip away the marketing and the “brain” is still an LLM: a statistical next-token predictor. Everything else is plumbing: tools, memory, routers, sandboxes, and identity. When that plumbing can execute code or drive a browser, the agent becomes a privileged operator that reads untrusted text as if it were policy.

Rules for Neural Traffic research reinforces a useful simplification: tools, memory, and routers wrap the model, but decisions still emerge from model completions. Defenses that only classify “toxic words” in user chat miss the real control plane, the tool-call stream and the data the model is allowed to see.

Key idea: If instructions and untrusted content share one channel (tokens), classic code/data separation does not exist. Treat every tool-using agent as a confused deputy until proven otherwise.

PHANTOM-B: a STRIDE-like checklist for the LLM slice

Adam Shostack’s PHANTOM-B white paper offers a memorable lens for “what can go wrong with the LLM parts?” Use it alongside classic STRIDE for the non-LLM infrastructure. Importantly, PHANTOM-B is designed as a set of prompts that drive specific findings, not as rigid cubbyholes that force every issue into one box.

Prompt injection , direct, indirect (documents/web/images), and multi-stage.

Hallucination , all outputs are model samples; “wrong” answers are not a special mode.

Anthropomorphization, teams over-trust “reasoning” language and under-build hard controls.

Non-explainability, decisions that need audit trails cannot rely on the model’s story about itself.

Training issues , accidental or intentional data quality problems shape behavior.

Over-reliance , letting the model expand authority quietly expands the attack surface.

Missing security engineering, SDL, threat models, and authz still apply around the model.

Biases, unacceptable for the use case even when the model “sounds fair.”

A practical exercise: for each agent workflow, write one concrete failure story per PHANTOM-B letter. Example for Over-reliance: “The agent can create IAM users because the tool was left attached from an earlier admin demo.” That sentence is more useful than a dozen abstract risk scores.

What production agents actually need, and why that is dangerous

CoreBreak framed two non-negotiable capabilities of serious agents:

1. Code interpreter , run code to compute, reshape data, and do what pure token prediction cannot.
2. Browser, render modern JavaScript-heavy sites and act like a user (click, type, navigate).

Cloud vendors productized both as managed “Agent-as-a-Service” building blocks (sessions, memory, gateways, tools, identity). That convenience concentrates risk: a break in isolation or identity wiring becomes a credentials-exfiltration path across tenants or accounts. Disclosure themes at the conference included issues against major agent harnesses and SDKs (including CVE identifiers reported in speaker materials).

When you review a vendor agent platform, ask four questions in writing: (1) What can the interpreter read on disk and in environment variables? (2) How is browser traffic isolated per tenant and per user? (3) Which identity is on outbound API calls, user-delegated, managed identity, or shared superuser? (4) Can the agent modify its own tools, memory, or hooks for persistence?

Attack narratives that matter (conceptual, not playbooks)

Interactive access beats a single leaky answer

ChatMate demonstrated that the real prize is an interactive loop over an assistant that already has enterprise context, calendar, mail, files, after sandbox boundaries fail. One research takeaway was sharp: a chat session that has ingested untrusted input is tainted and should run with reduced authority or heavy monitoring. Cloud side-effects also matter: limit host-network exposure of agent pods and treat “internal” services as if they were public.

For detection engineers, this implies new telemetry: session taint flags, tool-call graphs, and alerts when a session that summarized an external email suddenly requests mailbox-wide search or file download tools.

AI browsers reverse 30 years of browser security

Browsers gained same-origin policy, process sandboxing, CSP, site isolation, and storage partitioning over decades. Agentic browsers reintroduce a trusted summarizer/actor that reads page content and may click or exfiltrate. Indirect prompt injection (instructions hidden in pages, docs, or even images processed by vision/OCR) is the workhorse.

Defensive patterns discussed include:

• Holding tool calls in a buffer and checking them against the user’s original intent with a separate alignment model before execution.
• Dynamic tool attachment (only the tools required for the user’s stated task).
• Prompt-injection detection and content sanitization, useful layers, not silver bullets.
• Skepticism toward pure “plan-then-execute” schemes in open-ended browsing, where the environment is adversarial and dynamic.

A concrete product pattern: if the user asked “summarize this page,” the only default tool should be “read/render.” “Send email,” “export contacts,” or “run code” should require a fresh, explicit user goal, not emerge mid-summary because the page asked nicely.

Enterprise coding agents: a multi-stage dilemma

Roblox’s “Caging the Agent” talk described a chain that security teams should map for any Claude-Code-like deployment:

• Context ingestion, malicious instructions enter via repos, tickets, or docs.
• Credential discovery , the agent (or its tools) can see local secrets and env vars.
• Sandbox escape / deferred execution , later steps fire outside the original guardrails.
• Persistence, hooks or automation keep the foothold.

Their answer was multi-layer sandboxing at enterprise scale, not a single container flag. Treat coding agents as CI runners with a brain: least privilege, ephemeral credentials, network egress allowlists, and policy that blocks secret exfiltration paths by design. “Trusted Enough to Run” and related workflow talks underscore that official automation paths are attractive because they are already allowed through change management.

Physical blast radius

Kinetic Prompt Injection showed a stock robot driven by a vision/audio model stack where the camera and microphone were the only input path, no firmware implant, no stolen Wi-Fi password. When perception becomes an instruction surface, safety cases must include adversarial physical environments, not just digital content filters. This is not sci-fi for warehouses, hospitals, or security robots already piloting semi-autonomous behaviors.

Reference architecture for a safer agent

Think in four planes:

1. Perception plane, user text, retrieved docs, browser DOM, images; all untrusted by default.
2. Cognition plane , model(s); no direct network, no long-lived secrets.
3. Policy plane , schema validators, allowlists, rate limits, human approvals, alignment checks.
4. Action plane , tools with per-tool identities, audited arguments, and scoped network access.

Data should flow perception → cognition → policy → action, never cognition → production API with only a system prompt as the gate. If you need a memorable test: can a malicious PDF cause a wire transfer tool to fire without a second factor from a human? If yes, you built automation, not a safe agent.

Defensive architecture checklist

1. Separate privileges: the model proposes; a policy engine disposes. Never let raw model text become an authenticated API call without schema validation and authz checks.
2. Taint tracking for sessions: untrusted content lowers trust tier until human re-authorization.
3. Secret hygiene: inject short-lived tokens into tool sandboxes; never mount long-lived cloud keys into the interpreter filesystem the model can read.
4. Browser allowlists and confirmations for high-risk actions (email send, payment, IAM changes).
5. Independent alignment/monitoring path that cannot be disabled by the agent’s own tools.
6. Threat model with PHANTOM-B + STRIDE; red-team with indirect injection corpora, not just jailbreak prompts.
7. Log tool arguments and outcomes at a fidelity suitable for forensics, without logging secrets.
8. Red-team images and HTML comments, not only visible English sentences.

Educational synthesis for defensive awareness. Not an official Black Hat publication; omits exploit code and weaponization steps by design.