Forum

Notifications
Clear all

I wrote a small script to check all tool definitions for dangerous permission combos.

3 Posts
3 Users
0 Reactions
28 Views
(@api_sec_omar)
Active Member
Joined: 3 months ago
Posts: 13
Topic starter   [#1360]

Hey folks. I've been spending more time with NanoClaw in my home lab, specifically looking at how we define tools for the agents. The more I play with it, the more I realize it's way too easy to accidentally give a tool combination of permissions that could let a misbehaving agent do some real damage, especially in a self-hosted, internet-facing scenario.

I ended up writing a small Python script that parses your `tool_definitions.yaml` (or similar) and flags dangerous patterns. It's not a full static analyzer, but it catches the obvious stuff. The core idea is to look for tools that, when combined, could lead to things like:
* Arbitrary code execution (e.g., `shell` access plus `file_write` in a sensitive directory)
* Privilege escalation (e.g., ability to modify agent config or systemd units)
* Data exfiltration (e.g., `database_query` plus `network_access` without constraints)

Here's the basic version I started with. It loads definitions and checks against a simple rule set.

```python
#!/usr/bin/env python3
import yaml
import sys

# Define dangerous permission combos (tool_name: [list of other risky tool names])
RISKY_COMBOS = {
"execute_shell_command": ["write_file", "manage_processes"],
"write_file": ["read_system_config"],
"query_database": ["send_http_request"],
}

def check_tool_definitions(filepath):
with open(filepath, 'r') as f:
tools = yaml.safe_load(f)

tool_names = [tool['name'] for tool in tools['tools']]
found_issues = []

for primary_tool, risky_companions in RISKY_COMBOS.items():
if primary_tool in tool_names:
for risky in risky_companions:
if risky in tool_names:
found_issues.append(f"Combo: '{primary_tool}' + '{risky}'")

return found_issues

if __name__ == "__main__":
issues = check_tool_definitions(sys.argv[1])
if issues:
print("Potential risky permission combinations found:")
for issue in issues:
print(f" - {issue}")
sys.exit(1)
else:
print("No obvious dangerous combos found.")
```

You'd run it like `python3 check_tools.py ./config/tool_definitions.yaml`. The rule set (`RISKY_COMBOS`) is the most important part to expand for your own deployment. Think about the zero-trust principle: if an agent gets compromised, what tools could be chained together to break out of its intended scope?

This is a first pass. It could be enhanced to understand scopes (like file paths for write operations) or integrate into a CI/CD pipeline. For now, it's a simple sanity check before you deploy. I'm curious what dangerous combos others have thought of, or if you've built similar checks into your NanoClaw hardening process.



   
Quote
(@agent_isolator_rita)
Eminent Member
Joined: 3 months ago
Posts: 21
 

Good instinct to start with static analysis, but you're focusing on the wrong layer. Tool-level permission combos are a symptom, not the cause. The real boundary failure happens when your sandbox lets the agent *invoke those tools at all*.

Your script might flag that "execute_shell_command" and "write_file" are a risky pair. But if your agent's seccomp profile allows `execve` and `open` with `O_WRONLY`, that script's output is just a polite warning about a breach that's already happened. The kernel doesn't care about your YAML relationships.

You need to define the isolation boundary first, then check if your tool definitions can possibly violate it. Reverse the process. Start with the minimum viable namespaces (user, mount, network, PID) and a strict seccomp-bpf filter. *Then* see what your tools can actually do. You'll find most of your "dangerous combos" are impossible if the boundary is correct.


capability check


   
ReplyQuote
(@supply_chain_guard)
Eminent Member
Joined: 3 months ago
Posts: 28
 

While I applaud the proactive approach, I'm concerned your script's rule set will become unmaintainable and miss nuanced attack vectors. Defining static `RISKY_COMBOS` is a combinatorial explosion waiting to happen; each new tool addition requires manual analysis against every existing entry. This misses the transitive risk - tool A writes a script, tool B schedules it, tool C provides the payload.

A more scalable method is to map each tool's capabilities to a set of underlying security-relevant operations (e.g., `file_write:path_pattern`, `net_outbound:destination`, `proc_exec`). Then your analysis can check for reachability between these operations within a single agent's assigned toolset. This also allows you to incorporate context, like whether `file_write` is scoped to `/tmp` or includes `/etc`.

Also, consider integrating this check into your CI/CD for the tool definitions, and generating an SBOM for the analyzer itself. If you're going to gate deployments on this script, you need to sign its releases and attest to its provenance. Otherwise, you're just adding another toolchain vulnerability.


Trust but verify the build.


   
ReplyQuote