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.

4. Information Flow: Treat External Context as Untrusted Data—and Preserve Provenance

One of the survey's most important reframings is that prompt injection is an information-flow problem. The dangerous instruction may come from a user, but it may just as easily come from a retrieved document, a web page, a tool response, another agent, or a persistent memory entry.

That means the architecture should distinguish where information came from from what the model infers it means, and preserve provenance where that distinction matters downstream.

TrueForge: make the runtime boundary explicit

TrueForge is an open-source agent harness that provides the model/tool loop, context management, sandboxing, approvals, sessions, and events. Its sandbox-as-tool design is particularly relevant to the survey's trust-boundary argument: the agent loop and model/MCP credentials remain in the harness, while code, files, and shell execution happen in an isolated environment provisioned when needed.

This is a useful separation of concerns. The sandbox can be treated as a lower-trust execution surface without also becoming the store of agent credentials or conversational authority.

MCP Gateway: inspect and govern the tool boundary

TrueFoundry MCP Gateway adds a shared boundary between agents and enterprise tools. Current documentation describes centralized registry and discovery, OAuth/token management, server/tool access control, pre- and post-tool guardrails, approval workflows, and request/response auditability for traffic routed through the Gateway.

That matters because a tool result is not merely data. It can become new context that influences subsequent planning. Post-tool inspection therefore has a different role from pre-tool authorization: one controls whether the tool may run; the other can inspect what information comes back into the agent loop.

5. Delegated Authority: Least Privilege: Keep Agent Authority No Broader Than the Task Requires

The survey's second axis is delegated authority. Agent systems are risky not only because models can be manipulated, but because a manipulated model may be holding real authority on behalf of a user, team, application, or service.

This is where least privilege needs to become an architectural property rather than a prompt instruction.

The most important design principle is that these controls answer different questions. Authorization says whether an actor may use a capability. Guardrails constrain requests or results. HITL inserts human judgment at a selected moment. Budget and rate limits constrain economic and operational authority. None is a substitute for the others.

6. Persistent State: A Security Surface That Outlives the Prompt

The survey highlights persistent-state corruption as an emerging concern. That matters because agents increasingly outlive a single prompt or HTTP request. They preserve conversations, files, memory, summaries, tool results, plans, and sometimes learned preferences across long workflows.

TrueForge's SDK makes this runtime state legible through an explicit hierarchy of Agent → Session → Turn → Event → Delta. Sessions can survive reconnects and restarts, turns chain within a session, and events expose what the runtime is doing—including MCP initialization, model messages, tool responses, approval requirements, and turn completion.

That is valuable for security because it gives operators an inspectable history. But observability should not be confused with provenance guarantees.

This is especially important when a system compacts context. A summary can be operationally useful without preserving every trust-relevant detail. Teams should decide deliberately which provenance fields must survive compaction, memory promotion, and cross-agent transfer.

7. Multi-Agent Systems Turn Local Compromise Into Propagation Risk

The survey identifies multi-agent propagation as a growing research concern. Once agents exchange messages, delegate work, or call one another, a compromised output can become another agent's trusted input.

At that point, the relevant security question is not merely “is Agent A safe?” It is:

• Which agents may invoke Agent A?
• Which agents may Agent A invoke?
• What identity travels with a delegation?
• Which user or service is ultimately represented?
• Which tools and data remain reachable after delegation?
• How does trace context survive across the chain?

TrueFoundry's Agent Registry currently documents verifiable agent identity, ownership, collaborator-based access control, and routing for registered agents. Broader Agent Gateway and observability surfaces can add quotas, budgets, and centralized tracing for routed agent traffic. The Registry documentation also exposes identity-provider-backed mappings, but the dedicated On-Behalf-Of delegation workflow is still explicitly marked Coming Soon; this article therefore does not treat full OBO exchange semantics as generally available today.

But the same boundary remains important: an agent registry does not determine the application's workflow topology, and agent-to-agent connectivity is not automatically safe simply because the peers are registered. Authorization and delegation policy still have to constrain the graph.

8. Why “Defense in Depth” Is Not Enough Unless the Defenses Compose

Security teams often say “defense in depth,” but the survey's weak-composability finding points to a harder requirement: the defenses must agree on the same trust and authority model.

For example:

• A sandbox may isolate code, while an over-privileged MCP credential still allows a destructive remote API call.
• A gateway may block an unauthorized tool, while poisoned session state still changes which authorized tool the agent chooses.
• A human approval may validate an action, while the underlying arguments change before execution unless the approval is bound to the actual request.
• A trace may record every call, while downstream audit logs are still required to prove what the system of record actually changed.

A better operating model is to treat every consequential edge in the agent system as having four questions:

This is where TrueForge and the TrueFoundry Gateways are complementary. The harness governs execution inside the agent loop. Gateways centralize policy on model, tool, and agent traffic intentionally routed through them. Systems of record retain authority over the final business side effect.

9. Security Evaluation Has to Look Like Production

The survey's final warning is methodological: existing benchmarks still underrepresent long-horizon, stateful, and deployment-sensitive risks. That means a one-turn jailbreak test is not enough evidence that an agent is safe to operate for hours, retain state, use tools, or coordinate with peers.

A production-oriented security evaluation should vary more than the prompt. It should test:

• indirect instructions arriving through tools and retrieved content;
• state poisoning that becomes relevant several turns later;
• credential and permission boundaries under realistic identities;
• approval expiry, retries, and resume behavior;
• sandbox escape assumptions and out-of-sandbox tool authority;
• multi-agent propagation and delegation depth;
• model/provider changes and fallback routes;
• trace completeness across harness, gateway, and downstream systems.

For agent security evaluations, runtime configuration, tool topology, persistent state, identity, and mediation policy are part of the evaluated system—not incidental implementation details.

10. What TrueForge and TrueFoundry Do—and Do Not—Claim

The survey is useful precisely because it discourages silver-bullet thinking. The same should apply to product architecture.

The strongest architecture is therefore not “put a gateway in front of the agent.” It is a set of explicit trust boundaries whose responsibilities are narrow enough to reason about and whose evidence can be correlated after the fact.

11. The Practical Security Review

If those questions cannot be answered, the problem is not that the organization needs one more prompt filter. It needs a clearer agent security architecture.

References

• Yuchen Ling, Shengcheng Yu, Zhenyu Chen, and Chunrong Fang. Toward Secure LLM Agents: Threat Surfaces, Attacks, Defenses, and Evaluation (2026; v2 August 23, 2026). Survey of 247 papers and primary source for the security framework used in this article.
• TrueForge — Introduction. Current documentation for the open-source agent harness, execution loop, approvals, context management, persistent sessions, and sandbox-as-tool model.
• TrueForge — Setup Sandbox. Current documentation for sandbox isolation, on-demand provisioning, and keeping model/MCP credentials in the harness.
• TrueForge — SDK Concepts. Current Agent → Session → Turn → Event → Delta runtime model.
• TrueFoundry — AI Gateway. Current documentation for model access, routing, rate limits, budgets, guardrails, and observability.
• TrueFoundry — MCP Gateway. Current documentation for MCP registry, authentication, token management, tool access, guardrails, approvals, and audit.
• TrueFoundry — Agent Registry. Current documentation for registering agents, establishing identity and ownership, collaborator-based access control, routing, and agent tokens.
• TrueFoundry — Agent Gateway. Current public product surface for agent-level quotas/budgets, access controls, and execution tracing.
• TrueFoundry — Agent Identity and Delegation. Planned On-Behalf-Of delegation workflow; the page is explicitly marked Coming Soon.

Product behavior is described from current public TrueForge and TrueFoundry documentation as of August 28, 2026. The survey's taxonomy and research findings are attributed to its authors. The product mapping and architecture recommendations are TrueFoundry editorial analysis and should not be read as claims made or endorsed by the survey authors.

‍

‍

‍

‍