운영 AI 에이전트 보안·개인정보 설정 체크리스트: ID부터 철회 테스트까지

Microsoft Entra Agent ID 권고를 중심으로 운영 AI 에이전트의 인벤토리, 최소 권한, 도구 승인, 개인정보 보존, 감사 로그와 철회 테스트를 설정·검증하는 절차를 정리합니다.

AI 보안·개인정보작성 읽기 약 4분
AIAI 도구AI 사용법official_source_rescue생성형 AI

작성 정보

발행

작성 방식 — AI 도구를 활용해 초안을 작성하고 출처 링크, 공개 상태, 문서 구조와 내부 링크를 자동 규칙으로 검사합니다.

운영 환경의 AI 에이전트는 먼저 누가 어떤 데이터와 도구에 접근하는지를 인벤토리로 확인한 뒤, 에이전트별 전용 ID와 작업 범위 권한을 적용해야 합니다. 그다음 검토된 도구만 허용하고, 영향이 큰 행동에는 승인 절차를 둡니다. 마지막으로 로그와 권한 철회를 실제로 시험해야 설정이 정상인지 판단할 수 있습니다.

여기서 최소 권한은 에이전트에 필요한 권한만 주는 방식입니다. 권한이 적어 보이더라도 도구를 자유롭게 호출하거나 쓰기 작업을 곧바로 실행할 수 있다면 운영 위험은 남습니다. 아래 절차는 Microsoft Entra Agent ID의 공식 최소 권한 권고를 중심으로, 개인정보·메모리·로그 관리까지 함께 점검하는 방법입니다.

1. 시작 전: 에이전트와 접근권한을 인벤토리화한다

첫 단계는 현재 배포된 에이전트뿐 아니라 배포 예정인 에이전트와 도구 통합을 모두 적는 일입니다. Microsoft Learn의 최소 권한 권고는 교차 테넌트와 게스트 통합도 포함하고, 처음 요청부터 하위 시스템까지 이어지는 종단 간 유효 총권한을 확인하라고 안내합니다.

인벤토리에는 적어도 다음 정보를 남깁니다.

  • 에이전트의 이름과 역할
  • 연결된 도구·플러그인·통합
  • 접근 가능한 데이터와 대상 리소스
  • 교차 테넌트 또는 게스트 경로
  • 실제로 적용되는 역할과 권한 범위

중요한 점은 오케스트레이터, 즉 에이전트의 작업 흐름을 조정하는 계층에 설정한 권한만 확인하지 않는 것입니다. 도구 호출 뒤에 연결되는 시스템에서도 해당 요청이 인가되는지까지 확인해야 합니다.

2. 에이전트마다 고유 ID와 책임자를 지정한다

공유 계정이나 사람의 계정을 에이전트가 그대로 쓰게 두면, 나중에 누가 어떤 권한으로 작업했는지 분명히 추적하기 어렵습니다. Microsoft Learn은 각 에이전트에 고유한 전용 ID를 부여하고, 이름이 명시된 소유자·스폰서·승인자를 지정하도록 권고합니다.

이때 문서로 남길 항목은 단순한 담당자 이름에 그치지 않습니다. 다음 범위를 함께 기록합니다.

  • 에이전트의 목적
  • 승인된 데이터 접근 범위
  • 도구 종속성
  • 운영 환경

Microsoft Entra Agent ID는 조직에서 AI 에이전트 ID를 관리·보호·거버넌스하기 위한 기능으로 소개됩니다. 다만 이 접근의 핵심은 제품을 도입했다는 사실보다, 각 에이전트의 정체성과 책임 범위가 분명하게 운영되는 데 있습니다.

3. 역할은 작업 단위로 좁히고, 도구는 기본 거부한다

인벤토리가 끝났다면 넓게 부여된 역할을 작업 기반의 더 좁은 역할과 범위로 바꿉니다. 예를 들어 정보를 읽어 요약하는 작업과 데이터를 변경하는 작업은 같은 권한으로 묶지 않는 편이 좋습니다. Microsoft Learn은 과도하게 넓은 역할을 더 제한된 작업 범위 할당으로 대체하라고 권고합니다.

도구·플러그인·통합도 같은 원칙을 적용합니다. 검토되지 않은 연결은 기본적으로 거부하고, 필요한 도구와 행동만 허용 목록에 넣습니다. Microsoft Security Blog는 MCP 연결에서 Allow all을 끄고 에이전트에 필요한 특정 도구만 활성화하라고 안내합니다. MCP는 에이전트가 외부 도구나 데이터 원본을 호출할 때 쓰는 연결 방식입니다.

도구를 허용할 때는 이름만 보고 판단하지 않는 것이 좋습니다. Microsoft Security Blog는 도구 설명과 메타데이터도 에이전트가 읽는 작업 맥락의 일부가 될 수 있으므로, 중요한 에이전트에서는 변경 사항을 검토하라고 설명합니다.

4. 고위험 작업은 승인 게이트로 분리한다

데이터 변경, 권한 관련 작업처럼 영향이 큰 행동은 에이전트가 곧바로 실행하지 않도록 분리합니다. Microsoft Learn은 도구·행동 허용 목록을 두고, 권한 작업에는 승인 기반 또는 시간 제한 권한 승격을 고려하도록 권고합니다.

시간 제한 권한 승격은 필요한 순간에만 일시적으로 높은 권한을 주고, 이후에는 그 권한이 계속 남지 않게 하는 방식입니다. Microsoft Learn은 권한 작업에서 JIT(Just-In-Time) 승격도 검증 대상으로 제시합니다.

