샘플러는 헤드리스 에이전트를 돌려서 소셜 플랫폼을 검색하라고 시켜. 뻔한 강화는 도구 허용 목록이야. 검색 도구 넷을 지명하고, 나머지를 빼고, 끝. 교과서적인 최소 권한 설정처럼 읽히지.
실제로 일어난 건 그 도구들을 지명한 게 세션에서 걔들을 안 물린 채로 뒀다는 거야. 에이전트가 돌았고, 자신 있고 잘 포맷된 답을 냈고, 아무것도 검색 안 했어. 제한 플래그가 아예 없는 세션은 같은 도구를 문제없이 썼고. 잠금이 허용하려던 바로 그 능력을 없앴는데 어디서도 문제를 보고 안 했어.
이 부류 실패가 왜 그렇게 위험한가
가능한 상태 둘을 봐. 첫째, 허용 목록이 작동해. 에이전트가 검색하고 찾은 것에 근거한 답을 돌려주지. 둘째, 허용 목록이 도구를 망가뜨렸어. 에이전트가 검색을 못 하고 자기 사전 지식으로 답을 돌려줘. 둘 다 그럴듯한 출력을 내는 성공한 실행이야. 종료 코드도 같고, 형식도 같고, 내용은 어느 쪽이든 자신만만하고.
그러니까 일반 규칙은 불편하지만 단순해. 능력을 제한하는 통제엔 그 능력이 살아남았다는 긍정 검사가 필요하다. 제한을 확인하는 걸로는 부족해. 남은 게 여전히 작동하는지 확인해야 하고, 안 그러면 과하게 제한된 설정이랑 맞는 설정을 구별할 수 없어.
차단 목록, 그리고 여기선 왜 강등이 아닌지
대체품은 모양을 뒤집어. 도구를 쓸 수 있게 두고, 위험한 것들을 명시적으로 빼. 명령을 실행하거나, 파일을 읽고 쓰거나, 에이전트를 더 낳거나, 작업을 예약하는 것들. 흔한 논변대로면 더 약한 보안처럼 보여. 차단 목록은 네가 생각 못 한 걸 못 덮으니까.
두 가지가 이걸 맞는 거래로 만들어. 첫째, 허용 목록이 작동을 안 했고, 작동 안 하는 통제는 보안을 하나도 안 줘. 둘째, 여기 실제 위협은 구체적이고 열거 가능해. 위험은 기계에 작용하는 도구고, 그 집합은 작고, 알려져 있고, 확인 가능하거든. 그러는 동안 보존되는 능력인 검색은 순도 게이트가 따로 검증하고, 그게 허용 목록 버전엔 없던 긍정 검사야.
설정을 믿기 전에 찔러봐
과정 쪽 해법은 라이브 탐침이야. 능력을 제한하는 플래그 위에 뭘 짓기 전에, 그걸 달고 한 번 돌려서 제한된 능력이 실제로 작동하는지 확인해. 명령이 0 으로 끝났는지가 아니라, 네가 허용한 그것이 일어났는지. 여기선 응답에 플랫폼의 진짜 인용이 들었는지 확인하는 거지. 십 분 찔러보는 게 이미 나가버린 가정 하나를 대체했어.
통제가 금지하는 것만 말고 허용하는 것도 확인해. 너무 많이 없앤 오설정은 설계상 조용해. 아무것도 오류를 안 내고, 출력은 멀쩡해 보이고, 누가 그 답이 어떻게 나왔냐고 물을 때 알게 돼.
Code
능력을 망가뜨린 허용 목록, 그리고 그걸 대체한 차단 목록 더하기 긍정 검사·bash
# WHAT WAS TRIED: least privilege by allowlist. Reads correctly and
# silently left the four search tools UNWIRED -- the agent answered
# from prior knowledge, exit 0, plausible output, no search performed.
grok -p "$PROMPT" \
--tools 'x_user_search,x_keyword_search,x_semantic_search,x_thread_fetch' \
--yolo --output-format json
# WHAT SHIPPED: a denylist of everything that ACTS on the machine.
# Mandatory under --yolo: nothing pauses to ask a human, and the
# material being processed is text written by strangers -- so a tool
# that writes files or runs commands is a path from a stranger's post
# to an action on this host.
DISALLOWED='run_terminal_command,read_file,list_dir,grep,search_replace,write,
spawn_subagent,kill_command_or_subagent,get_command_or_subagent_output,
scheduler_create,scheduler_delete,scheduler_list,workflow,
image_gen,image_edit,image_to_video,reference_to_video,Agent'
grok -p "$PROMPT" \
--disallowed-tools "$DISALLOWED" \
--yolo --output-format json \
# ...and the capability that REMAINS is verified separately, by the
# purity gate: a card citing no real post from the platform is
# rejected. That positive check is what the allowlist never had.
네 시스템에서 능력 제한을 하나 찾아. 허용 목록, 범위 제한 토큰, 샌드박스 정책 같은 거. 허용된 능력이 여전히 작동한다는 걸 증명하는 긍정 테스트를 써서 돌려봐. 그 테스트를 쉽게 못 쓰겠으면, 지금 작동하는 제한이랑 너무 많이 없앤 제한을 구별할 방법이 없다는 걸 적어둬.
Hint
긍정 테스트는 보통 부정 테스트보다 쓰기 어렵고, 그래서 빠져 있는 거야. 금지됐다는 증명엔 실패하는 시도 하나면 되지만, 허용됐다는 증명엔 끝에서 끝까지 성공하는 사용이 필요하고 그건 진짜 자격 증명이랑 진짜 의존을 뜻하거든. 그 어려움이 이 구멍이 어디에나 있는 이유야.
Progress
Progress is local-only — sign in to sync across devices.