■ 에이전트 권한
표시가 없는 문장은 공식 문서에서 확인한 내용이에요. 다른 표시는 읽는 법
왜 배우나 — 시험이 요구하는 것
시험 목표 7.1 팀 도구·환경 설정 · D7 개발팀 7%Configure Claude tools and environments for teams (e.g., Claude Code)
이 개념으로 푸는 판단 (할 수 있어야 하는 것)
- 7.1③ 에이전트에 줄 권한, 어디까지? — 행동을 allow/ask/deny 로 나눈 공유 설정 + MCP 자격증명 최소 권한
- 7.1① 팀 규칙을 모두의 모든 세션에 똑같이 싣으려면? — 개인 설정 vs 저장소에 커밋한 프로젝트 설정 vs 조직 관리형 설정
- 7.1② '반드시' 돌아야 하는 검사, 어디에 거나? — 지시(CLAUDE.md) vs 훅, 그리고 어느 훅 이벤트
- 3.1① 상담원은 읽기·초안만 쓰는데 환불·삭제 도구가 붙어 있다 — 무엇을 바꾸나? — 과잉 권한 줄이기 (도구 제거 vs 로그·확인창 vs 모델 교체)
한눈에
Claude Code 가 도구 호출마다 규칙으로 허용(allow)·확인(ask)·거부(deny)를 정한다. 규칙은 모델이 아니라 Claude Code 가 강제한다. 프롬프트와 CLAUDE.md 는 허용 범위를 바꾸지 못한다
팀 규칙은 커밋한 .claude/settings.json 에 둔다. 팀 MCP 서버는 커밋한 .mcp.json 에 둔다
비유 IAM 정책의 명시적 Deny 와 같다. 어느 정책에 Allow 가 있어도 Deny 하나가 이긴다
ELI5
건물 출입 규칙이에요. 경비는 목록을 정해진 순서로 봐요.
- 먼저 "출입 금지" 목록을 봐요. 있으면 끝, 못 들어가요.
- 다음 "물어보고 들여보내기" 목록을 봐요.
- 마지막에 "그냥 통과" 목록을 봐요.
- 규칙은 경비가 지키지, 방문객 말로 안 바뀌어요.
개념 설명
원리
누가 강제하나
- 권한 규칙은 Claude Code(클라이언트)가 도구 호출마다 검사한다. 그래서 모델이 뭐라고 하든 결과가 같다.
- CLAUDE.md 와 프롬프트는 Claude 가 무엇을 시도할지만 바꾼다. 무엇이 허용되는지는 바꾸지 못한다.
순서가 결과를 정한다
- 순서는 deny, ask, allow 다. 첫 일치가 결정한다. 구체성은 순서를 바꾸지 못한다. 그래서 예외를 두려면 deny 를 좁히는 수밖에 없다.
- 층도 마찬가지다. 어느 층이든 deny 면 끝이다. 그래서 조직은 deny 만 내려도 아래 층이 풀지 못한다.
- 능력을 주는 쪽(allow)은 신뢰가 필요하다. 제한하는 쪽(deny·ask)은 바로 적용된다. 남이 커밋한 파일이 내 기계에 권한을 여는 것을 막기 위해서다.
deny 의 두 얼굴
- 도구 전체 deny(
Bash)는 도구 정의를 Claude 에게서 없앤다. 그래서 Claude 는 그 도구를 부를 생각도 못 한다. 이것이 필요 없는 도구 빼기다(■ 최소 권한). - 패턴 deny(
Bash(rm *))에서는 도구가 보인다. 맞는 호출만 막힌다.
규칙의 한계
- Bash 규칙은 명령 글자를 본다. 그래서 다른 표기(
git -C . push)는 빠져나간다. - 이 한계 때문에 층을 겹친다.
- 권한 규칙 : 글자를 본다
- PreToolUse 훅 : 내 로직으로 본다
- 샌드박스 : OS 수준이다. 인젝션이 판단을 뚫어도 남는다
MCP 는 "어디에 적었나"가 공유 범위다
- 범위는 셋이다.
- local : 나와 이 프로젝트다(기본)
- project :
.mcp.json을 커밋하면 팀이다 - user : 나와 모든 프로젝트다
- 비밀은 파일 밖(
${VAR})에 둔다. 개인 자격증명이면 local 에 둔다. - 커밋한 서버는 대화형 세션에서 승인을 받고 켜진다. 클론한 저장소가 스스로 켤 수 없다.
핵심 질문은 두 개다
- 이 도구가 역할에 필요한가? (아니면 뺀다)
- 필요하면, 이 호출이 되돌리기 어려운가? (allow / ask / deny)
규칙과 판단
갈림길
②③ 이 행동, 어느 규칙 [7.1③]
도구 전체 deny
도구 이름만(Bash) 적으면 Claude 맥락에서 도구를 아예 뺀다. 자세한 것은 ■ 최소 권한 에 있다
allow
묻지 않고 실행한다
ask
매번 확인한다
패턴 deny
Bash(rm *) 처럼 패턴으로 막는다. 도구는 남고 맞는 호출만 막힌다
①④⑤ 규칙이 부딪힐 때 [7.1③] [7.1①]
deny
deny, ask, allow 순으로 보고 첫 일치가 결정한다
deny
어느 층이든 deny 면 다른 층이 allow 하지 못한다
ask
로컬 'don't ask again' allow 는 프로젝트·관리형 ask 를 이기지 못한다
훅이 먼저 실행된다
exit 2 훅은 allow 가 있어도 막는다. 훅의 allow 는 deny·ask 를 넘지 못한다
⑥ MCP 서버 어디에 [7.1③]
project (.mcp.json 커밋)
비밀은 파일에 적지 말고 ${VAR} 로 뺀다
local (기본값)
커밋하기 싫은 자격증명이 든 서버를 둔다
user
~/.claude.json 에 둔다
흐름
그림 속 이름·금액·시간·토큰 수는 예시예요. 공식 한도·동작은 카드 본문 값이 기준.
장면 글로 보기
칸 : 호출 → deny → ask → allow
규칙 (deny) : deny, ask, allow 순으로 보고 첫 일치가 결정한다
규칙 (allow) : Bash(npm run *) · Bash(aws s3 ls)
질문 : 규칙 셋 중 무엇을 먼저 볼까?
① 저위험 반복 명령 ✓
- 시작 : 호출 — 쪽지 : Bash 명령 /
npm run lint - 검사 : 호출 → deny : 걸리지 않는다 — 쪽지 :
Bash(aws *)/ → 불일치 - 검사 : 호출 → ask : 걸리지 않는다 — 쪽지 :
Bash(git push *)/ → 불일치 - 통과 : 호출 → allow : 묻지 않고 실행한다 — 쪽지 :
Bash(npm run *)/ → 일치 · 실행 - 끝 : allow 는 묻지 않는다. 확인창 없이 lint 가 실행된다
② 좁은 allow 로 넓은 deny 뚫기 ≠
- 시작 : 호출 — 쪽지 : Bash 명령 /
aws s3 ls - 검사 : 호출 → deny : 넓은 deny 에 걸린다 — 쪽지 :
Bash(aws *)/ → 일치 · 거부 - 건너뜀 : ask
- 건너뜀 : allow
- 끝 : 첫 일치가 deny 다. 좁은 allow(
Bash(aws s3 ls))도 넓은 deny 를 뚫지 못한다
③ 다른 표기로 빠져나감 ≠
- 시작 : 호출 — 쪽지 : Bash 명령 /
git -C . push - 시작 : deny — 쪽지 :
Bash(git push *)/ 를 deny 에 두면 - 검사 : 호출 → deny : deny 에 걸리지 않는다 — 쪽지 :
git -C . push/ → 불일치 - 끝 : Bash 규칙은 명령 글자를 맞춰 본다. 그래서
git -C . push는 걸리지 않는다. 내용 검사는 PreToolUse 훅이 한다
나머지 규칙
-
모드 : 무인 실행(CI·예약 작업)에는
dontAsk를 쓴다. 미리 허용된 도구만 쓰고 나머지는 자동으로 거부한다.bypassPermissions는 격리된 컨테이너·VM 에서만 쓴다 [7.1③]auto에서는 분류기가 매 행동을 검토한다. 이것이 고위험(high-stakes) 인프라의 꼼꼼한 사람 검토를 대신하지는 않는다
규칙 원문 ①②③④⑤⑥ (갈림길로 그린 규칙)
-
세 규칙 : 규칙은 셋이다 [7.1③]
- allow : 묻지 않고 실행한다
- ask : 매번 확인한다
- deny : 쓰지 못한다
평가 순서는 deny, ask, allow 다. 첫 일치가 결정한다. 더 구체적인 규칙이라고 순서가 바뀌지 않는다. 좁은 allow(
Bash(aws s3 ls))도 넓은 deny(Bash(aws *))를 뚫지 못한다 -
위험도로 나눠 공유 설정에 : 명령을 위험도로 나눠 공유 설정에 싣는다 [7.1③]
- 저위험 반복(
Bash(npm run *)) : allow - 되돌리기 어려운 것(
Bash(git push *)) : ask 또는 deny - 비밀 파일(
Read(./.env)) : deny
어느 명령을 ask 나 deny 에 둘지는 팀이 판단한다 업계 일반
- 저위험 반복(
-
deny 두 종류 : deny 는 두 종류다 [7.1③] [3.1①]
- 도구 이름만(
Bash) : 도구를 Claude 맥락에서 아예 뺀다. Claude 는 그 도구를 보지 못한다 - 패턴(
Bash(rm *)) : 도구는 남고 맞는 호출만 막는다
역할에 필요 없는 도구는 도구 전체를 뺀다. 자세한 것은 ■ 최소 권한 에 있다
- 도구 이름만(
-
층 합치기 : 어느 층이든 deny 면 다른 층이 allow 하지 못한다. 사용자 allow 와 프로젝트 deny 가 만나면 막힌다. 반대로 놓여도 막힌다. 관리형 deny 는
--allowedTools로도 뚫지 못한다로컬 'don't ask again' allow 는 프로젝트·관리형 ask 를 이기지 못한다. 커밋한 allow 는 팀원이 그 폴더를 신뢰한 뒤에 적용된다. deny 와 ask 는 바로 적용된다. 자세한 것은 ■ 팀 설정 위치 에 있다
조직은 두 설정으로 잠근다.
allowManagedPermissionRulesOnly는 관리형 설정만 권한 규칙 출처로 삼는다.disableBypassPermissionsMode도 조직 잠금 설정이다 [7.1①] [7.1③] -
규칙의 한계 : Bash 규칙은 명령 글자를 맞춰 본다. 그래서
git -C . push는Bash(git push *)에 걸리지 않는다 [7.1②] [7.1③]명령 내용을 내 코드로 검사하려면 PreToolUse 훅을 쓴다. 파일과 네트워크를 OS 수준에서 막으려면 샌드박스를 쓴다. 자세한 것은 ◆ CLAUDE.md(지시) vs 훅(강제) 에 있다
훅 vs 규칙 : 훅이 먼저 실행된다. exit 2 훅은 allow 가 있어도 막는다. 훅의 allow 는 deny·ask 를 넘지 못한다
-
MCP 범위 [7.1③]
범위 어디 누구 쓰는 곳 local (기본) ~/의 그 프로젝트 칸. claude. json 나만, 이 프로젝트 개인 개발 서버·실험·커밋하기 싫은 자격증명 project 저장소 루트 .mcp.json 커밋하면 팀 팀 공유 도구 user ~/. claude. json 나만, 모든 프로젝트 개인 유틸 같은 이름이 여러 범위에 있으면 local > project > user 순으로 이긴다. 항목을 통째로 고르고 필드는 섞지 않는다
.mcp.json은${VAR}·${VAR:-기본값}을 확장한다(command·args·env·url·headers). 그래서 파일은 공유하고 토큰은 각자 환경에 둔다project 서버는 대화형 세션에서 쓰기 전에 승인을 묻는다. 클론한 저장소는 스스로 승인하지 못한다. 커밋한
enableAllProjectMcpServers는 미신뢰 폴더에서 무시된다.-p·SDK 세션은 묻지 않고 로드한다. 이것을 막으려면disabledMcpjsonServers를 쓴다MCP 권한 규칙은 아래와 같다
mcp__github는 서버 전체를 가리킨다- allow 글롭은 서버 이름을 고정해야 한다(
mcp__github__get_*) - deny
mcp__*는 모든 MCP 도구를 뺀다
조직은
managed-mcp.json·allowedMcpServers·deniedMcpServers로 관리한다MCP 토큰 범위를 줄이는 법(OAuth scope 최소)은 ■ MCP 인증·인가 에 있다
더 깊이 : 판단 규칙 · 상황 변수 (설명)
판단 규칙
| 조건 | 답 | 근거 |
|---|---|---|
| 역할이 안 쓰는 도구다 | 도구 전체를 deny 한다(또는 목록에서 뺀다) | permissions "A bare tool name like Bash removes the tool from Claude’s context entirely" · 가이드 샘플 1 |
| 저위험 반복 명령이다 | allow 한다 | permissions (Bash(npm run *)) |
| 되돌리기 어려운 명령이다 | ask(매번 확인)나 deny 에 둔다 | permissions (Bash(git push *)) |
| 넓은 deny 에 좁은 예외가 필요하다 | deny 를 좁힌다. allow 로는 뚫지 못한다 | permissions "An allow rule can’t carve an exception out of a deny rule." |
| 명령 내용과 다른 표기까지 막아야 한다 | PreToolUse 훅이나 샌드박스를 쓴다 | permissions |
| 팀이 공유할 MCP 서버다 | .mcp. 을 커밋한다. 비밀은 ${VAR} 로 뺀다 | mcp |
| 개인 자격증명이 든 MCP 서버다 | local 범위에 둔다 | mcp |
| 사람 없는 파이프라인이다 | dontAsk 를 쓴다(미리 허용된 것만 실행한다) | permissions · Skilljar 486932 |
| 확인창을 전부 끄려 한다 | bypassPermissions 는 격리 컨테이너·VM 에서만 쓴다 | permissions |
상황 변수
| 변수 | 값 | 답 쪽 | 근거 |
|---|---|---|---|
| 도구 필요성 | 역할에 없다 | 도구 전체를 deny 한다 | 판단 규칙 1 |
| 되돌림 | 쉽고 반복된다 | allow 한다 | 판단 규칙 2 |
| 되돌림 | 어렵다 | ask 나 deny 에 둔다 | 판단 규칙 3 |
| 규칙 출처 | 관리형 deny 다 | 누구도 풀지 못한다. -- 로도 풀지 못한다 | permissions |
| 규칙 출처 | 커밋한 allow 다 | 팀원이 폴더를 신뢰한 뒤에 적용된다 | permissions |
| 규칙 출처 | 로컬 'don't ask again' 이다 | 프로젝트·관리형 ask 를 이기지 못한다 | settings |
| 실행 방식 | 대화형이다 | project MCP 서버 승인을 묻는다 | mcp |
| 실행 방식 | claude -p·SDK 다 | project MCP 서버를 묻지 않고 로드한다 | mcp |
| 샌드박스 | 켰고 autoAllowBashIfSandboxed 가 기본값이다 | Bash 전체 ask 를 샌드박스 경계가 대신한다 | permissions |
| 모드 | auto 다 | 분류기가 검토한다. 고위험(high-stakes) 인프라의 사람 검토를 대신하지 않는다 | auto mode 글 |
연습 문제
팀 저장소 .claude/settings.json 의 deny 에 Bash(aws *)넓은 deny 가 있다. 한 개발자가 S3 목록만 보려고 같은 파일의 allow 에 Bash(aws s3 ls) 를 추가좁은 allow했다. 개발자는 "더 구체적인 규칙이니 이긴다" 고 믿는다. Claude 가 aws s3 ls 를 부르면 어떻게 되나?
시험 대비
함정
- "권한은 두고 감사 로그로 추적한다" 와 "머지 전에 확인창을 추가한다" 는 함정이다. 둘 다 보완 통제(control)일 뿐이다. 필요 없는 능력은 뺀다 (공식 샘플 1 A·C). 자세한 것은 ■ 최소 권한 에 있다
- "좁은 allow 가 넓은 deny 보다 구체적이니 이긴다" 는 함정이다. deny 를 먼저 본다
- "CLAUDE.md 에 'git push 하지 마' 라고 적는다" 는 함정이다. 규칙은 Claude Code 가 강제한다. 프롬프트는 허용 범위를 바꾸지 못한다
- "
Bash(git push *)deny 면 모든 push 가 막힌다" 는 함정이다.git -C . push는 걸리지 않는다. 그래서 훅이나 샌드박스를 쓴다 - "토큰을
.mcp.json에 적어 커밋한다" 는 함정이다. 토큰은${VAR}로 빼거나 local 범위에 둔다 - "로컬에서 'don't ask again' 을 눌렀으니 팀 ask 가 사라진다" 는 함정이다. 로컬 allow 는 ask 를 이기지 못한다
- "CI 에선 사람이 없으니
bypassPermissions를 쓴다" 는 함정이다. 무인 실행에는dontAsk를 쓴다. bypass 는 격리 환경에서만 쓴다 - "클론한 저장소의
.mcp.json서버는 다 믿고 자동 연결한다" 는 함정이다. 대화형 세션에서는 승인이 필요하다. 커밋한 자동 승인 키는 미신뢰 폴더에서 무시된다
신호
"Rules are evaluated in order: deny, then ask, then allow."
"An allow rule can’t carve an exception out of a deny rule."
"Permission rules are enforced by Claude Code, not by the model."
"If a tool is denied at any level, no other level can allow it."
"Check .mcp.json into version control so everyone on your team gets the same MCP tools and services."
"Use local scope for personal development servers, experimental configurations, or servers with credentials you don’t want in version control."
"Only use this mode in isolated environments like containers or VMs where Claude Code can’t cause damage." (bypassPermissions)
"Least privilege means removing capabilities the role does not require, eliminating the attack surface rather than monitoring or guarding it." (가이드 샘플 1)
더 깊이 : 뒤집히는 때 · 오답 재료 (설명)
뒤집히는 때
1. 샌드박스를 켜니 Bash 확인창이 사라지는 때
- 조건 : 팀 설정에
Bash전체 ask 가 있다. 누군가 샌드박스를 켠다(autoAllowBashIfSandboxed기본true). - 판단 : 샌드박스 안의 Bash 는 확인 없이 실행된다. 샌드박스 경계가 "모든 Bash 확인"을 대신하기 때문이다. 그래서 "ask 에 넣었으니 늘 묻는다"가 뒤집힌다. plan 모드에서는 이 대체를 하지 않는다. 그래도 아래 셋은 그대로 걸린다.
- 내용을 지정한 ask(
Bash(git push *)) - 명시 deny
- 중요 경로
rm
- 내용을 지정한 ask(
- 근거 : permissions
2. CI 에서 .mcp.json 서버가 묻지도 않고 붙는 때
- 조건 : 하루 300번 도는 CI 잡이
claude -p로 저장소를 연다. 저장소.mcp.json에 외부 서버가 있다. - 판단 : 대화형이면 승인을 묻는다.
-p·SDK 는 물을 수 없어서 그냥 로드한다. 막는 방법은 아래와 같다.disabledMcpjsonServers--setting-sources(SDKsettingSources)로 프로젝트 설정을 뺀다--strict-mcp-config
- 근거 : mcp
3. allow 해 뒀는데 계속 묻는 때 (MCP)
- 조건 : 팀이
mcp__crm__grant_access를 allow 했다. 서버가 이 도구에_meta["anthropic/requiresUserInteraction"]: true를 붙인다. 또는 조직이 claude.ai connector 도구를 ask 로 정한다. - 판단 : 둘 다 allow 규칙과 훅 allow 를 무시하고 매번 묻는다(
bypassPermissions에서도).dontAsk면 아예 거부한다. "allow = 안 묻는다"의 예외다. - 근거 : mcp · permissions
4. auto 모드로 바꾸니 넓은 allow 가 빠지는 때
- 조건 : 수동 모드에서 편하려고
Bash(python *)같은 넓은 인터프리터 allow 를 두었다. 그리고auto로 전환한다. - 판단 : auto 에 들어가면 임의 코드 실행을 여는 넓은 규칙은 버리고 분류기에 보낸다. 좁은 규칙만 이어진다. 버리는 넓은 규칙은 아래와 같다.
- 쉘 전체
- 인터프리터 와일드카드
- 패키지 매니저 run
- 등급 : (제품 문서가 아닌 Anthropic 엔지니어링 글, "best-effort")
- 근거 : auto mode 글
5. 사용자 deny 가 팀 allow 를 막는 때
- 조건 : 팀
.claude/settings.json이Bash(docker *)를 allow 한다. 한 팀원의~/.claude/settings.json에는Bash(docker *)deny 가 있다. - 판단 : 사용자 층은 우선순위가 가장 낮다. 하지만 권한에서는 deny 가 층과 무관하게 먼저다. 그래서 그 팀원에게는 막힌다. 값 하나짜리 키(model 등)의 "높은 층이 이긴다"(■ 팀 설정 위치)와 다르다.
- 근거 : permissions
오답 재료
| 오답 | 왜 끌리나 | 왜 틀리나 | 근거 |
|---|---|---|---|
| "관리자 토큰은 두고 감사 로그로 추적" | 기능을 안 깨고 안전해 보인다 | 사후 감지일 뿐이다. 필요 없는 능력은 뺀다 | 가이드 샘플 1 해설 · ■ 최소 권한 |
| "머지 전에 확인창 추가" | 사람이 한 번 본다 | 보완 통제(control)일 뿐이다. 능력은 남는다 | 가이드 샘플 1 해설 |
| "좁은 allow 가 더 구체적이니 넓은 deny 를 이긴다" | 방화벽 규칙처럼 구체 규칙이 우선일 것 같다 | 순서는 deny, ask, allow 다. 구체성과 무관하다 | permissions |
| "CLAUDE.md 에 'push 금지' 적으면 된다" | 쉽고 모두에게 실린다 | 규칙은 Claude Code 가 강제한다. 프롬프트는 허용 범위를 바꾸지 못한다 | permissions |
"Bash(git push *) deny 로 push 는 다 막힌다" | 규칙이 명확해 보인다 | git -C . push 는 걸리지 않는다 | permissions |
"토큰을 .mcp. 에 적어 커밋" | 팀원이 바로 쓴다 | 비밀이 저장소에 남는다. ${VAR} 나 local 을 쓴다 | mcp |
"CI 는 사람이 없으니 bypassPermissions" | 확인창에 안 멈춘다 | 무인 실행은 dontAsk 를 쓴다. bypass 는 격리 환경에서만 쓴다 | permissions · Skilljar 486932 |
"커밋한 enableAllProjectMcpServers 로 팀 서버 자동 연결" | 한 번에 다 켜진다 | 미신뢰 폴더에서는 무시된다. 서버는 승인을 기다린다 | mcp |
참고
더 깊이 : CCA-F · 출처 · 상태 · 미해결 (참고)
CCA-F
겹침 (2.4 MCP 스코프 local·project·user · ${VAR} 로 토큰 분리 · 2.3 서브에이전트마다 역할에 필요한 도구만). 여기서는 두 가지를 묻는다. 하나는 allow/ask/deny 를 위험도로 나눠 팀 공유 설정에 싣는 판단이다. 다른 하나는 규칙이 어느 순서·어느 층에서 이기는지다
출처
- 가이드 목표 7.1 공식 시험 가이드 v1.0
- 샘플 1 공식 시험 가이드 v1.0
- code.claude.com permissions
- settings
- mcp (2026-09-28 조회)
- auto mode 글
- Skilljar Claude Code in Action 486932
- CCA-F 노트 2.3·2.4 (개인 학습 노트)
상태
- 업계 일반 1줄(② 배치)
미해결
- 목록 7.1③ "리뷰 서브에이전트 = PR 코멘트만, 머지 불가" 는 공식 원문에서 못 찾았다(파일 en-claude-code-mcp.md·en-claude-code-permissions.md, 검색어 review·pull request·merge). 원리는 ■ 최소 권한 이 덮는다. 그래서 카드에는 예로 넣지 않았다.
- 목록은 "rm -rf·force push = deny, git push = ask" 로 배치한다. 공식 예는
Bash(git push *)를 deny 로도(permissions) 쓰고 ask 로도 쓴다. 어느 쪽에 둘지는 팀이 판단한다(업계 일반). - 서브에이전트 파일 안에 MCP 서버를 좁혀 거는 법(sub-agents 문서 "Scope MCP servers to a subagent")은 받지 않았다. mcp에 링크만 있다.
- 관리형 MCP(
managed-mcp.json·allowedMcpServers·deniedMcpServers) 세부는 managed-mcp 문서 소관이다. 이번에는 이름만 확인했다(mcp).