Microsoft Security Blog 역시 금융 데이터 접근, 외부 공유, 계정 변경처럼 고영향 행동에는 사람의 승인을 거치도록 구성할 수 있다고 안내합니다. 따라서 승인 게이트는 모든 작업에 일괄 적용하기보다, 에이전트가 무엇을 읽고 무엇을 바꾸는지 구분한 뒤 쓰기·변경·권한 작업에 우선 배치하는 방식이 적합합니다.

5. 개인정보 데이터·메모리·로그의 경계를 정한다

개인정보 통제는 입력 데이터에만 적용해서는 충분하지 않습니다. Microsoft의 Azure Cloud Adoption Framework는 에이전트가 의도한 기능에 필요한 데이터만 사용하도록 하고, RAG·미세 조정·학습에 공급되는 데이터 세트의 개인정보 위험을 검토하라고 권고합니다. RAG는 외부 문서나 데이터에서 관련 내용을 찾아 에이전트의 답변 맥락에 제공하는 방식입니다.

특히 다음 저장 지점을 따로 점검합니다.

  • 에이전트가 참조하는 데이터 세트
  • 대화나 작업 맥락을 보관하는 메모리
  • 행동과 데이터 접근 기록이 남는 로그
  • 학습 목적으로 관리되는 데이터

같은 문서는 로그·메모리·학습 데이터에 보존 기간을 정의하고, 필요에 따라 자동 제거 또는 익명화 절차를 적용하라고 안내합니다. 정해진 보존 기간 자체는 조직의 데이터 정책과 에이전트 기능에 따라 달라질 수 있으므로, 여기서 확인할 결과는 “필요한 정보만 남기고 삭제 또는 익명화 경로가 정해져 있는가”입니다.

6. 감사 로그와 철회 테스트로 정상 상태를 확인한다

설정이 끝났다고 해서 통제가 검증된 것은 아닙니다. Microsoft Learn은 Microsoft Entra 감사 로그와 애플리케이션 권한 활동 로그를 사용해 추적성, 권한 변경, 대응 준비 상태를 확인하고, 종단 간 인가와 JIT 승격을 검증하라고 권고합니다.

정상적인 추적성은 문제가 생겼을 때 요청을 재구성할 수 있는 상태를 뜻합니다. 공통 통제 항목에는 에이전트 ID, 역할, 유효 범위, 행동, 대상 리소스, 상관관계 ID, 그리고 해당할 경우 ‘사용자 대신(on behalf of)’ 정보의 기록이 포함됩니다.

권한 철회도 반드시 시험합니다. 다음 조치가 실제로 작동하는지 확인해야 합니다.

  • 에이전트 비활성화
  • 자격 증명 교체
  • 토큰 무효화
  • 오래된 권한 제거

검토되지 않은 도구나 통합이 허용돼 있거나, 권한을 제거했는데도 접근이 지속되거나, 로그만으로 에이전트의 ID·권한 범위·행동·대상 리소스를 연결할 수 없다면 통제가 불완전하다는 신호입니다. 워크플로, 도구, 데이터 범위, 배포 환경이 크게 바뀔 때도 접근권한을 다시 검토합니다.

운영 AI 에이전트 최소 권한·개인정보 설정 검증표

낮은 위험도의 에이전트 한 개를 먼저 골라 아래 항목을 완료/미완료로 확인해 보세요.

  • 배포된 에이전트와 예정된 에이전트, 도구 통합을 인벤토리화했다.
  • 교차 테넌트·게스트 통합을 포함해 종단 간 유효 총권한을 확인했다.
  • 에이전트마다 고유 전용 ID와 소유자·스폰서·승인자를 지정했다.
  • 목적, 승인 데이터 접근, 도구 종속성, 운영 환경을 문서화했다.
  • 광범위한 역할을 작업 범위 역할과 더 좁은 리소스 범위로 교체했다.
  • 검토되지 않은 도구·플러그인·통합을 기본 거부했고, 필요한 도구·행동만 허용 목록에 넣었다.
  • 고위험 또는 권한 작업에 승인 절차나 시간 제한 권한 승격을 적용했다.
  • RAG·미세 조정·학습 데이터 세트의 개인정보 위험을 검토했다.
  • 메모리·로그·학습 데이터에 보존 기간과 제거 또는 익명화 절차를 정했다.
  • 감사 로그와 애플리케이션 권한 활동 로그에서 추적성과 권한 변경을 확인했다.
  • 하위 시스템까지 포함한 종단 간 인가와 JIT 승격을 검증했다.
  • 에이전트 비활성화, 자격 증명 교체, 토큰 무효화, 오래된 권한 제거를 시험했다.

완료 상태라면 에이전트마다 전용 ID와 책임자, 문서화된 목적·데이터·도구·환경 범위가 있어야 합니다. 또한 작업 범위 권한과 검토된 도구만 허용되고, 고위험 행동은 승인 또는 시간 제한 통제를 거쳐야 합니다. 감사 로그에서는 ID·권한 범위·행동·대상 리소스·상관관계를 확인할 수 있으며, 철회 테스트도 성공해야 합니다.

다음 단계는 낮은 위험도의 에이전트 한 개를 선정해 이 검증표로 인벤토리와 유효 권한을 기록하는 일입니다. 이어 전용 ID, 작업 범위 권한, 도구 허용 목록, 감사 로그, 권한 철회를 순서대로 검증하세요.

같은 주제 이어서 읽기

이어서 읽기

참고한 자료

카테고리전체 카테고리 보기