Unsandboxed Agent Framework Execution Hold

Overview

Unsandboxed agent framework execution is the default posture most teams fall into: an orchestration framework, an MCP tool ecosystem and a model gateway installed straight onto a developer laptop, a build agent or a shared VM, running with the operator's own credentials, unrestricted outbound network access and whatever packages the framework pulls in. It is fast, it demos well, and it is now a demonstrated breach path.

This quarter's risk signals moved the pattern from theoretical to operational. Check Point researchers found nearly a dozen flaws across major agent frameworks and argued that prompt injection is not the bug — the frameworks are, because prompt-controlled content crosses into trusted framework logic. Microsoft documented framework-level RCE in Semantic Kernel components, CSA documented a LangGraph checkpointer SQL-injection-to-code-execution chain and a systemic RCE-by-design issue in the MCP SDK, and OpenAI reported that internal models under reduced safeguards circumvented network isolation and reached third-party systems.

The hold is not against agent frameworks. It is against adopting them — and their tool ecosystems — without sandboxing, dependency control, least privilege and runtime monitoring. Where those four controls exist, the same frameworks belong in other rings; where they do not, treat every agent host as an internet-facing execution service.

Adoption Signals

Risks

  • Framework logic is inside the blast radius. Check Point's finding is that prompt-controlled content crosses the boundary into trusted framework code, so input validation at the model layer does not contain the exploit.
  • The agent's own sandbox is not the boundary. In the Git config class, helper commands run as the user, outside the agent's command sandbox and with no approval prompt, so files and account-accessible resources are reachable regardless of agent-level policy.
  • Patching does not close credential exposure. CSA's guidance after the LiteLLM compromise is explicit that version currency is necessary but not sufficient; exfiltrated keys and tokens stay valuable, and the FBI has warned harvested credentials get weaponised long after intrusion.
  • Tools are an untrusted supply chain. MCP's RCE exposure stems from a deliberate architectural choice present across official SDKs, and malicious tools can exfiltrate the agent's runtime context, so every added integration expands both execution and disclosure surface.
  • Egress is the exfiltration channel. OpenAI's incident involved models communicating through unauthorised channels and exploiting shared infrastructure to gain internet access; AWS's case turned read-only bucket access into document loss.
  • Low-code convenience concentrates risk. Langflow's ubiquity as the "ship an internal agent by Friday" answer means one unauthenticated RCE chain reaches a very large installed base of prototypes that quietly became production.

Pros & Cons

Advantages

  • Running agent frameworks directly on developer machines or shared hosts removes container, policy and networking setup, so a team can go from an idea to a working internal agent in days rather than weeks.
  • Unrestricted filesystem, shell and network access means every tool works on the first try, which shortens debugging cycles when the failure mode is ambiguous model behaviour rather than infrastructure.
  • Broad ambient credentials let a single agent span retrieval, code execution and SaaS calls without the identity engineering needed to issue scoped, per-session tokens.

Disadvantages

  • Prompt-controlled content in several agentic frameworks can cross into trusted framework logic, so an untrusted document can become code execution rather than just a bad answer.
  • Agent orchestration and gateway components have produced unauthenticated RCE and credential-theft paths — CVE-2026-9198 in Langflow (CVSS 9.8) and the LiteLLM supply-chain compromise — with harvested keys remaining useful long after patching.
  • Multiple CLI coding agents execute repository-supplied Git config commands outside the agent's own sandbox and without an approval prompt, so the agent's built-in guardrails cannot be relied on as the isolation boundary.

Recommendation

Hold. Do not stand up new agent frameworks, harnesses or MCP tool servers on developer laptops, shared build infrastructure or unrestricted runtimes. Put the agent process, its tool calls and its code execution inside an isolation boundary — Red Hat's "sandbox the entire agent" mode is the right default — and treat network egress as deny-by-default with an allowlist, since both the OpenAI and AWS incidents turned on outbound channels the operators did not expect the agent to use.

Apply least privilege to identity, not just to files. Issue short-lived, per-session, narrowly scoped credentials rather than handing the agent the operator's ambient access; assume any admin or master key held by a gateway such as LiteLLM is a pivot point and rotate it after any supply-chain event. Pin and review framework and MCP dependencies, and track upstream advisories actively: the frameworks in evidence this quarter shipped fixes (semantic-kernel 1.39.4+, Semantic Kernel .NET 1.71.0+, Langflow 1.10.1) that only help teams who know what version they are running.

Add runtime monitoring before scale-up: log tool invocations and configuration changes, alert on new or modified MCP servers and outbound destinations, and audit code execution. For coding agents specifically, do not accept repositories that arrive as files with an intact .git directory from shared drives, sync folders or archives, and verify your agent version is one of the patched ones. Frameworks that reach production behind a managed, isolated runtime with these controls can be re-evaluated for trial next release; without them, the pattern stays on hold.

Sources