에이전트 권한은 프롬프트가 아니라 런타임 계약이다

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: AI 에이전트에게 도구를 붙일 때, “하지 말라”는 프롬프트와 실제 권한 제어는 어떻게 나눠야 할까?
• 핵심 출처:
  • Guardrails and human review | OpenAI API - 게시일 미표기, 확인일 2026-06-09
  • Configure permissions - Claude Code Docs - 게시일 미표기, 확인일 2026-06-09
  • Authorization - Model Context Protocol - draft 문서, 확인일 2026-06-09
  • Tools - Model Context Protocol - draft 문서, 확인일 2026-06-09
  • How we built Claude Code auto mode: a safer way to skip permissions - 2026-03-25, 확인일 2026-06-09

1. 왜 지금 봐야 하나

요즘 에이전트 개발에서 가장 위험한 착각은 “모델에게 주의하라고 말했으니 안전하다”는 생각이다. LLM은 도구를 호출하고, 파일을 수정하고, 외부 API를 치고, MCP 서버를 통해 사용자의 데이터에 접근한다. 여기서 실패는 단순히 답변이 틀리는 수준이 아니다. 잘못된 셸 명령, 권한 없는 데이터 조회, 과도한 API 호출, 운영 DB 변경 같은 실제 부작용으로 이어질 수 있다.

최근 주요 에이전트 런타임 문서들이 공통으로 강조하는 방향은 분명하다. 프롬프트는 “무엇을 시도할지”를 유도하지만, 권한 시스템은 “무엇이 실제로 실행될 수 있는지”를 결정해야 한다. OpenAI Agents 문서는 guardrail과 human review를 통해 실행을 계속할지, 멈출지, 일시정지할지를 나누라고 설명한다. Claude Agent SDK는 allow/deny 규칙, permission mode, hook, 런타임 callback을 별도 평가 순서로 둔다. MCP authorization draft는 HTTP 기반 MCP 서버를 OAuth resource server로 보고, token audience와 scope를 매 요청에서 검증해야 한다고 말한다.

즉, 에이전트 설계의 핵심 질문은 “어떤 모델이 더 똑똑한가”에서 “어떤 행동을 어떤 조건에서 실행하게 할 것인가”로 이동하고 있다.

2. 핵심 개념

에이전트 권한 설계는 세 층으로 나눠서 보면 이해하기 쉽다.

첫째, 의도 층이다. 시스템 프롬프트, 작업 지시, specialist agent instruction이 여기에 속한다. “운영 데이터는 수정하지 마라”, “사용자 승인 없이는 결제 취소를 하지 마라” 같은 문장이다. 이 층은 모델의 선택을 줄여주지만 보안 경계는 아니다. 프롬프트 인젝션, 과잉 수행, 오해, 툴 출력 오염이 생기면 모델은 여전히 위험한 호출을 시도할 수 있다.

둘째, 검사 층이다. input guardrail, output guardrail, tool guardrail, hook, classifier가 여기에 속한다. 호출 전 인자를 검사하거나, 호출 후 결과를 redact하거나, 위험한 패턴을 차단한다. OpenAI 문서는 함수 tool call 주변의 argument/result는 tool guardrail로 검사하고, 취소·편집·셸 명령·민감한 MCP action 같은 부작용은 human-in-the-loop approval로 pause하라고 안내한다.

셋째, 집행 층이다. 실제 런타임이 tool을 숨기거나, deny rule을 우선 적용하거나, OAuth scope가 없으면 401/403으로 거절하는 부분이다. Claude Agent SDK 문서에서 중요한 점은 allowed_tools가 “허용 목록으로 제한”이 아니라 “사전 승인 목록”이라는 것이다. bypassPermissions 모드에서는 listed tool만 허용되는 것이 아니라, 그 단계까지 도달한 모든 tool이 승인될 수 있다. 반대로 deny rule은 bypassPermissions에서도 차단될 수 있다. 권한의 의미는 이름이 아니라 평가 순서에서 결정된다.

3. 최신 이슈와 연결

MCP는 에이전트 도구 생태계의 공통 인터페이스가 되고 있다. MCP tools draft는 tool list가 authorization credential/scope에 따라 달라질 수 있고, tool annotation은 신뢰된 서버에서 온 것이 아니라면 untrusted로 봐야 한다고 설명한다. 또한 도구는 model-controlled로 설계되지만, 보안상 필요한 경우 사용자가 호출을 거부할 수 있어야 하며, 애플리케이션은 어떤 도구가 노출되는지와 언제 호출되는지를 보여줘야 한다.

MCP authorization draft도 중요한 전환점을 보여준다. HTTP 기반 MCP 서버가 보호된 리소스라면, 서버는 OAuth Protected Resource Metadata를 제공하고, 클라이언트는 authorization server discovery를 수행하며, access token은 MCP 서버라는 target resource에 대해 발급된 것인지 검증해야 한다. scope가 부족하면 런타임에 step-up authorization을 요구할 수 있다. 이것은 “도구 설명에 관리자용이라고 써둔다”가 아니라, 네트워크 경계에서 권한을 다시 확인하라는 뜻이다.

Anthropic의 auto mode 글은 다른 현실 문제를 짚는다. 권한 프롬프트가 너무 많으면 사용자는 대부분 승인하게 되고, 실제 검토 품질은 떨어진다. Anthropic은 Claude Code 사용자들이 permission prompt의 93%를 승인한다고 밝히며, auto mode를 수동 승인과 무권한 실행 사이의 절충안으로 소개했다. 다만 이 글은 classifier가 완벽하지 않다는 점도 명시한다. 실제 overeager action 데이터에서 full pipeline의 false negative rate가 17%였다는 수치를 공개하며, auto mode는 고위험 인프라 작업에서 꼼꼼한 인간 검토를 대체하는 기능이 아니라고 선을 긋는다.

