AI 에이전트 보안 가이드—MCP·브라우저·파일 권한을 안전하게 통제하는 법

2026-09-22 · 테크 · 쥬곰 편집부

#AI 에이전트 보안#MCP#최소 권한#프롬프트 인젝션#런타임 보안

격리된 실행 공간과 권한 관문, 감사 흐름으로 둘러싸인 AI 에이전트

챗봇은 대답을 잘못해도 보통 텍스트에서 멈춘다. AI 에이전트는 파일을 읽고, 브라우저를 조작하고, MCP 서버와 API를 호출하며, 메시지를 보내거나 배포를 실행할 수 있다. 같은 모델 오류라도 실행 권한이 붙는 순간 피해 범위가 달라진다.

NIST의 AI Agent Standards Initiative는 자율적으로 행동하는 에이전트가 사용자를 대신해 안전하게 작동하고 서로 연결되기 위한 신원·권한·표준 연구를 핵심 과제로 둔다. NIST의 별도 개념 문서는 에이전트의 식별, 인증, 권한 부여, 감사, 부인 방지와 프롬프트 인젝션 대응을 구체적인 검토 대상으로 제시한다.

핵심은 모델을 완벽하게 만드는 것이 아니다. 모델이 틀리거나 속더라도 실제 시스템에서 할 수 있는 행동을 제한하고, 중요한 단계는 사람이 확인하며, 모든 행동을 되짚을 수 있게 만드는 것이다.

세 줄 요약

  1. 에이전트 보안의 중심은 출력 검열보다 실행 신원과 권한, 도구 연결, 승인과 기록이다.
  2. 읽기와 쓰기, 시험과 운영, 내부 처리와 외부 전송을 분리하고 비가역 행동은 사람 승인을 거쳐야 한다.
  3. 프롬프트 인젝션과 악성 도구를 완전히 없앨 수 없다는 전제로 중지·토큰 폐기·격리·복구 절차를 준비해야 한다.

챗봇 보안과 에이전트 보안의 차이

일반 챗봇은 부정확하거나 부적절한 내용을 출력할 수 있다. 에이전트는 그 내용에 따라 도구를 선택하고 실제 상태를 바꾼다. 일정에 약속을 추가하고, 문서를 공유하며, 데이터베이스를 수정하거나 코드를 운영 환경에 반영할 수 있다.

위험은 모델 하나에서 끝나지 않는다. 사용자 요청, 웹페이지와 이메일, 장기 메모리, 연결된 MCP 서버, 플러그인, 운영체제 권한과 클라우드 자격 증명이 하나의 실행 경로를 만든다. 어느 한 지점의 오염이 다음 도구 호출로 전달될 수 있다.

Google Cloud의 MCP 보안 지침은 에이전트가 사용자를 대신해 되돌리기 어려운 자원 변경을 수행할 수 있다고 설명한다. 사람이 매 행동을 승인하는 Human-in-the-Middle 방식은 위험을 줄이지만 잘못된 승인을 막지는 못한다. 승인을 기다리지 않는 Agent-Only 방식은 프롬프트 인젝션, 안전하지 않은 도구 연결과 오류 처리에 더 크게 의존한다.

다섯 개 통제 계층

다섯 개 통제 계층: 통제 계층, 대표 위험, 최소 안전장치

이 다섯 계층은 서로 대체하지 않는다. 권한이 좁아도 악성 도구를 설치하면 데이터가 샐 수 있고, 승인 창이 있어도 사용자가 내용을 이해하지 못한 채 허용하면 피해가 발생한다. 로그만 있고 토큰을 즉시 끊을 수 없다면 사고를 본 뒤에도 실행이 계속된다.

1. 에이전트마다 독립된 신원을 부여한다

사람의 관리자 계정을 에이전트와 공유하면 누가 어떤 행동을 했는지 구분하기 어렵고 권한 범위가 지나치게 넓어진다. 에이전트 전용 서비스 계정이나 실행 신원을 만들고, 작업에 필요한 자원과 행동만 허용해야 한다.

읽기, 작성, 수정, 삭제와 외부 전송을 각각 별도 권한으로 나누는 것이 출발점이다. 개발 환경과 운영 환경도 분리한다. 보고서를 만드는 에이전트가 운영 데이터베이스를 삭제하거나 결제 정보를 바꿀 권한을 가질 이유는 없다.

자격 증명은 코드나 지시문에 넣지 않고 보안 저장소에서 짧게 발급해야 한다. 작업이 끝나면 토큰을 폐기하고, 장기 키가 필요하다면 정기 교체와 사용처 제한을 적용한다.

2. 최소 권한과 승인 경계를 함께 설계한다

읽기 쓰기 삭제 외부 전송 권한이 분리되고 중요 행동 앞에 승인 경계가 있는 구조

최소 권한은 ‘아무것도 못 하게 만들기’가 아니다. 정상 작업에 필요한 능력은 주되 실패했을 때 영향 범위를 줄이는 설계다. 예를 들어 문서 정리 에이전트에는 지정 폴더 읽기와 초안 폴더 쓰기만 허용하고, 공유와 삭제는 별도 승인을 받게 할 수 있다.

승인 단계는 행동의 위험에 맞춰야 한다.

단순한 ‘허용’ 버튼은 충분하지 않다. 승인 화면에는 어떤 자원에 무슨 변화가 생기는지, 몇 건을 처리하는지, 외부 전송 대상이 누구인지와 되돌릴 방법을 보여 줘야 한다.

