AI 에이전트 권한도 코드처럼 관리한다: 허용·승인·차단을 나누는 실무 기준

결론부터

AI 코딩 에이전트를 쓸 때 이제 질문은 “쓸까 말까”가 아니다. 질문은 더 구체적이다.

이 에이전트가 읽어도 되는 것, 고쳐도 되는 것, 실행해도 되는 것, 밖으로 보내도 되는 것을 누가 어떻게 정하는가?

2026년 9월 GitHub는 Copilot Business·Enterprise 관리자가 에이전트 작업을 중앙에서 차단, 사람 승인, 자동 진행으로 나눌 수 있는 managed permissions를 공개했다.[1] shell command, file read/edit, network domain이 정책 대상이다. Anthropic도 Claude Managed Agents에서 toolset별 permission policy를 두고, server-executed tool과 MCP tool이 자동 실행될지 승인 대기할지 설정하게 한다.[2]

이 흐름이 중요한 이유는 간단하다. 에이전트가 답만 하던 시기에는 “모델이 틀릴 수 있다”가 핵심 리스크였다. 에이전트가 쉘을 실행하고, 파일을 고치고, MCP 서버를 호출하고, 외부 도메인으로 나가는 순간 리스크는 “틀린 말”이 아니라 틀린 행동이 된다.

기준 시점은 2026년 9월 16일이다. 아래 내용은 GitHub Copilot changelog와 GitHub Docs, Anthropic Claude Platform·Claude Code 문서를 바탕으로 정리했다.[1][2][3][4][5][6]

왜 갑자기 권한표가 중요해졌나

코딩 에이전트는 사람이 터미널에서 하던 일을 대신한다. grep으로 찾고, 파일을 읽고, 패치를 만들고, 테스트를 돌리고, 가끔은 외부 문서를 가져오거나 MCP 서버로 이슈를 만든다. 이 자체는 편하다. 문제는 편한 만큼 권한 경계가 흐려진다는 점이다.

예전 자동화는 대체로 스크립트 단위였다.

스크립트 A: 빌드만 한다
스크립트 B: 배포만 한다
스크립트 C: 리포트만 만든다

에이전트는 다르다. 같은 대화 안에서 읽기, 쓰기, 실행, 네트워크, 외부 API 호출이 섞인다. 그래서 “이 도구를 켤까?”보다 “이 도구가 어떤 입력에서 어떤 권한으로 실행될까?”를 봐야 한다.

GitHub가 말한 managed permissions의 의미도 여기에 있다. 개인이 한 번 누른 “다시 묻지 않기”나 workspace 설정, auto-approval로 기업 정책을 약화할 수 없게 한다.[1] 즉, 권한은 기분이나 습관이 아니라 운영 정책이 된다.

세 칸으로 시작하면 덜 무섭다

처음부터 복잡한 보안 프레임워크를 만들 필요는 없다. 실제로 많은 도구가 비슷한 세 칸을 쓴다.

• allow: 자동으로 실행해도 된다.
• ask: 실행 전 사람 승인이 필요하다.
• deny: 아예 막는다.

Anthropic Managed Agents의 permission policy는 always_allow와 always_ask를 제공한다. agent toolset은 기본적으로 always_allow, MCP toolset은 기본적으로 always_ask다.[2] Claude Agent SDK는 hooks, deny rules, ask rules, permission mode, allow rules, canUseTool callback 순서로 권한을 평가한다고 설명한다.[4] OpenCode도 allow, ask, deny 규칙을 permission config로 둔다.[7]

이 구조에서 중요한 건 “자동 허용을 얼마나 넓힐까”가 아니다. 좋은 기본값은 보통 반대다.

작업	기본값	이유
repo 안 파일 읽기	allow	코드 이해에 필요하고 되돌릴 필요가 없다. 단, .env, credential, 개인 파일은 별도 차단한다.
검색, 목록 보기	allow	탐색 비용을 줄인다. 민감 경로는 deny를 먼저 둔다.
테스트 실행	ask 또는 allow	프로젝트에 따라 안전하다. 다만 외부 네트워크·긴 실행·비용이 붙으면 ask가 낫다.
파일 수정	ask	diff를 보고 승인해야 한다. 문서-only 작업처럼 범위가 좁을 때만 allow를 고려한다.
shell command	ask	읽기 명령과 파괴적 명령이 섞인다. 패턴별 예외를 둔다.
rm, 권한 변경, 배포, 결제, 메일 발송	deny 또는 ask	되돌리기 어렵거나 외부 영향이 있다.
새 MCP 서버 연결	ask 또는 deny	서버 하나가 새 API 권한 묶음이 될 수 있다.
외부 도메인 접속	ask/allowlist	코드·로그·비밀값 유출 경로가 될 수 있다.

이 표는 보안팀이 있는 회사에만 필요한 것이 아니다. 개인 자동화도 똑같다. 블로그 초안 생성, 이미지 생성, 미리보기 업로드, 배포처럼 단계가 나뉜 시스템에서는 “초안은 자동, 발행은 승인” 같은 경계가 이미 존재한다. 그 경계를 파일과 정책으로 남기면 된다.