4. 개발자 관점 해석

에이전트를 제품에 넣을 때 권한은 “UX 귀찮음”이 아니라 시스템 계약이다. 특히 다음 세 가지 실패 모드를 구분해야 한다.

첫 번째는 모델의 과잉 수행이다. 사용자가 “브랜치 좀 정리해줘”라고 했을 때, 에이전트가 원격 브랜치까지 대량 삭제한다면 의도 해석은 맞는 듯 보이지만 승인 범위를 넘은 것이다. 이런 문제는 “조심해” 프롬프트보다 blast radius가 큰 tool에 explicit approval을 붙이는 방식이 더 낫다.

두 번째는 경계 혼동이다. 에이전트가 테스트 DB와 운영 DB, 개인 repo와 조직 repo, 내부 도메인과 외부 도메인을 구분하지 못할 수 있다. 이 경우 권한 정책은 tool 이름보다 resource boundary를 알아야 한다. 예를 들어 query_database라는 하나의 tool이라도 env=prod이면 승인 필요, env=dev이면 자동 허용처럼 나뉘어야 한다.

세 번째는 권한 피로다. 모든 호출을 묻는 시스템은 안전해 보이지만, 사용자가 계속 “예”만 누르면 사실상 무권한 실행과 비슷해진다. 권한 설계의 목표는 prompt 수를 늘리는 것이 아니라, 묻지 않아도 되는 행동과 반드시 멈춰야 하는 행동을 분리하는 것이다.

실무적으로는 다음 원칙이 유용하다. 읽기 전용 도구는 넓게, 쓰기 도구는 좁게, 외부 전송은 더 좁게, 삭제·결제·배포·운영 변경은 승인 기반으로 둔다. 그리고 권한 결과는 반드시 로그로 남긴다. 에이전트 사고를 디버깅하려면 “모델이 왜 그랬나”보다 “어떤 tool call이 어떤 정책을 통과했나”가 먼저 필요하다.

5. 내 프로젝트에 적용할 체크포인트

• 도구를 위험도별로 분류했는가? read-only, local write, external read, external write, destructive action, production action으로 나눠본다.
• allow list를 제한으로 착각하고 있지 않은가? 사용하는 SDK에서 allow가 “도구를 숨기는지”, “사전 승인만 하는지”, “permission mode 이후에도 의미가 있는지” 확인한다.
• deny가 가장 먼저 이기는가? shell, delete, deploy, credential, production endpoint에 대해 deny/ask rule의 우선순위를 문서로 남긴다.
• tool argument를 검사하는가? rm -rf, DROP TABLE, force push, 외부 URL, credential-like string, prod environment 같은 인자 조건을 호출 전 검사한다.
• MCP 서버는 token audience와 scope를 검증하는가? 단순히 bearer token 존재만 보지 말고, 그 token이 해당 MCP server/resource용인지 확인한다.
• step-up authorization이 가능한가? 처음부터 모든 scope를 요구하지 말고, 민감 tool 호출 시 추가 권한을 요구하는 흐름을 고려한다.
• 승인 state를 저장하고 재개할 수 있는가? human review가 필요한 실행은 새 대화를 시작하지 말고 동일 run state를 pause/resume하는 구조가 안전하다.
• 권한 로그가 남는가? requested_tool, arguments_hash, policy_decision, approver, resource, timestamp, run_id 정도는 남겨야 나중에 재현할 수 있다.

6. 오늘 10분 액션

오늘은 코드 작성보다 표 하나를 만든다. 내 프로젝트의 AI 기능 또는 자동화 스크립트에서 모델이 호출할 수 있는 도구를 모두 적고, 아래 형식으로 10분만 분류해보자.

Tool	읽기/쓰기	외부 전송	운영 영향	기본 정책	추가 메모
search_docs	읽기	없음	낮음	자동 허용	결과 길이 제한
write_file	쓰기	없음	중간	ask	프로젝트 디렉터리만
run_shell	쓰기 가능	가능	높음	ask 또는 deny	명령 패턴 검사
deploy_prod	쓰기	외부	매우 높음	human approval	승인자와 로그 필수
call_mcp_admin	읽기/쓰기	외부	높음	scope + approval	token audience 검증

그다음 하나만 바꾼다. 가장 위험한 tool 하나에 대해 “프롬프트 금지 문구”가 아니라 실제 런타임 차단 조건을 추가한다. 예를 들어 Bash(rm *)는 deny, deploy는 human approval, prod 인자는 approval required처럼 작게 시작하면 된다.

7. 더 볼 자료

• OpenAI Agents의 guardrails/human review 문서: guardrail과 approval을 어디에 붙일지 감을 잡기 좋다.
• Claude Agent SDK permissions 문서: allow/deny/permission mode의 평가 순서를 확인하자.
• MCP Authorization draft: MCP 서버를 OAuth resource server로 볼 때 어떤 metadata, scope, audience 검증이 필요한지 정리되어 있다.
• MCP Tools draft: tool list, schema, tool annotation, human-in-the-loop 표시 요구를 볼 수 있다.
• Anthropic auto mode engineering post: 권한 피로와 classifier 기반 승인 자동화의 장단점을 현실적으로 설명한다.

중복 회피 메모

로컬 content/generated와 Supabase의 최근 ai_dev 글을 확인했다. 직전 AI 글은 긴 컨텍스트, compaction, 구조화 메모리, RAG 참조 관리에 집중했다. 이번 글은 context 관리가 아니라 에이전트 tool use의 권한 평가 순서, MCP authorization, human approval, permission fatigue라는 런타임 안전 계약에 집중해 관점을 분리했다.