Agent Security Is a Systems Problem: From Prompt Injection to Runtime Control

A major 2026 survey of LLM-agent security reaches a conclusion enterprise teams should take seriously: once a model can use tools, retain state, and act on behalf of someone else, security is no longer mainly a prompt-filtering problem. It becomes a systems problem spanning information flow, delegated authority, and persistent state.

1. Why Agent Security Is Different From LLM Safety

The survey starts from a simple architectural fact: an LLM agent does more than generate text. It may plan, invoke tools, browse, execute code, update state, and coordinate with other agents. Those capabilities turn model outputs into inputs to software control flow.

That changes the failure mode. A malicious instruction hidden in a web page can influence a later tool call. A poisoned tool result can become context for another decision. A compromised memory entry can survive the original session. A delegated credential can turn a bad plan into a real side effect. In a multi-agent system, the same contaminated information may propagate beyond the agent that first encountered it.

The survey therefore frames agent security around three interacting properties:

The useful implication is that secure-agent architecture should not ask only, “Did we block the malicious prompt?” It should also ask: what could that content influence, what authority could the resulting trajectory exercise, and what state could the trajectory leave behind?

2. The Attack Surface Runs Through the Whole Agent Lifecycle

Ling and coauthors use a lifecycle-based, systems-oriented framework rather than a flat list of attack names. Operationally, it is useful to separate the core action path—input, planning, decision, tool execution, and output—from cross-cutting surfaces such as memory, monitoring, and multi-agent coordination, because those surfaces can influence or observe multiple stages of the run.

This lifecycle perspective also explains why defenses can be “weakly compositional,” as the survey puts it. A content filter may block one class of malicious text but do nothing about over-privileged credentials. A sandbox may contain code execution but not prevent an authorized API call. An approval gate may stop one side effect but not a poisoned memory write. A trace may make an incident observable without preventing it.

Security therefore emerges from the composition of boundaries, privileges, state controls, and evidence.

3. Mapping the Survey to TrueForge and TrueFoundry

The cleanest product mapping is not “TrueFoundry solves agent security.” It is to ask which part of the survey's systems model each layer can realistically govern.

‍

‍