Hacker News가 Claude Code용 context-aware permission guard를 검토하다

이 project가 고치려는 문제

Show HN thread의 주인공은 Claude Code용 security layer인 nah다. README는 같은 tool이 어떤 맥락에서는 harmless하고 다른 맥락에서는 destructive할 수 있는데, allow-or-deny permission만으로는 그 차이를 표현하기 어렵다고 출발한다. 그래서 nah는 tool call이 실제로 무엇을 하려는지 분류한다. Bash 구조, ~/.ssh나 .env 같은 sensitive read, write와 edit target, suspicious content, Glob이나 Grep를 통한 sensitive directory scan, 그리고 generic한 MCP tool call까지 확인한다.

핵심 설계는 deterministic classifier가 항상 먼저 돈다는 점이다. README에 따르면 block는 nah., 사용자 확인이 필요한 경우는 nah?로 표기되고, 그 뒤에도 남는 애매한 case만 optional LLM으로 넘긴다. 예시는 의도를 쉽게 보여준다. git push는 허용될 수 있지만 git push --force는 다시 봐야 하고, project 내부의 build artifact 삭제는 괜찮을 수 있지만 cloud credential read는 그렇지 않다. 또한 project는 --dangerously-skip-permissions에 의존하지 말라고 경고한다. asynchronous hook 때문에 guard가 막기 전에 command가 먼저 실행될 수 있기 때문이다.

HN이 집중한 지점

HN commenters는 nah를 유용하다고 봤지만 완결된 해답으로 보지는 않았다. 여러 reply는 tool layer의 policy logic 아래에 Docker, virtual machine 같은 진짜 sandbox가 여전히 필요하다고 주장했다. 또 다른 이들은 multi-step exfiltration과 간접적인 damage를 지적했다. 개별 command는 harmless해 보여도 chain 전체는 secret을 밖으로 보낼 수 있고, agent는 평범한 source file에 악성 code를 써 넣은 뒤 test나 build step으로 나중에 실행시킬 수도 있다는 것이다. policy surface가 커지면 hardcoded assumption 대신 별도의 DSL이 필요할 것이라는 논점도 나왔다.

이 회의론은 project를 깎아내리는 반응이라기보다 왜 이 tool이 주목받았는지를 보여준다. 개발자들은 toy agent가 아니라 filesystem, network, MCP access를 가진 agent를 다루기 시작했고, 단순한 permission prompt만으로는 intent를 충분히 표현할 수 없다는 사실이 이미 분명해졌다. nah가 흥미로운 이유는 permissioning을 yes-or-no switch가 아니라 log와 inspectable decision을 가진 context classifier로 바꾸려 하기 때문이다.

왜 지금 중요한가

이 thread는 agent safety tooling의 현재 위치를 잘 보여준다. deterministic policy engine은 점점 필수가 되고 있지만 sandboxing을 대체하지는 않는다. 대신 사용자 intent와 raw tool execution 사이에 놓이는 middle layer가 된다. nah는 그 변화를 대표하는 사례다. practical하고 local하며 opinionated하지만, 동시에 agent security가 단일 rule set이 아니라 systems problem이라는 점을 분명히 알고 있다.

Source post: Hacker News discussion. Primary source: nah README.