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