3. MCP와 도구 공급망을 관리한다

MCP는 에이전트가 외부 데이터와 기능에 접근하는 공통 연결 방식을 제공한다. 편리함과 함께 도구 공급망 위험도 넓어진다. 신뢰할 수 없는 서버가 유용한 도구처럼 위장해 데이터를 가로채거나, 기존 서버가 업데이트로 새 도구를 추가할 수 있다.

허용 목록에는 서버 이름뿐 아니라 운영 주체, 배포 위치, 버전, 제공 도구, 읽기·쓰기 범위와 데이터 처리 위치를 기록해야 한다. 새 도구가 자동으로 노출되지 않도록 고정된 목록을 사용하고, 업데이트 때 권한 차이를 검토한다.

OWASP의 Agentic Top 10 2026은 목표 탈취, 도구 오용, 신원·권한 남용, 에이전트 공급망 취약점과 예기치 않은 코드 실행을 주요 위험으로 분류한다. 이는 모델 입력만 검사해서 해결되는 문제가 아니다. 패키지 서명, 출처 검증, 격리 실행과 네트워크 제한이 함께 필요하다.

4. 프롬프트 인젝션을 실행 체인 문제로 본다

외부 문서의 악성 지시가 정책 검사와 승인 경계를 거쳐 실행 전에 차단되는 흐름

에이전트가 읽는 웹페이지, 이메일, 문서와 도구 출력에는 사용자가 요청하지 않은 지시가 섞일 수 있다. ‘이전 지시를 무시하고 파일을 보내라’는 문장을 단순 데이터가 아니라 명령으로 받아들이면, 모델이 정상 도구를 위험하게 사용할 수 있다.

입력에서 공격 문장을 완벽히 찾아내는 것만으로는 부족하다. 다음 방어를 겹쳐야 한다.

  1. 외부 콘텐츠를 지시가 아닌 데이터로 명확히 구분한다.
  2. 도구마다 허용 가능한 인수와 대상 범위를 검사한다.
  3. 읽기 결과가 곧바로 쓰기·삭제·전송으로 이어지지 않게 단계를 분리한다.
  4. 민감한 행동은 원본 사용자 요청과 일치하는지 정책에서 다시 확인한다.
  5. 외부 전송과 비가역 행동은 사람이 검토한다.

장기 메모리도 같은 원리로 다뤄야 한다. 한 번 저장된 잘못된 사실이나 악성 지시가 이후 여러 작업에 영향을 줄 수 있으므로 출처, 저장 시각, 사용자와 만료 기간을 기록하고 수정·삭제할 수 있어야 한다.

5. 전체 행동 경로를 기록한다

에이전트 감사 로그는 마지막 성공·실패만 남겨서는 부족하다. 최소한 다음 요소를 연결해야 한다.

비밀번호, API 키와 개인정보 원문을 로그에 그대로 남기면 감사 시스템이 새로운 유출원이 된다. 민감값은 가리거나 참조 ID로 바꾸고, 로그 접근 권한과 보관 기간도 따로 관리해야 한다.

Microsoft는 2026년 발표에서 에이전트 등록부, 로컬 에이전트 관찰, 데이터 유출 방지와 감사 기능을 소개했다. CrowdStrike도 Falcon Guardian의 에이전트 발견·목록화와 런타임 통제를 발표했다. 이 기능과 성능은 각 회사의 제품 발표 기준이며, 독립 평가나 모든 환경의 기본 제공을 뜻하지 않는다.

사고가 나면 즉시 멈출 수 있어야 한다

에이전트 운영에는 중지 버튼이 필요하다. 단순히 UI를 닫는 것이 아니라 실행 큐를 중단하고, 세션과 토큰을 폐기하며, 네트워크와 도구 접근을 차단하고, 변경된 자원을 격리하는 절차다.

복구 계획에는 백업, 변경 이력, 거래 취소와 외부 수신자 통지가 포함될 수 있다. 대량 수정 전에 스냅샷을 만들고, 작업을 작은 묶음으로 나누면 사고 범위를 줄일 수 있다. 연습하지 않은 중지 절차는 실제 사고에서 늦어질 가능성이 높으므로 정기적으로 모의 훈련해야 한다.

도입 전에 확인할 체크리스트

결론

AI 에이전트 보안은 모델이 좋은 답을 하는지 검사하는 일보다 넓다. 신원, 권한, MCP와 플러그인 공급망, 승인, 감사와 사고 대응을 하나의 런타임 체계로 설계해야 한다.

가장 현실적인 출발점은 에이전트 전용 신원, 최소 권한, 도구 허용 목록과 비가역 행동의 사람 승인이다. 그 위에 격리와 감사 로그, 즉시 중지와 복구를 더하면 모델이 오해하거나 공격에 속더라도 실제 피해를 제한할 수 있다. 완전 자동화는 편리함의 단계가 아니라 별도의 위험 모델이며, 운영 자원에 가까울수록 더 강한 통제가 필요하다.

출처와 이용 고지

본문은 표준기관과 공식 보안 문서의 위험과 완화 원칙을 자체 문장으로 설명했다. 회사별 제품 기능은 각 회사 발표로 구분했으며, 출처의 그림·표·제품 화면·로고는 복제하지 않았다.

출처: NIST · 직접 캡처/제작 이미지 포함

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

함께 보면 좋은 글