LLM agents break trust boundaries; favour deterministic controls
Perplexity’s paper says agent architectures shift security assumptions. It maps attack surfaces across tools, connectors and hosting, with indirect prompt injection, confused-deputy behaviour and workflow cascades the top risks. The authors back defence-in-depth with sandboxing and deterministic enforcement, and call for realistic benchmarks and delegation and privilege policy models.
Frontier AI agents are not just chatbots with a clipboard. Perplexity’s submission to a US standards request argues that agent architectures change the old separation between code and data, blur authority boundaries, and make execution less predictable. If you run agents in production, that translates into new ways to lose confidentiality, integrity and availability.
The paper is grounded in operating large, general-purpose agents. It charts attack surfaces across tools, connectors, hosting boundaries and multi-agent setups. The headline risks are familiar but nastier when the system accepts goals and builds workflows on the fly.
- Indirect prompt injection from retrieved content steering tool use.
- Confused-deputy behaviour across multi-agent chains and shared workspaces.
- Cascading failures in long-running, stateful workflows.
Where this bites in real infrastructure
Endpoints and browsers: Agents that read web pages or email will ingest untrusted content that can act like executable control. Treat anything the agent retrieves as hostile. Isolate the browsing and file-handling environment, strip implicit trust, and avoid giving default filesystem or credential access. Long-lived sessions and shared caches increase blast radius.
Data pipelines and retrieval: If your agent builds plans from retrieved knowledge, poisoned documents can redirect actions. The paper’s point on code-data blur is a warning: prompts and outputs become control flow. Add content sanitisation and schema checks before tool execution, version your corpora, and audit which document led to which action so that rollback is possible when a bad page sneaks in.
Tooling and model serving: Orchestrators that let models pick tools need a deterministic backstop. The authors highlight Allowlist" target="_blank" rel="noopener" class="term-link">allowlists, strict schema validation, rate limits, and explicit human approval for high-consequence actions as the only mature line that consistently holds. Keep business-logic policies out of the prompt and in code that enforces them. Log each tool call with inputs, outputs and decision rationale to support incident response.
Code execution and sandboxes: Weak sandboxes remain a primary vector. The defence stack the paper describes only works if your execution environment is actually isolated. No shared writeable volumes across tenants, no default network egress, and time-bounded runs. If you cannot explain what the agent is allowed to execute and where it can send bytes, you do not have a sandbox.
GPU clusters and serving infra: The orchestration layer is another trust boundary. Multi-tenant clusters should assume agents will try unexpected sequences and resource spikes. Apply deterministic resource limits and kill-switches at the scheduler, not just in prompts. Hosting choices matter: cloud adds network boundaries and exposure; on-prem trims internet risk but raises insider and configuration risk, as the paper notes.
Secrets and connectors: Agents chain tools, and each connector widens the blast radius. Scope tokens to the minimum action set, rotate aggressively, and keep secrets out of prompt-visible contexts. Plugin and skill supply chains are an attack surface; verify and monitor them like any third-party integration.
Controls that survive contact with production
The paper groups defences into input-level checks, model-level instruction hierarchies, sandboxed execution and deterministic enforcement. The authors are clear on maturity: the last category is what saves you at 3am. Detectors for prompt injection suffer base-rate false positives and latency costs, and model “hierarchies” are conventions, not guarantees. Use them as hygiene, not as gates.
The incident notes in the paper reinforce this: some failures are plain old application security, including a documented platform flaw and a one-click remote code execution case that did not depend on Large Language Model (LLM) behaviour. Treat the agent stack like a web app plus scheduler, then add the agentic quirks on top.
What is missing is standardisation and measurement. The authors call for realistic, adaptive security benchmarks, better delegation and privilege models for agents, and guidance for secure multi-agent design aligned with established risk frameworks. Until that lands, keep one deterministic layer between the model and anything that can spend money, move data or change state. Your pager will thank you.
Additional analysis of the original ArXiv paper