네트워크 차단은 만능이 아니다

GitHub Copilot coding agent에는 firewall 설정이 있다. GitHub 문서는 firewall을 끄면 Copilot이 어떤 host에도 연결할 수 있고, code나 민감 정보가 유출될 위험이 커진다고 경고한다.[3] GitHub의 agentic security 원칙 글도 Copilot coding agent에 firewall을 적용해 외부 리소스 접근을 제한한다고 설명한다.[5]

좋은 소식이다. 하지만 여기서 멈추면 안 된다. GitHub Docs의 제한 사항에는 중요한 문장이 있다. firewall은 에이전트가 Bash tool로 시작한 프로세스에 적용되며, MCP 서버나 configured setup steps에서 시작한 프로세스에는 적용되지 않는다.[3]

이건 “GitHub가 부족하다”는 비판이 아니다. 운영자가 봐야 할 경계가 하나 더 있다는 뜻이다.

확인할 네트워크 경계
1. 에이전트의 shell/process outbound
2. MCP 서버 자체의 outbound
3. setup step, bootstrap script, package install 단계
4. 브라우저/웹 fetch 도구
5. 로그·trace·analytics exporter

MCP도 마찬가지다. GitHub는 enterprise managed settings에 allowedMcpServers, deniedMcpServers를 추가해 URL, local command, server name 기준으로 MCP 서버를 허용·차단할 수 있게 했다.[6] 특히 정책이 fail closed라고 설명한다. 설정이 malformed이거나 검증 불가능하면 허용이 아니라 차단으로 간다.[6]

이 방향이 맞다. MCP 서버는 “도구 하나”가 아니라 외부 시스템으로 가는 문이다. GitHub, Slack, Notion, DB, 내부 admin API가 MCP로 붙으면 에이전트 권한표는 곧 API 권한표가 된다.

권한은 사람이 이해할 수 있어야 한다

사람 승인을 넣는다고 자동으로 안전해지지는 않는다. 승인 카드가 “Bash를 실행할까요?”처럼 뭉뚱그려져 있으면 사람은 결국 습관적으로 누른다. 좋은 승인 흐름은 최소한 네 가지를 보여줘야 한다.

1. 무엇을 실행하는가: 명령, 파일 경로, MCP tool 이름, 도메인.
2. 왜 필요한가: 에이전트가 이 작업을 요청한 이유.
3. 영향 범위는 어디인가: repo 안인지, 외부 시스템인지, 비용·배포·삭제가 있는지.
4. 대안은 있는가: read-only 확인으로 충분한지, dry-run이 가능한지.

Claude Code 쪽 문서가 설명하는 canUseTool callback은 이런 런타임 승인 흐름을 만들 수 있는 지점이다.[4] GitHub Copilot CLI도 specific tool, subcommand, MCP tool을 --allow-tool, --deny-tool로 지정할 수 있고, deny rule이 allow보다 우선한다고 설명한다.[8]

여기서 실무 팁은 단순하다. ask를 너무 많이 만들면 사람은 지친다. 그래서 승인이 필요한 작업을 줄이려면 모든 것을 allow로 푸는 게 아니라, 안전한 read-only 경로를 많이 만들어야 한다.

예를 들면 다음과 같다.

• production 로그는 쓰기 권한 없는 query view로만 제공한다.
• 배포는 에이전트가 직접 하지 않고 “배포 PR” 또는 “승인 대기 job”만 만든다.
• 외부 API 호출은 raw token이 아니라 제한된 RPC stub을 통한다.
• 파일 수정은 특정 디렉터리, 특정 확장자, 특정 작업 브랜치로 좁힌다.
• 네트워크는 패키지 레지스트리와 공식 문서 도메인만 기본 허용한다.

“권한 as code”로 남겨야 하는 이유

권한을 UI에서만 관리하면 시간이 지나며 기억이 사라진다. 누가 왜 허용했는지, 팀별로 무엇이 다른지, 새 도구가 들어왔을 때 어떤 기준으로 판단했는지 남지 않는다.

그래서 앞으로 에이전트 설정은 .env보다 policy에 가까워진다.

{
  "read": {
    "src/**": "allow",
    ".env*": "deny"
  },
  "edit": {
    "docs/**": "ask",
    "src/content/blog/**": "ask",
    "src/data/itNews.ts": "deny"
  },
  "bash": {
    "git status*": "allow",
    "npm test": "allow",
    "npm run build": "allow",
    "npx wrangler deploy*": "ask",
    "rm *": "deny"
  },
  "network": {
    "docs.github.com": "allow",
    "platform.claude.com": "allow",
    "unknown": "ask"
  }
}

이 예시는 특정 도구의 그대로 쓸 설정 파일이 아니라 사고방식 예시다. 중요한 건 repo에 남고, 리뷰되고, 바뀐 이유가 commit에 남는다는 점이다.

이렇게 해두면 “에이전트가 사고 쳤다”를 사후 감정 문제로 끝내지 않을 수 있다. 정책이 너무 넓었는지, 승인 카드가 부실했는지, 네트워크 allowlist가 빠졌는지, MCP 서버 검증이 없었는지로 나눠서 고칠 수 있다.

