안전띠 없는 AI는 위험하다: 에이전트 보안 및 엔터프라이즈 거버넌스 완전 가이드

AI 에이전트가 개발 생산성을 200% 끌어올린다는 건 이제 모두 안다. 하지만 그 AI가 .env 파일의 비밀번호를 읽어버리거나, 없는 파일을 있다고 착각하고 정상 파일을 연쇄 삭제한다면? 안전띠 없는 스포츠카는 빠르기만 할 뿐 위험하다. 이 글에서는 AI 에이전트의 파일 접근 제어부터 엔터프라이즈 MCP 보안, 그리고 치명적 실수를 막는 거버넌스 전략까지 총정리한다.

1. AI 에이전트의 파일 접근 권한 통제

AI를 똑똑한 신입사원이라고 생각하자. 일은 잘하지만, 회사의 비밀번호가 적힌 금고(.env)를 열어보거나 시스템 폴더를 삭제하면 큰일이다. 주요 AI 코딩 도구별로 제공하는 보안 자물쇠를 비교해보자.

Cursor: `.cursorignore` — 투명 망토 씌우기

Cursor IDE에서는 .cursorignore 파일을 만들어 특정 파일에 투명 망토를 씌울 수 있다.

# .cursorignore
.env
.env.*
*.log
*.pem
secrets/
node_modules/

이 파일에 적힌 항목은 AI의 인덱싱과 읽기에서 완전히 제외된다. AI 눈에는 아예 존재하지 않는 파일이 된다.

⚠️ 치명적 한계: AI에게 터미널 사용 권한을 줬다면, cat .env 같은 셸 명령어로 우회 접근이 가능하다. .cursorignore는 에디터 레벨의 차단이지, 시스템 레벨의 차단이 아니기 때문이다.

진짜 중요한 비밀 파일은 프로젝트 폴더 밖(워크스페이스 외부)으로 빼두는 것이 가장 안전하다.

Codex: 샌드박스 + 승인 모드 — 목줄 길이 조절

OpenAI의 Codex는 AI의 자유도를 모드로 조절할 수 있다.

모드	AI가 할 수 있는 것	AI가 할 수 없는 것
Read-only	코드 읽기, 분석, 설명	파일 수정, 생성, 삭제 일체 불가
Auto	폴더 내 안전한 작업 자율 수행	폴더 밖 접근, 외부 네트워크 연결 시 승인 필요

Auto 모드에서 AI가 위험한 행동을 시도하면 반드시 사람에게 "이거 해도 돼요?" 라고 물어본다. 목줄의 길이를 상황에 맞게 조절하는 것이다.

Claude Code: `settings.json` — 가장 촘촘한 제어

