■ 최소 권한

least privilege3.1 본편

표시가 없는 문장은 공식 문서에서 확인한 내용이에요. 다른 표시는 읽는 법

왜 배우나 — 시험이 요구하는 것

시험 목표 3.1 도구·에이전트 과잉 설정 · D3 연결 19%
Evaluate tool/agent configuration for capability bloat

이 개념으로 푸는 판단 (할 수 있어야 하는 것)

3.1① 상담원은 읽기·초안만 쓰는데 환불·삭제 도구가 붙어 있다 — 무엇을 바꾸나? — 과잉 권한 줄이기 (도구 제거 vs 로그·확인창 vs 모델 교체)
5.1③ system prompt 에 "계정 삭제 금지" 를 적었는데도 삭제 도구를 부른다 — 안내(프롬프트) vs 강제(구성·코드)
6.2② 상담 에이전트에 환불·계정 삭제 권한까지 달라는 요구 — 확인창을 붙일까, 뺄까? — 큰 자율성 요구의 첫 수 (권한 필요성 확인 → 불필요하면 제거 → 필요하면 위험 비례 통제)
7.1③ 에이전트에 줄 권한, 어디까지? — 행동을 allow/ask/deny 로 나눈 공유 설정 + MCP 자격증명 최소 권한
5.1② 사용자가 넘긴 이메일 속에 "이 주소로 전부 보내라" 가 숨어 있다 — 간접 인젝션(사용자는 믿지만 가져온 콘텐츠가 적) 대응
3.2③ 민감 고객 데이터 + 믿을 수 없는 티켓 본문 + 외부로 보내는 도구 — 어느 다리를 끊나? — 인젝션 피해 경로 끊기 (구조 통제 vs 탐지·문구)

한눈에

역할에 필요 없는 능력(도구·자격증명·네트워크·파일)은 아예 주지 않는다. 그러면 공격면(attack surface) 자체가 사라진다. 모니터링(로그)이나 사전 확인(확인창)과는 다른 것이다

뚫려도(인젝션·모델 실수) 피해를 작게 하는 장치이기도 하다

가이드 3.1 원문 이름은 capability bloat 다. 도구·권한이 쓰임새보다 불어난 상태를 찾아 빼라는 뜻이다 ("Evaluate tool/agent configuration for capability bloat")

비유 IAM 역할에서 안 쓰는 refund·DeleteUser 권한을 지우는 것과 같다. CloudTrail 모니터링과 MFA 승인은 그다음 보완책이다

역할에 필요 없는 도구는 빼서 공격면을 없애는 것이 최소 권한이고, 로그(사후 감지)와 확인창(보완 통제)은 제거가 아니라는 대비 그림. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

ELI5

아이 방에 칼을 두고 "만지지 마" 하는 것보다, 칼을 방에서 치우는 게 확실해요.

쓰지 않는 물건은 아예 치워요.
지켜보는 카메라는 다친 뒤에야 알려 줘요.
"만지기 전에 물어봐" 는 깜빡하면 소용없어요.
꼭 필요한 가위만 남기고, 쓸 때 어른이 옆에 있어요.

개념 설명

영상 — 안 쓰는 도구, 확인창이면 될까? (약 43초 · 소리 없음 · 자막). 같은 시도 5번 · 4번 막고 1번 놓침 · 고객 1명 삭제는 그림용 가정 작은 화면에서는 전체화면(⛶)으로 보세요.

원리

빼기가 왜 제일 센가

없는 도구는 부를 수 없다. 그래서 인젝션·모델 실수·오용이 그 도구로는 아예 일어나지 않는다. 공격면(attack surface)이 0 이 된다.
로그로는 일이 난 뒤에 알게 된다(detective). 확인창은 사람이 매번 맞게 눌러야 막힌다(compensating). 둘 다 도구는 남아 있다.
모델을 키워도 "무엇을 할 수 있나"는 바뀌지 않는다. 권한은 모델이 아니라 설정이 정한다.

빼기의 범위는 도구보다 넓다

