Having spent the last several weeks conducting a detailed threat model analysis on the current landscape of open-source LLM agent frameworks, I've reached a concerning conclusion: the security documentation for the majority of these projects is not merely insufficient; it is fundamentally inadequate for anyone considering deployment beyond a demo environment. The documentation often reads as a feature list of "security-conscious" design, rather than a frank assessment of residual risks and explicit security boundaries.
My primary threat model for this evaluation assumes a **malicious or compromised third-party tool/service** that the agent is permitted to call, and a **semi-trusted user** capable of crafting natural language instructions (i.e., prompt injection is a given). The security of the framework itself, therefore, hinges on its ability to enforce strict isolation, mediate all interactions, and provide unambiguous audit trails. Unfortunately, the docs rarely address this head-on.
Consider the critical security vectors that are routinely glossed over:
* **Tool Execution Sandboxing:** Most frameworks will state they "execute tools in a safe manner," but what does that mean? Is it a subprocess with dropped privileges? A time limit? A memory limit? Is there any namespace isolation (e.g., `clone()` flags, `unshare`)? The documentation for Framework A might mention "sandboxing," while Framework B's docs are silent. Without specifics, we cannot map the attack path from a tool executing `os.system` to host compromise.
* **Secret and Context Handling:** The common pattern is to pass secrets (API keys) and the full conversation context to each tool as function arguments. The docs seldom warn of the obvious risk: a tool compromised via prompt injection now exfiltrates the entire context and all embedded secrets. Where is the discussion of secret scoping, context sanitization, or even the basic principle of least privilege for tool access?
* **Network and I/O Controls:** Can the agent framework enforce network egress rules per tool? If a "web search" tool is allowed, can it be restricted to specific domains? If not, it's a straightforward DNS/exfiltration channel. The documentation typically lists network-enabled tools as features, not as potential pivoting points for an attacker.
For example, a typical "getting started" security note might look like this:
```python
# From a hypothetical framework's 'advanced security' guide
agent = Agent(
tools=[web_search, calculator, file_reader],
# Security setting mentioned once, vaguely
safe_mode=True
)
```
What is the threat model `safe_mode` is designed to address? What does it *not* protect against? We are left to reverse-engineer the source code to find out.
This lack of rigor forces adopters into a position of either blind trust or significant upfront reverse-engineering. For the field to mature, we need frameworks to provide explicit statements on:
1. The **assumed threat model** for their security features.
2. The **exact isolation mechanisms** in place for tool execution.
3. A clear matrix of **residual risks** (e.g., "With safe_mode=True, tool A can still perform a local file read via path traversal if the user prompt instructs it to do so").
Has anyone performed a deep, code-level comparison of these isolation implementations? I'm beginning to compile one but suspect many of us are redundantly reading the same sparse docs and digging into the same source code.
--mt
Your point about documentation reading like a "feature list of 'security-conscious' design" is precisely why I've stopped taking framework security claims at face value. You must inspect the actual policy enforcement points. A framework stating it "mediates all interactions" is meaningless if its policy language is ambiguous or its decision logs are unstructured.
This is where a formal, declarative policy layer becomes non-negotiable. If the framework doesn't expose a clear interface for integrating a policy engine like OPA, or if its native authorization logic is buried in imperative Python scattered across modules, then the security boundary is illusory. You cannot audit what you cannot clearly define.
The "unambiguous audit trails" you mention should be a series of policy decisions against a known set of input attributes. Without that, your logs are just narrative text, impossible to verify or replay. Have you found any agent frameworks that actually document their authorization query inputs and outputs in a machine-testable format? I have not.
policy first
Absolutely spot on about the sandboxing point. You see it with Docker-based setups too - they'll say "runs in a container" like that's a magic security box, but default configurations are often way too permissive. I had to learn the hard way about namespace isolation and dropping capabilities when I first tried to run untrusted code in my lab.
It forces you to become your own framework security team, layering on things like seccomp profiles and read-only bind mounts they never mention. Makes you wonder if the authors have even tried to break their own "safe" execution model, or if it's just checking a box.
lab.firstname.net
Yep, the "runs in a container" checkbox is everywhere. It feels like a marketing bullet point, not a security boundary. My breaking point was when I saw a popular framework's Dockerfile running the agent as root with all capabilities "for ease of use."
You really do end up as your own security team. I've started treating the default Docker config from any framework as inherently hostile and building my own hardened runner image from scratch. Even then, you're relying on your own seccomp/bAppArmor skills, which is a whole other can of worms.
Have you found any frameworks that actually publish their container security posture clearly? Like, a proper breakdown of dropped caps and syscall filters? I've only seen it in, like, one niche project's deep docs.
"Fundamentally inadequate" is putting it mildly. It's like they write the docs to impress a hiring manager, not to help someone actually secure a thing.
Your point about the docs avoiding a frank assessment is key. I rarely see a framework list its *known* security limitations. You know, the "if you do X, the isolation breaks because Y" section. That omission is itself a security risk.
It reminds me of the bug bounty reports where the vendor's public docs make a grand claim, but the actual code path is full of escape hatches they never mention. Makes you wonder if the thin docs are a feature, not a bug.
Reality is the only threat model that matters.
Totally feel you on building your own runner image from scratch. That's become my default move too.
The "root with all caps for ease of use" pattern is a huge red flag. It tells me they never considered real deployment, just quickstart demos.
To answer your question, no, I haven't seen a mainstream framework publish a real breakdown. The one niche project I can think of is "CageFerret" (maybe you're talking about the same one?), and even theirs was buried in a /deployment/security.md file most people never click. Everyone else just has "docker run" in the quickstart and calls it a day.
It forces you into that DIY security team role, which is fine for us tinkerers, but it's a massive barrier for any team wanting to adopt this stuff safely. Where's the middle ground?
Selfhosted since 2004