Claude Code는 세 도구 중 가장 세밀한 권한 제어를 제공한다. .claude/settings.json에 세 단계 규칙을 설정할 수 있다.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/*.pem)",
      "Read(**/secrets/**)",
      "Bash(cat *.env*)",
      "Bash(grep * .env)"
    ],
    "ask": [
      "Write(./production/**)",
      "Write(./database/**)",
      "Bash(rm *)",
      "Bash(DROP *)"
    ],
    "allow": ["Read(./src/**)", "Write(./src/**)", "Write(./tests/**)"]
  }
}

규칙	동작	사용 예시
deny	절대 금지. 묻지도 않고 차단	`.env`, 인증서, 시크릿 파일
ask	실행 전 반드시 사용자 승인 요청	프로덕션 코드 수정, 위험한 셸 명령
allow	자유롭게 허용 (매번 묻지 않음)	소스 코드, 테스트 코드

Cursor의 .cursorignore와 달리, Claude Code의 deny 규칙은 Bash 명령어까지 차단할 수 있다. Bash(cat *.env*)를 deny에 넣으면 터미널 우회까지 막을 수 있는 것이다.

3대 도구 보안 수준 비교

기능	Cursor	Codex	Claude Code
파일 읽기 차단	✅	✅	✅
파일 쓰기 제어	❌	✅ (모드)	✅ (세밀)
터미널 우회 방지	❌	✅ (샌드박스)	✅ (Bash deny)
규칙 세밀도	파일 단위	모드 단위	글로브 패턴 + 도구 단위
추천 대상	간단한 프로젝트	통제된 환경	엔터프라이즈, 민감 프로젝트

2. 엔터프라이즈 MCP 보안: 무분별한 외부 툴 연결 막기

회사 규모가 커지면 새로운 위험이 생긴다. 직원이 편하겠다고 검증되지 않은 MCP 서버를 마음대로 연결해서, 회사 코드나 고객 데이터를 외부로 유출시키는 섀도우 IT(Shadow IT) 문제다.

문제: 섀도우 IT

김개발: "이 MCP 서버 연결하면 코드 분석이 편해지는데..."
       → 검증되지 않은 외부 서버에 회사 소스 코드 전송
       → 💀 보안 사고 발생

개인이 좋은 의도로 설치한 도구가 회사 전체의 보안 구멍이 된다.

해결: `managed-mcp.json` 중앙 통제

IT 관리자가 관리자 권한으로만 수정 가능한 managed-mcp.json 파일을 전 사원의 컴퓨터에 배포한다. 이 파일이 존재하면 직원은 마음대로 새 MCP 도구를 추가할 수 없다.

통제 방식 2가지

독재 모드 (Exclusive Control) — "이것만 써라"

관리자가 허용한 도구 이외에는 일체 사용 불가.

{
  "exclusive": true,
  "servers": {
    "company-github": {
      "command": "mcp-github",
      "args": ["--org", "our-company"]
    },
    "company-db": {
      "command": "mcp-postgres",
      "args": ["--host", "db.internal.company.com"]
    }
  }
}

사내 공식 GitHub, 사내 DB만 연결 가능하고, 나머지는 모두 차단된다. 보안이 최우선인 금융·의료·공공 기관에 적합하다.

정책 기반 모드 (Allow/Denylist) — "이건 돼, 저건 안 돼"

직원들에게 어느 정도 자유를 주되, 울타리를 쳐두는 방식이다.

{
  "exclusive": false,
  "policy": {
    "allow": ["https://*.company.com/*", "https://github.com/our-company/*"],
    "deny": ["https://unknown-server.io/*", "http://*"]
  }
}

규칙	설명
allow	회사 도메인, 공식 GitHub 등 허용
deny	미검증 서버, HTTP(비암호화) 연결 차단
우선순위	deny가 항상 allow보다 우선

deny 목록에 걸리면, allow에 포함되어 있어도 묻지도 따지지도 않고 차단된다. 방화벽의 차단 규칙이 허용 규칙보다 항상 우선하는 것과 같은 원리다.

3. AI 에이전트의 실시간 실패 감지와 거버넌스

단순한 챗봇 시대에는 "오답"이 최대 위험이었다. 하지만 AI가 스스로 계획을 세우고 도구를 조작하는 에이전트 시대에는, 훨씬 무서운 위협이 등장했다.

연쇄 사고 (Cascade Failure)

AI가 첫 단추를 잘못 꿰면 연쇄적으로 사고가 확대된다.

AI: "config.json 파일을 읽어야 한다"
    ↓
없는 파일명을 있다고 착각 (환각/Hallucination)
    ↓
"파일을 못 읽겠다... 권한 문제인가?"
    ↓
권한을 바꾸겠다며 시스템 파일 수정 시도
    ↓
에러 발생 → "충돌하는 파일들을 정리하겠다"
    ↓
💀 정상 파일 연쇄 삭제

AI는 각 단계에서 논리적으로 행동한다고 믿고 있다. 하지만 첫 전제(파일이 존재한다)가 틀렸기 때문에, 이후의 모든 행동이 재앙으로 이어진다.

"사람이 확인하면 되잖아?"가 실패하는 이유

위험을 막으려면 AI가 행동할 때마다 사람에게 승인 버튼을 누르게 하면 될까? 이론적으로는 맞지만, 현실에서는 반드시 실패한다.

경고 피로 (Alert Fatigue):

[1번째 알림] "파일을 읽겠습니다" → 꼼꼼히 확인 → 승인 ✅
[5번째 알림] "테스트를 실행하겠습니다" → 확인 → 승인 ✅
[27번째 알림] "파일을 수정하겠습니다" → 대충 보고 승인 ✅
[58번째 알림] "이 파일을 삭제하겠습니다" → 안 보고 승인 ✅ ← 💀

하루에 수백 번씩 알림이 오면, 사람은 내용을 보지 않고 반사적으로 승인을 누르게 된다. 이를 자동화 편향(Automation Bias) 이라고 한다. 결국 사람이 있어도 사고를 막지 못한다.

해결: 자동화된 실패 감지 시스템

사람 대신 또 다른 AI(Monitor 모델)나 규칙 기반 시스템이 에이전트의 행동을 실시간으로 감시해야 한다.

분류 및 개입 전략 (Triage Framework)

모든 AI 행동을 두 가지 기준으로 분류한다: 되돌릴 수 있는가? 와 위험도는 얼마나 높은가?

분류	특성	대응 전략	예시
Low Stakes (사소한 오류)	되돌리기 쉬움 (Reversible)	시스템이 자동 재시도 또는 후속 수정. 사람 개입 불필요	캘린더 일정 오입력, 들여쓰기 오류, 파일명 오타
High Stakes (치명적 오류)	되돌릴 수 없음 (Irreversible)	즉시 정지(Halt) + 사람에게 에스컬레이션	자금 이체, 대량 데이터 삭제, 전체 고객 메일 발송

감시 시스템이 잡아야 할 위험 신호 (Red Flags)

위험 신호	설명	대응
목표 이탈 (Goal Drift)	AI가 원래 지시와 무관한 작업을 시작	경고 → 정지
반복 실패 (Retry Loop)	같은 작업을 3회 이상 실패하며 반복	정지 → 에스컬레이션
권한 상승 시도	주어진 권한 이상의 접근을 시도	즉시 차단
대량 변경	한 번에 다수의 파일 삭제/수정 시도	승인 요청
외부 통신	허가되지 않은 외부 API 호출	즉시 차단

거버넌스 아키텍처

[AI 에이전트] ── 행동 로그 ──→ [Monitor 시스템]
      │                              │
      │                    ┌─────────┴─────────┐
      │                    │ 위험도 판단        │
      │                    │ Low → 자동 처리    │
      │                    │ High → 정지 + 알림 │
      │                    └─────────┬─────────┘
      │                              │ (High Stakes만)
      ↓                              ↓
  [작업 수행]                   [사람에게 알림]
                            "AI가 production DB를
                             DROP하려고 합니다.
                             승인하시겠습니까?"

핵심은 모든 행동에 사람을 끼우는 게 아니라, 위험도가 높은 행동에만 선별적으로 사람을 개입시키는 것이다. 이렇게 하면 경고 피로 없이도 치명적 사고를 막을 수 있다.

📝 요약 (치트시트)

주제	핵심 포인트
파일 접근 제어	Cursor: `.cursorignore`(터미널 우회 가능) / Codex: 샌드박스+모드 / Claude Code: `settings.json` deny/ask/allow (가장 촘촘)
MCP 중앙 통제	`managed-mcp.json`으로 독재 모드(허용 도구만) 또는 정책 모드(Allow/Deny 규칙). deny가 항상 우선
실패 감지	연쇄 사고 방지: Monitor 시스템이 행동 감시 → Low Stakes는 자동 처리, High Stakes는 즉시 정지+에스컬레이션
경고 피로 해결	모든 행동에 승인 요구 ❌ → 되돌릴 수 없는 행동에만 선별적 개입 ✅

한 줄 요약: AI 에이전트는 강력한 도구지만, 안전띠 없는 스포츠카는 위험하다. .cursorignore부터 managed-mcp.json, 실시간 실패 감지까지 — 안전망을 먼저 구축하는 것이 진정한 AI 도입의 첫걸음이다.