바로 가져갈 체크리스트

오늘 할 일은 거창하지 않다. 지금 쓰는 에이전트와 자동화를 아래 표에 넣어보면 된다.

질문	적어볼 것
에이전트가 읽는 입력은 무엇인가?	issue, PR, 웹페이지, 고객 로그, 내부 문서, 모델 출력
자동 허용할 read-only 작업은 무엇인가?	repo 탐색, 테스트 로그 읽기, 공식 문서 fetch
승인 없이는 안 되는 작업은 무엇인가?	파일 수정, shell 실행, 외부 API 호출, 비용 발생 작업
무조건 차단할 작업은 무엇인가?	secret 읽기, 기본 브랜치 직접 push, production DB write, 결제·메일 발송
네트워크는 어디까지 열려 있는가?	패키지 레지스트리, 공식 문서, MCP 서버, unknown domain
MCP 서버는 누가 승인했는가?	URL/command/name 기준 allowlist, owner, 목적, 권한 범위
감사 로그에 남는 것은 무엇인가?	요청자, tool name, 입력, 승인자, 결과, diff, 외부 호출
실패하면 어떻게 되돌리는가?	PR revert, deployment rollback, token revoke, job cancel

내 자동화 기준으로도 이 표는 바로 쓸 수 있다. 초안 생성은 자동이어도 된다. 이미지 생성은 비용과 품질 검수가 있어야 한다. 미리보기 업로드는 괜찮지만, 발행과 배포는 Owner 승인 뒤에만 실행해야 한다. 이 경계가 말로만 있으면 매번 다시 판단해야 하지만, 정책 파일과 로그로 남기면 운영이 된다.

FAQ

Q. 작은 팀이나 개인 프로젝트에도 필요한가?

필요하다. 다만 enterprise 수준의 중앙 관리부터 시작할 필요는 없다. 먼저 allow / ask / deny 표를 만들고, secret 읽기·배포·삭제·외부 발송만 확실히 막아도 효과가 크다.

Q. auto-approve를 쓰면 안 되나?

쓸 수 있다. 다만 read-only, 테스트, 정해진 경로의 문서 수정처럼 영향 범위가 좁은 작업에 먼저 쓰는 편이 낫다. GitHub changelog가 말하듯 managed restrictions는 auto-approval이나 saved approval로 약화되지 않아야 한다.[1]

Q. MCP 서버는 왜 특별히 조심해야 하나?

MCP 서버는 에이전트에게 새 손과 새 통로를 붙인다. 서버 하나가 GitHub issue 생성, Slack 메시지 발송, DB 조회, 내부 API 호출을 감쌀 수 있다. 그래서 서버 단위 allowlist와 tool 단위 ask/deny가 같이 필요하다.[6]

Q. 방화벽을 켜면 충분한가?

충분하지 않다. GitHub Docs도 Copilot coding agent firewall이 Bash tool로 시작한 프로세스에 적용되고, MCP 서버나 setup steps에는 적용되지 않는다고 설명한다.[3] 에이전트 본체의 outbound와 연결된 도구의 outbound를 따로 봐야 한다.

Q. 제일 먼저 바꿀 설정 하나만 고른다면?

deny부터 정한다. secret 파일, production write, default branch 직접 push, irreversible action, unknown MCP server, unknown external domain을 먼저 막는다. 그다음 반복해서 안전하다고 확인된 read-only 작업만 allow로 올린다.

한 줄 정리

AI 에이전트 운영의 좋은 기본값은 “더 똑똑한 모델이면 괜찮다”가 아니다. 권한을 작게 주고, 위험한 행동은 승인 카드로 멈추고, 절대 하면 안 되는 일은 코드로 차단하는 것이다.

오늘 적용할 1가지

지금 쓰는 에이전트나 자동화 하나를 골라서 read, edit, shell, network, MCP, deploy 여섯 줄짜리 권한표를 만든다. 각 줄에 allow / ask / deny를 하나씩 적고, ask와 deny에 해당하는 실제 예시 명령이나 도메인을 붙인다. 이 작은 표가 나중에 정책 파일, 승인 UI, 감사 로그의 초안이 된다.

출처

[1] GitHub Changelog, “Enterprise managed permissions for GitHub Copilot agent operations”, 2026-09-09.
[2] Anthropic Claude Platform Docs, “Permission policies”.
[3] GitHub Docs, “Customizing or disabling the firewall for GitHub Copilot coding agent”.
[4] Claude Code Docs, “Configure permissions”.
[5] GitHub Blog, “How GitHub’s agentic security principles make our AI agents as secure as possible”.
[6] GitHub Changelog, “MCP allowlists in enterprise managed settings”, 2026-08-06.
[7] OpenCode Docs, “Permissions”.
[8] GitHub Docs, “Allowing and denying tool use”.

타깃 유입 키워드

AI agent permissions, GitHub Copilot managed permissions, Claude permission policies, MCP allowlist, AI coding agent security, 에이전트 권한 관리, AI 자동화 승인 게이트