Hey thanks for the question. I would like to answer it in a more descriptive manner with an example later.
Classifying a command can be a bit of a misnomer because it has two inherent problems:
1. You need a classifier. That means the security boundary becomes “can I trick or bypass the classifier?” Whether it is a smaller model or a pile of regexes, it will eventually have edge cases.
2. The token economics do not work, and it also needs to be fast. I do not want an eval evaluating another eval for every command.
So the approach I took is closer to how we normally build security systems: secure defaults and deterministic boundaries.
For example, to protect secrets, AgentJail can block access to paths like `~/.ssh`, `~/.aws/credentials`, `.env`, etc. at the OS level.
The OS is the deterministic boundary here. The ring-0 enforcement layer.
The more interesting problem is network access. You may genuinely want the agent to debug a production Kubernetes cluster, inspect an AWS resource, or query a production database. A blanket network deny would make the agent useless.
For that, I am taking a protocol-aware DSL approach. Something like:
``` deny if { request.host == "api.github.com" request.method == "POST" startswith(request.path, "/repos/") endswith(request.path, "/git/refs") }
ask if { request.host == "kubernetes.default.svc" request.method == "DELETE" }
allow if { request.host == "api.github.com" request.method == "GET" } ```
So instead of trying to classify whether a command is “dangerous,” the policy describes exactly which resources and operations are allowed, denied, or require approval.
The agent can still be probabilistic. The enforcement boundary should not be.
Does that answer to your question?