Loading ToolBench
A drop-in shell execution wrapper for LLM agents that prevents hallucinated/destructive commands with AI safety validation and gatekeeper decision making
SecureShell exposes a single tool, execute_shell_command, with reasonable structure but significant gaps in production-readiness. The tool has a description and basic schema, but lacks critical safety documentation, error-handling guidance, and output schema definition. The description does not adequately warn about the destructive nature of command execution or guide recovery when the gatekeeper denies a command. Parameter descriptions are minimal. Most critically, there is no documented output schema, callers do not know what format the gatekeeper response takes (ALLOW/DENY/CHALLENGE), how to interpret it, or what data is returned on success. For a tool that executes arbitrary shell commands with a security gate, the definition quality is dangerously incomplete.
Execute shell commands securely with AI gatekeeper validation. Gatekeeper may ALLOW, DENY, or CHALLENGE (request clarification). Commands are sandboxed and audited. Use this for file operations, system commands, git operations, and other shell tasks.
No output schema documented. The tool description states the gatekeeper may ALLOW, DENY, or CHALLENGE, but the response structure, fields, and data format are not defined anywhere in the source. Callers do not know what to expect or how to interpret the result. This is critical for destructive operations.
Error handling and recovery guidance missing. The tool description mentions DENY and CHALLENGE responses but provides no guidance on what the LLM should do when denied (retry? ask user for clarification? abandon?). For a security gate, error classification and recovery paths are essential.
Description lacks severity and consequence warnings for destructive operations. The description does not explicitly state that this tool modifies system state, can delete files, or has irreversible consequences. For an agent tool that executes shell commands, this is a dangerous omission. Agents need to know which calls are idempotent and which are not.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Parameter 'reasoning' is required but has minimal guidance. The minLength constraint of 10 is in the schema but not mentioned in the parameter description. The description should explain why reasoning is required, what constitutes good reasoning, and how it is used by the gatekeeper.
Tool description is generic and does not clearly distinguish this from a raw shell execution tool. It mentions 'sandboxed' and 'audited' but does not explain what sandboxing is in place, what audit trails are kept, or what the actual execution environment is. Agents need concrete context about limitations and guarantees.
No documented constraints on command types or lengths. The 'command' parameter has no description of allowed command syntax, shell, maximum length, or prohibited patterns (e.g., piping, backgrounding). This invites hallucinated or invalid commands from LLMs.
No permission or scope declaration. The tool does not specify what permissions are required to execute it, whether authorization is checked, or what the blast radius is if an agent is compromised. For a tool that can execute arbitrary shell commands, this is a significant oversight.
No documentation of idempotency guarantees. Many shell commands are not idempotent (e.g., 'rm' can fail on a second run if the file is already deleted). Agents may retry on transient errors, the tool definition should state which commands are safe to retry and which are not, or provide a confirmation mechanism for destructive operations.