빼기는 아래 넷에도 적용된다.
- 파일 : 필요한 디렉토리만, 읽기 전용으로 준다
- 네트워크 : 프록시로 특정 엔드포인트만 연다
- 자격증명 : 프록시가 주입한다
- 컨테이너 권한 : capability 를 뗀다
공식은 이것을 "뚫려도 피해가 작게"라는 틀로 적는다. 막는 장치가 아니라 피해 반경을 줄이는 장치다.

설정 lever(조절 수단)의 함정

Agent SDK 의 allowedTools 는 "묻지 않고 실행" 목록이다. 목록 밖 도구는 남아 있다. 도구를 없애려면 disallowedTools 에 이름만 적는다.
MCP connector 는 서버를 붙이면 기본이 "모든 도구 켬" 이다. 읽기 전용이면 쓰기·파괴 도구를 꺼야 한다.

남겨야 하는 강한 도구

먼저 "정말 역할에 필요한가"를 묻는다. 필요하면 남기고 실행 직전 코드 검사(훅)와 사람 확인을 붙인다. 이 경우에는 확인창이 정답 쪽이다.

규칙과 판단

역할에 필요 없으면 빼고, 필요한 읽기 도구는 남기며, 꼭 필요한 강한 도구는 PreToolUse 훅으로 실행 직전 검사하는 결정 나무와 표면별 빼는 방법. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

갈림길

①⑤ 첫 수 [3.1①]

역할에 필요한 능력인가?

아니오

뺀다

첫 수는 빼기다. 역할이 안 쓰는 도구는 설정에서 제거한다

예

쓰기·파괴 도구인가?

아니오 (읽기)

남긴다

필요한 읽기 도구는 그대로 남긴다. 읽기 전용 도우미면 쓰기·파괴 도구만 denylist 에 넣는다

예 (정말 필요한 강한 도구)

실행 직전에 검사한다

도구를 남기고 실행 직전에 PreToolUse 훅으로 검사한다. 이 훅은 모든 호출 전에 돈다. 훅의 거부는 bypassPermissions 에서도 먹힌다

① 보기 가르기 [3.1①] [5.1③]

그 보기가 능력을 없애나?

예

제거다

공격면(attack surface) 자체가 사라진다

아니오

무엇인가?

로그

사후 감지다

로그는 사후 감지(detective)다. 제거가 아니다

확인창

보완 통제다

확인창은 보완 통제(compensating control)다. 제거가 아니다

더 큰 모델

무관하다

모델 크기는 권한 범위와 무관하다

system prompt 에 '삭제 금지'

안내일 뿐이다

안내일 뿐 강제가 아니다. 도구가 있으면 불릴 수 있다 업계 일반

② 빼는 lever [3.1①]

어느 surface 인가?

직접 API

tools 배열에 안 넣는다

업계 일반 준 도구만 부를 수 있는 구조

MCP connector

denylist · allowlist

쓰기·파괴 도구를 denylist 로 끈다(enabled: false). 또는 allowlist 를 쓴다. default_config.enabled: false 로 모두 끄고 필요한 것만 켠다

Agent SDK

disallowedTools

도구 이름만 적는다(예 "Bash"). 그러면 정의가 요청에서 빠져 Claude 가 못 본다. allowedTools 는 자동 승인일 뿐이다. 목록 밖 도구도 그대로 남는다

나머지 규칙

③
도구 말고도 : 아래 능력도 좁힌다 [3.2③]
- 파일 : 필요한 디렉토리만 읽기 전용으로 준다
- 네트워크 : 프록시로 특정 엔드포인트만 연다
- 자격증명 : 프록시가 주입한다(에이전트는 못 본다)
- 컨테이너 : Linux capability 를 뗀다
④
인젝션 대비도 같은 처방이다 [5.1②]
- 필요 없는 비밀은 주지 않는다
- 도구는 샌드박스에서 실행한다
- 권한 범위는 최대한 좁게 둔다
경로 끊기는 ■ 프롬프트 인젝션 피해 경로 끊기 에 있다
OAuth scope 도 최소부터 받고 필요할 때 올린다. 자세한 것은 ■ MCP 인증·인가 에 있다

규칙 원문 ①②⑤ (갈림길로 그린 규칙)

