AGENT-SECURITY RESEARCH

We read the source. We counted the blast radius.

An honest audit of how much action-surface the ten most popular open-source agent frameworks expose by default. Shell, code execution, file writes, a logged-in browser. We verified every finding at the source — and we share the file-level specifics privately with each team first. If we’ve mis-read your framework, tell us and we’ll fix it in the open.

iResponsible disclosure: the exact files and lines are held out of this public report and shared privately with each team named here. This shows the shape of the problem, not an exploit — and it credits the teams already hardening their defaults.
10Frameworks source-readMOST-STARRED, PUBLIC SOURCE
4Act on the host by defaultUNSANDBOXED, NO APPROVAL GATE
10/10Verified at the sourceSPECIFICS SHARED WITH EACH TEAM
770k+Combined GitHub starsAS OF 2026-07-05
A big action surface is not a bug. An agent that cannot act is a chatbot. The signal is which teams have started gating that action layer — and which have not.

Agents don’t just answer any more. They run shell commands, execute generated code, write files and drive authenticated browsers. That action layer is where untrusted input sits one hop from a real send, pay, write or exec. We wanted to know how big that surface actually is across the frameworks builders reach for, so we read the executor code of ten of them and counted only concrete affordances we verified at the source. This is that count. It exists because the risk in agents is not the model getting fooled. It is what the agent is allowed to do next.

Ranked by dangerous default surface

“Dangerous by default” means the shipped default path reaches the host or a live session unsandboxed, with no approval gate — not what is merely possible with configuration.

#FrameworkStarsSurfacesDefault postureDefault action pattern
1gpt-engineer55.2k2Host, ungatedruns model-written code on the host by default, without a sandbox or approval gate.
2MetaGPT69.2k4Host, ungatedin-process code execution plus a host shell command, on in the default path.
3LangChain141kshell + broadBroad surfacea live shell tool and the broadest overall tool surface (HTTP, file, DB). Its raw-exec Python REPL was removed for safety.
4AutoGPT185k4Gatedseveral exec paths, but Docker by default and host shell only if opted in.
5AutoGen59.5k3Gatedlocal code execution, but ships a dangerous-command sanitiser and a Docker/cloud alternative.
6browser-use103k~10Live sessiondrives a real logged-in browser — click, navigate, upload. A poisoned page sits one hop from a real action.
7crewAI55k3Mixedfile write to a model-supplied path; its code-exec tooling leans sandboxed.
8LlamaIndex50.7k1Opt-ina subprocess code interpreter the maintainers themselves flag as not for production.
9OpenAI Agents SDK27.7k3Sandboxedshell bound to a sandboxed, scoped session, with a human-in-the-loop example in the repo. Safest of the shell-capable set.
10Semantic Kernel28.3k1Off-hostPython execution runs off-host in a remote pool — no local host exec.

Counts are verified lower bounds from the primary executor and tool files. A framework’s true surface is at least what we describe here.

What we measured, and what we did not

We verified each repository via the GitHub API, located the real executor code, and read the source. We counted only concrete affordances that carry an agent from thinking to doing — shell and subprocess exec, code eval, file writes, a live authenticated browser. We are not scoring code quality, and this is not a scoreboard of shame. It is a point-in-time reading of shipped defaults, correctable in the open.

The honest part

A big action surface is not a flaw. An agent that cannot act is a chatbot. The interesting signal is not who has a surface, but who has already started securing it — and several of these teams visibly are. LangChain pulled its raw exec REPL. AutoGPT and AutoGen default to Docker. OpenAI binds shell to a sandbox. Semantic Kernel runs code off-host. Credit where it is due.

Why one shared layer

Every team here is doing per-framework what should exist once, as a layer. A consistent control point in front of every dangerous action, whichever framework a builder picked. Untrusted input is one hop from a real send or pay. That control point is what Hermes Shield builds.

Your agent has this surface too.

Whichever framework you built on, your agent can reach tools that untrusted text can trigger. We’re building the shared control point that sits in front of those actions, and letting builders in slowly. Register interest and we’ll bring you in as it opens.

Register Interest

Method date 2026-07-05. Star counts via the GitHub REST API, same date. Read-only analysis of public source. Findings are point-in-time; frameworks evolve. Framework names are third-party marks, cited neutrally, not an endorsement. Corrections welcome — if we’ve mis-cited your framework, tell us and we’ll fix it in the open.

Agent Framework Attack-Surface Report — Hermes Shield