LuD1161

Joined 7 years ago

Karma
54
Submissions
66
Member since
Dec 9
Building on : https://github.com/LuD1161/agentjail
View on Hacker News

Recent submissions

Comment · 2 months ago
Comment · 2 months ago
I just checked the repo. Nice work A suggestion: 1. Adding which repo/project was where my most tokens were consumed. I checked the image in the repo README, didn't see that graph.
Comment · 2 months ago
wow i need to check the 32GB cards. how did you handle the KV cache. Oh i see it was the Q6 model. Did you have to cut down on context window?
Comment · 3 months ago
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?

Comment · 3 months ago
You mean, I should stop posting much about it ? Is it too aggressive posting Am sorry about that.
Comment · 3 months ago
With agentjail ( https://github.com/LuD1161/agentjail ), I've tried to contain coding agents in os-native sandboxes (sbpl for macos and similarly for linux, <4ms start time) + policy guardrails evaluated by Open Policy Agent (OPA), policies written in rego.

Protocol aware network proxy coming soon Then you can match a DSL and block particular network requests.

This ensures you no longer fear --dangerously-skip-permissions and stop babysitting agents

What else would you want to see in this project? Please star the repo, if you like the idea :)

Comment · 3 months ago
With agentjail (github.com/LuD1161/agentjail), I've tried to contain coding agents in os-native sandboxes (sbpl for macos and similarly for linux) + policy guardrails evaluated by Open Policy Agent (OPA), policies written in rego.

Protocol aware network proxy coming soon Then you can match a DSL and block particular network requests.

This ensures you no longer fear --dangerously-skip-permissions and stop babysitting agents

What else would you want to see in this project? Please star the repo, if you like the idea :)

Comment · 3 months ago
Policy guardrails for Coding Agents. Never babysit your agents - github.com/lud1161/agentjail

· OS native sandbox (<4ms start-time) · Policies for AWS, local files, k8s, DBs etc. · Rego backed policies w/ OPA (CNCF Graduated project) · Fastest policy evaluator (<3ms)

Please star the repo if you like the work.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton