Agent Security Is a Systems Problem
A new paper argues that LLM agent security cannot be solved by better prompts or guardrails alone. The architecture itself leaks privilege.
A new paper on arXiv argues that securing LLM agents is fundamentally a systems design problem, not a prompt engineering or model safety problem. The authors claim most current defences focus on input filtering or output sanitisation, but miss the structural issue: agents have too much privilege by default. The core observation is that an agent with filesystem access, API keys, and shell commands is one prompt injection away from disaster. No amount of instruction tuning or red-teaming fixes that. The privilege boundary is wrong from the start. The paper proposes treating agents like operating system processes. Sandboxing, capability-based security, least privilege per task. An agent summarising emails does not need write access to your cloud infrastructure. Most deployments give it anyway because the tooling defaults to full access. This matters because every company building RAG pipelines or customer support bots is now inadvertently building a distributed system with unclear trust boundaries. The agent can read your database, call your payment API, and modify user records. One malicious document in the knowledge base can exploit that. I have seen this in detection engineering. Analysts build detections that query APIs with admin tokens because scoping permissions per query is tedious. Then someone injects a payload through a support ticket and the detection itself becomes the attack vector. The fix is not better models. It is designing agent systems with the same paranoia we apply to web servers. Assume the input is hostile. Assume the model will be tricked. Build the walls before the agent goes live.