첫 수는 빼기다. 역할이 안 쓰는 도구는 설정에서 제거한다 [3.1①] [5.1③] [6.2②]

로그는 사후 감지(detective)이고, 확인창은 보완(compensating) 통제다. 둘 다 제거가 아니다. 모델 크기는 권한 범위와 무관하다

빼는 lever(조절 수단)는 surface(쓰는 환경)마다 다르다

surface	빼는 법
직접 API	`tools` 배열에 안 넣는다 업계 일반 준 도구만 부를 수 있는 구조
MCP connector (원격 서버째 못 뺀다)	쓰기·파괴 도구를 denylist 로 끈다(`enabled: false`). 또는 allowlist 를 쓴다. `default_config.enabled: false` 로 모두 끄고 필요한 것만 켠다
Agent SDK	`disallowedTools` 에 도구 이름만 적는다(예 `"Bash"`). 그러면 정의가 요청에서 빠져 Claude 가 못 본다. `allowedTools` 는 자동 승인일 뿐이다. 목록 밖 도구도 그대로 남는다

정말 필요한 강한 도구면 남기고 실행 직전에 검사한다. Claude Code 와 Agent SDK 에서는 PreToolUse 훅을 쓴다

이 훅은 모든 호출 전에 돈다. 훅의 거부는 bypassPermissions 에서도 먹힌다

사람 확인은 위험 크기에 맞춰 건다 업계 일반 목록 6.2② 근거 문서 미열람

필요한 읽기 도구는 그대로 남긴다. 읽기 전용 도우미면 쓰기·파괴 도구만 denylist 에 넣는다

더 깊이 : 판단 규칙 · 상황 변수 (설명)

판단 규칙

조건	답	근거
역할이 안 쓰는 도구가 붙어 있다	설정에서 제거한다	가이드 샘플 1 정답 B "Least privilege means removing capabilities the role does not require"
보기에 로그·확인창·더 큰 모델이 섞였다	셋 다 제거보다 약하다	샘플 1 해설 "Logging (A) and confirmations (C) are detective/compensating controls … model size (D) is unrelated to authorization scope"
원격 MCP 서버를 connector 로 붙였고 읽기만 필요하다	쓰기·파괴 도구를 denylist 에 넣는다 (또는 allowlist 로 필요한 것만 켠다)	mcp-connector
Agent SDK 에서 도구를 없애야 한다	`disallowedTools` 에 이름만 적는다	agent-sdk permissions
인젝션이 성공해도 피해를 줄이고 싶다	비밀을 주지 않는다. 샌드박스를 쓴다. 권한을 최소로 둔다	mitigate-jailbreaks
에이전트 환경의 파일·네트워크·키를 정한다	필요한 디렉토리만 읽기 전용으로 준다. 프록시로 엔드포인트를 제한한다. 키는 프록시가 주입한다	secure-deployment 표
강한 도구가 역할에 꼭 필요하다	남기고 실행 직전에 검사한다(훅)	agent-sdk permissions "use a PreToolUse hook … a hook deny applies even in bypassPermissions mode"

상황 변수

변수	값	답 쪽	등급	근거
그 도구가 역할에 필요한가	아니요	제거한다		판단 규칙 1
그 도구가 역할에 필요한가	예(가끔)	남기고 실행 전 검사와 사람 확인을 붙인다	(훅) · 업계 일반(사람 확인을 위험 크기에 비례해 거는 것)	판단 규칙 7
도구가 어디서 오나	내 코드 `tools`	배열에서 뺀다	업계 일반	준 도구만 부를 수 있다
도구가 어디서 오나	원격 MCP 서버 묶음	도구 단위로 denylist/allowlist 를 쓴다		mcp-connector
도구가 어디서 오나	Agent SDK 내장 도구	`disallowedTools` 를 쓴다		permissions
위협	인젝션(믿을 수 없는 콘텐츠를 읽는다)	권한을 최소로 두고 외부 전송을 끊는다		■ 프롬프트 인젝션 피해 경로 끊기
배포	개발자 노트북 1대	기본 보안 기능으로 충분할 수 있다		secure-deployment "Not every deployment needs maximum security."
배포	여러 고객 데이터를 다루는 멀티테넌트	격리·프록시·최소 IAM 을 겹겹이 둔다		secure-deployment

