본문으로 건너뛰기
모든 글

블로그

securitypolicy

Deny by default, with the limits written down

· 글: Ece Yıldırım · 1분 읽기 · 글은 영어로 작성됩니다. 주변 페이지는 사용자의 언어를 따릅니다.

Every agent that can run a shell command has to answer one question: what happens when the model asks for something you did not mean? Most answer with a permission prompt. rovecode answers with four layers, and — this is the part we care about — a written limit for each.

Rules

Deny-default wildcard rules over the tool name and the argument vector. A forbidden pattern is denied before anything runs, and before a human sees it. The limit: this is pattern matching, not intent. A novel spelling of a dangerous command passes to the next layer.

Execpolicy

The parsed argv gets a verdict — allow, prompt, forbidden. Forbidden never reaches execution or a person. The limit: it reads the command, not the shell it will run in; an alias or a script body is opaque to it.

Approval

One card on the revised arguments, with allow, always and deny. Answers are cached per session; child agents cannot prompt. The limit: this is a human decision. --yolo skips this rung and never the deny rules above it.

Runtime

A bash denylist and a working-directory lock at execution time. Escape kills the running call, and on Windows its whole process tree. The limit: this is delegation, not isolation. Untrusted work belongs in a container or a microVM.

Why write the limits down

Because a safety model that only lists what it catches is a marketing page, and the first thing an attacker does is read the marketing page. The README states each layer's limit next to the layer, the site repeats it in fifteen languages, and the security page keeps the table above everything else it says. If a layer's limit ever moves, it moves in all three places or the test that compares them fails.