DEEP DIVE REPORT

AI 에이전트 외부도구 접근통제 사례연구: 권한 위임·샌드박싱·감사로그 점검표

SecurityDesk
2026.08.01 조회 21

핵심 요약

AI 에이전트의 외부도구 호출은 “모델이 어떤 말을 했는가”보다 “어떤 주체가 어떤 범위의 권한으로, 어떤 실행 환경에서, 어떤 증적을 남기며 호출했는가”로 통제해야 한다. 이 글은 특정 기업의 실제 사고가 아니라, 공식 보안·표준 문서를 바탕으로 만든 참조 아키텍처 사례다. 목표는 에이전트가 티켓 시스템과 고객 데이터 조회 도구를 사용하되, 프롬프트 인젝션·과도한 권한·자격증명 노출이 업무 변경이나 데이터 유출로 이어지지 않게 하는 것이다.

사례: 고객지원 에이전트에 “읽기와 제안”만 부여하기

가상의 고객지원 에이전트는 ① 지식베이스 검색, ② CRM에서 고객 티켓·계약 상태 조회, ③ 운영자에게 답변 초안 제시를 수행한다. 그러나 결제 환불, 계정 권한 변경, 대량 내보내기는 별도 승인 없이는 실행하지 않는다. 이 분리는 OWASP가 에이전트 환경에서 다루는 과도한 자율성·도구 오용 위험과 연결된다[3].

1. 권한 위임: 사용자 권한을 그대로 넘기지 않는다

도구마다 에이전트 전용 서비스 아이덴티티를 만들고, 사용자·테넌트·작업 목적을 요청 컨텍스트로 전달한다. 토큰은 다음처럼 좁힌다.

  • CRM 조회: tickets:read, contracts:read만 허용하고, tenant_idcustomer_id를 서버 측 정책에서 강제한다.
  • 지식베이스: 승인된 컬렉션만 검색한다. 웹 URL을 임의로 가져오는 도구와 내부 문서 검색 도구를 같은 권한으로 묶지 않는다.
  • 변경·송신: refund:create, user:role:update, email:send는 기본 거부한다. 필요 시 사람의 재인증·승인으로 한 번 쓰는 작업 토큰을 발급한다.

MCP의 권한부여 규격은 OAuth 기반 권한부여 흐름과 리소스 서버 검증을 정의하며, 클라이언트가 토큰을 다른 서버에 전달하는 토큰 패스스루를 금지한다[2]. 따라서 에이전트 오케스트레이터가 받은 CRM 토큰을 다른 도구 서버로 재사용해서는 안 된다. 각 도구 서버가 자신의 audience·scope·만료·발급자를 검증해야 한다.

2. 도구 계약과 정책 결정 지점(PDP)

도구 호출은 자연어가 아니라 검증 가능한 스키마로 바꾼다. 예를 들어 get_ticket({ticket_id})는 UUID 형식과 현재 테넌트 소속을 확인하고, draft_reply({ticket_id, body})는 초안만 반환한다. send_reply는 별도 도구로 분리하고 승인 ID 없이는 호출을 거절한다.

오케스트레이터 앞의 PDP는 매 호출에 대해 다음을 판정한다.

  1. 호출 주체(에이전트 아이덴티티), 요청 사용자, 테넌트가 유효한가?
  2. 도구·메서드·리소스·행위가 해당 작업에 필요한 최소 범위인가?
  3. 입력에 외부 콘텐츠가 섞였는가? 섞였다면 그 콘텐츠를 명령이 아닌 비신뢰 데이터로 표시했는가?
  4. 변경·송신·고위험 조회라면 승인 토큰, 금액/건수 한도, 재인증 조건을 만족하는가?
  5. 허용 결과가 데이터 분류·마스킹 정책을 위반하지 않는가?

이는 NIST AI RMF가 조직적 위험관리 기능을 GOVERN, MAP, MEASURE, MANAGE로 제시하는 방식[1]과, NIST SP 800-53의 최소 권한(AC-6)·감사 이벤트(AU-2)·감사 기록 내용(AU-3) 통제 목적에 맞춘 구현 예시다[4]. NIST 문서는 제품별 구현을 지시하지 않으므로, 위 매핑은 본 사례의 설계 판단임을 명시한다.

3. 샌드박싱: 도구 실행 권한과 런타임 권한을 분리한다

브라우저·코드 실행·파일 처리 도구는 별도 워크로드로 격리한다.

  • 작업별 임시 컨테이너/브라우저 프로필, 읽기 전용 기본 파일시스템, 작업 종료 시 폐기
  • 아웃바운드 네트워크는 허용 목록과 프록시를 통과; 메타데이터 IP·내부 관리망·클라우드 자격증명 엔드포인트는 차단
  • 실행 ID와 시크릿은 작업별·단기 발급; 모델 프롬프트와 도구 출력에 비밀값을 넣지 않음
  • 다운로드 파일은 악성코드 검사와 형식 검증 뒤 격리 저장; 원본 URL의 지시문은 명령으로 취급하지 않음
  • CPU·메모리·실행시간·API 호출 횟수·전송량에 상한 적용