연습 문제

상담 에이전트는 주문 조회와 답장 초안만 한다읽기·초안만. 그런데 설정에는 영업팀이 예전에 붙인 환불 도구와 고객 삭제 도구안 쓰는 도구가 그대로 남아 있다. 누군가 "환불·삭제 전에 확인창을 띄우자"고 한다. 첫 수는 무엇인가?

시험 대비

함정

"도구는 두고 환불·삭제 전에 확인 단계를 둔다" (샘플 1 C) 는 함정이다. 보완 통제일 뿐이다
"로그를 달아 나중에 감사한다" (샘플 1 A) 는 함정이다. 사후 감지다
"지시를 잘 따르는 더 큰 모델로 바꾼다" (샘플 1 D) 는 함정이다. 모델 크기는 권한 범위와 무관하다
"system prompt 에 '삭제 금지' 를 적는다" 는 함정이다. 안내일 뿐 강제가 아니다. 도구가 있으면 불릴 수 있다 업계 일반 CCA-F 노트 2.3 "다 주고 프롬프트로 '쓰지 마'" 와 같은 함정
"allowedTools 에 읽기 도구만 적었으니 나머지는 막혔다" 는 함정이다. 막히지 않는다. 목록 밖 도구는 남아서 권한 모드로 넘어간다. 빼려면 disallowedTools 를 쓴다
반대쪽 함정도 있다. "확인창 보기는 항상 오답이다" 는 함정이다. 필요해서 남긴 강한 도구에는 실행 전 검사와 사람 확인이 맞는 통제다 (업계 일반 + ⑤)

신호

"Least privilege means removing capabilities the role does not require, eliminating the attack surface rather than monitoring or guarding it." (가이드 샘플 1)

"Logging (A) and confirmations (C) are detective/compensating controls, not removal of unnecessary privilege; model size (D) is unrelated to authorization scope." (샘플 1)

"Denylisting write or destructive tools is recommended when building read-only assistants, or when you want a human confirmation step before state changes"

"Apply the principle of least privilege so that a successful injection can do minimal damage"

"To put a tool out of Claude’s reach entirely, add its bare name to disallowedTools."

보통은 필요 없는 도구를 아예 빼지만, 환불이 실제 업무면 남기고 실행 전 검사를 붙이고, 한 서버에 섞였으면 도구 단위로 끄고, 허용 목록만으론 안 빠져 disallowedTools 를 쓴다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게) — 자세한 조건은 아래 '더 깊이'에 있어요

더 깊이 : 뒤집히는 때 · 오답 재료 (설명)

뒤집히는 때

1. 확인창이 정답이 되는 때

조건 : 강한 도구(환불)가 역할의 실제 업무다. 영업팀 요구가 아니라 상담원이 실제로 환불을 처리한다.
판단 : 빼면 업무가 안 된다. 최소 권한(least privilege)은 "필요한 것만"이지 "0" 이 아니다. 남기고 실행 직전 검사(한도·대상 확인)와 사람 확인을 붙인다.
등급 : (훅) · 업계 일반(위험 비례 사람 검토)
근거 : permissions · 목록 6.2② "필요하면 오류 비용·잡을 수 있는지에 비례해"
시험에서 : 지문이 "상담원은 읽기·초안만"이라 말하면 제거가 답이다. "환불도 상담원 업무"라 말하면 제거 보기는 업무를 깨는 오답이 될 수 있다.

2. 서버째 뺄 수 없는 때

조건 : 사내 원격 MCP 서버 하나에 읽기·쓰기 도구가 20개 섞여 있고, 서버를 떼면 읽기 도구까지 잃는다.
판단 : 서버 단위가 아니라 도구 단위로 끈다. connector 는 configs 로 도구별 enabled: false 를 준다.
근거 : mcp-connector

3. `allowedTools` 로 잠갔다고 믿는 때

