From 1b12f9b1d6cee2d9c645b05180c617db0140f217 Mon Sep 17 00:00:00 2001 From: Teknium Date: Wed, 15 Apr 2026 14:30:40 -0700 Subject: [PATCH] docs: add terminal bypass test to Out of Scope section Clarifies that tool-level access restrictions are not security boundaries when the agent has unrestricted terminal access. Deny lists only matter when paired with equivalent terminal-side restrictions (like WRITE_DENIED_PATHS pairs with the dangerous command approval system). --- SECURITY.md | 1 + 1 file changed, 1 insertion(+) diff --git a/SECURITY.md b/SECURITY.md index e757c8897..3cede2885 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -55,6 +55,7 @@ The following scenarios are **not** considered security breaches: - **Trusted State Access:** Reports that require pre-existing write access to `~/.hermes/`, `.env`, or `config.yaml` (these are operator-owned files). - **Default Behavior:** Host-level command execution when `terminal.backend` is set to `local` — this is the documented default, not a vulnerability. - **Configuration Trade-offs:** Intentional break-glass settings such as `approvals.mode: "off"` or `terminal.backend: local` in production. +- **Tool-level read/access restrictions:** The agent has unrestricted shell access via the `terminal` tool by design. Reports that a specific tool (e.g., `read_file`) can access a resource are not vulnerabilities if the same access is available through `terminal`. Tool-level deny lists only constitute a meaningful security boundary when paired with equivalent restrictions on the terminal side (as with write operations, where `WRITE_DENIED_PATHS` is paired with the dangerous command approval system). ---