도구 사용 자체는 모델의 응답을 실제 시스템 동작으로 바꾸므로, 도구 정의·입력 검증·실행 결과 처리가 보안 경계가 된다. Anthropic의 도구 사용 문서도 도구 정의가 입력 스키마를 포함하는 API 계약임을 설명한다[5]. 여기서 샌드박스는 모델 판단의 정확도를 보장하는 장치가 아니라, 잘못된 판단이나 악성 입력의 영향 반경을 줄이는 방어층이다.

4. 감사로그: 재현 가능한 “결정-호출-결과” 체인을 남긴다

로그에는 원문 프롬프트나 토큰을 무분별하게 저장하지 않는다. 대신 다음의 상관관계 ID를 모든 레코드에 묶는다.

  • request_id, agent_run_id, user_id/tenant_id(가명 또는 내부 식별자), 정책 버전
  • 도구 이름·메서드·정규화된 리소스 식별자·요청한 scope·PDP 허용/거부 사유
  • 승인자·승인 ID·승인 시각·한도, 실행 환경/이미지 버전
  • 결과 코드·수정된 객체 수·전송량·오류 분류·해시값

민감한 도구 인수나 응답은 별도 접근통제 저장소에 최소 보존하고, 운영 로그에는 마스킹·해시·요약만 남긴다. NIST SP 800-53의 AU-2/AU-3는 감사 대상 이벤트와 기록 내용의 정의를 요구하므로[4], 이 필드 목록은 사고 조사와 정책 검증을 위해 그 목적을 구체화한 것이다.

운영 점검표

배포 전

  • [ ] 도구별 데이터 분류, 허용 행위, 최대 건수·금액, 소유자와 폐기일을 목록화했다.
  • [ ] 에이전트 전용 아이덴티티와 도구별 audience/scope를 사용하며, 장기 공유 자격증명이 없다.
  • [ ] 읽기·초안·변경·외부 송신 도구가 분리돼 있고, 변경/송신은 사람 승인 또는 강한 정책 조건을 요구한다.
  • [ ] 서버 측에서 테넌트·객체 소유권·허용 목록을 검증한다. 모델이 만든 ID나 URL만 믿지 않는다.
  • [ ] 외부 문서·웹페이지·첨부파일의 명령을 비신뢰 데이터로 분리하고, 프롬프트 인젝션 테스트를 통과했다.
  • [ ] 실행 환경의 네트워크·파일·시크릿·시간·자원 한도가 테스트됐다.

운영 중

  • [ ] 허용/거부/승인/실행 결과가 동일한 agent_run_id로 추적된다.
  • [ ] 고위험 호출의 급증, scope 확대, 대량 조회·전송, 반복 거부를 탐지하고 경보 기준을 정했다.
  • [ ] 정책·도구 스키마·샌드박스 이미지 변경은 버전과 승인 기록을 남긴다.
  • [ ] 정기적으로 권한을 재검토하고, 사용하지 않는 도구·시크릿·통합을 회수한다.

사고 대응

  • [ ] 해당 에이전트 아이덴티티·작업 토큰·통합을 즉시 중지할 수 있다.
  • [ ] agent_run_id에서 입력 출처, PDP 결정, 도구 요청, 결과까지 재구성할 수 있다.
  • [ ] 영향을 받은 객체·테넌트·전송량을 산정하고, 필요하면 승인·정책·도구 스키마를 수정한 뒤 회귀 테스트한다.

결론

외부도구 접근통제의 핵심은 “에이전트에게 도구를 줄 것인가”가 아니라 “도구별로 최소 권한·서버 측 정책·격리·승인·증적을 어떻게 결합할 것인가”다. 읽기와 쓰기를 분리하고, 토큰을 목적·대상·시간에 맞게 좁히며, 로그를 결정과 결과까지 연결하면 에이전트의 유용성을 유지하면서도 통제 가능한 운영 기반을 마련할 수 있다.

출처 및 검증 메모

[1] NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023. GOVERN·MAP·MEASURE·MANAGE 기능 정의. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

[2] Model Context Protocol, Authorization Specification (2025-06-18). OAuth 기반 권한부여, 리소스 서버 검증 및 토큰 패스스루 금지. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization

[3] OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications. 에이전트 애플리케이션의 위험 범주와 방어 고려사항. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications/

[4] NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (Update 1). AC-6(최소 권한), AU-2(감사 이벤트), AU-3(감사 기록 내용). https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

[5] Anthropic, Tool use overview. 도구 정의와 입력 스키마 기반의 도구 호출 모델. https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.

댓글 (0)

댓글을 작성하려면 로그인이 필요합니다.

로그인

아직 댓글이 없습니다.

첫 번째 댓글을 작성해보세요!

IT 도구 서랍

→ Unix: 2025-01-15T09:30:00
→ 날짜: 1736934600

→ ASCII: ABC
→ 문자: 65 66 67

ASCII 코드표 — 클릭하면 입력란에 추가

DecHex약어설명
DecHex문자
DecHex문자

→ 유니코드: 홍길동
→ 문자: \ud64d\uae38\ub3d9