조건 : SDK 설정이 allowedTools: ["Read", "Grep"] 뿐이다.
판단 : 목록 밖 도구도 존재한다. 승인이 필요한 호출은 권한 모드로 넘어간다(모드에 따라 실행될 수 있다). 잠그려면 dontAsk 모드와 짝을 짓는다. 없애려면 disallowedTools 를 쓴다.
근거 : permissions

4. 합친 도구가 권한 단위를 섞는 때

조건 : 도구 설계에서 github_pr 하나에 action = list·review·merge 를 합쳤다(■ 도구 설계 · 규칙 ①). 리뷰 전용 에이전트는 머지가 안 돼야 한다.
판단 : 도구 하나를 빼면 읽기까지 사라진다. 두면 머지까지 남는다. 권한 경계가 다른 동작은 도구를 나누거나, 실행 직전 검사로 action 값을 막는다.
등급 : 업계 일반 (두 공식 권고인 합치기와 최소 권한을 같이 쓸 때의 추론)
근거 : define-tools · 샘플 1 · permissions

오답 재료

오답	왜 끌리나	왜 틀리나	등급	근거
"환불·삭제 전에 확인 단계를 붙인다"	안전해 보이고 업무도 안 깨진다	도구가 남으니 공격면이 그대로다. 보완 통제(compensating control)일 뿐이다		샘플 1 해설
"로그를 달아 나중에 감사"	규정 감사에 익숙하다	사후 감지다. 일이 난 뒤에 알게 된다		샘플 1 해설
"지시를 더 잘 따르는 큰 모델"	오용을 모델 실수로 본다	모델 크기는 권한 범위와 무관하다		샘플 1 해설
"system prompt 에 '삭제 도구 쓰지 마'"	비용이 0 이고 바로 적용된다	안내일 뿐이다. 도구가 있으면 불릴 수 있다	업계 일반	CCA-F 노트 2.3 같은 함정
"`allowedTools` 에 필요한 것만 적었다"	이름이 '허용 목록'이라 나머지는 막힌 것 같다	자동 승인 목록일 뿐이다. 나머지 도구도 남는다		permissions
"지우면 나중에 곤란하니 두고 감시"	되돌리기 쉬워 보인다	공식은 "지켜보기가 아니라 없애기"를 말한다		샘플 1 정답 문장
"확인창 보기는 항상 오답" (반대 함정)	샘플 1 을 외웠다	역할에 필요한 강한 도구면 남기고 실행 전 검사와 확인을 붙이는 것이 맞다	업계 일반	뒤집히는 때 1

참고

더 깊이 : CCA-F · 출처 · 상태 · 미해결 (참고)

CCA-F

겹침 — CCA-F 는 "서브에이전트마다 역할에 필요한 도구만(18개 → 4~5개)"을 **고르기 정확도**로 물었다. 여기서는 같은 빼기를 **보안(공격면)** 근거로 묻는다. 보기에 로그·확인창·큰 모델이 섞여 나온다

출처

가이드 목표 3.1 공식 시험 가이드 v1.0
샘플 1 공식 시험 가이드 v1.0
mcp-connector
mitigate-jailbreaks
agent-sdk permissions
secure-deployment
CCA-F 노트 2.3 (개인 학습 노트)

상태

업계 일반 4줄

미해결

사람 확인을 위험 등급에 맞춰 거는 규칙(목록 6.2② "Creating multiple risk levels…")은 확인하지 못했다. content-moderation 문서를 이번에 받지 않았다. 6.2② 카드 때 확인한다.
system prompt 규칙이 "안내일 뿐 강제 아님"이라는 공식 문장은 이번 원문들에서 못 찾았다. 검색어는 "enforce", "guidance" 다. 찾아본 문서는 secure-deployment · mitigate-jailbreaks · agent-sdk permissions en 이다. 업계 일반으로 둔다.
목록 3.1① 의 "서버째 뺄 수 없는 원격 MCP 면 denylist" 는 원문 그대로 확인했다. 다만 원문은 denylist 를 "사람 확인 단계를 두고 싶을 때"도 권한다. 여기서 '확인 단계'는 에이전트가 상태를 못 바꾸게 하고 사람이 바꾸는 뜻으로 읽힌다(추론).