AI 에이전트 접근 통제

담당 역할: AI 플랫폼 엔지니어, IAM/보안 엔지니어

Part 4의 권한(IAM) 거버넌스는 “사람과 서비스 계정에게 최소권한을 준다”는 전제로 설계되어 있다. 이 전제가 AI 에이전트 앞에서 무너진다. 전통적 권한 모델(RBAC·ABAC·ACL·OAuth)은 모두 “의도의 출처는 언제나 인간이다”를 가정한다. AI 에이전트는 의도를 전달만 하지 않는다. 맥락에서 의도를 생성한다. 클릭 한 번 뒤에서 수십 개의 판단과 행동이 연쇄한다.

• 주체 식별 문제: 리소스 쪽에서 “사람이 직접 조작했는지” “에이전트가 자율적으로 움직였는지”를 구별할 수 없다. 감사 로그만 보면 둘이 똑같아 보여 사고 후 누가 했는지 추적할 수 없다.

• 권한 블랙박스 문제: 에이전트 고유 권한(서비스 계정) 모델에서는 사용자가 “에이전트가 무엇을 할 수 있는지”를 파악하지 못한다. 사용자 본인은 할 수 없는 일을 에이전트를 거쳐 실행할 위험이 있다.

• 책임 소재 괴리: “A가 B에게 부탁한다”와 “A가 에이전트에게 부탁한다”는 다르다. B는 스스로 판단하고 책임진다. 에이전트의 능력 범위를 A가 정확히 파악하지 못하면 사고의 책임 소재가 흐려진다.

Agent Identity는 AI 에이전트를 조직 안에서 “관리되는 신원”으로 다루는 아키텍처 사상이다. 사람 직원과 마찬가지로 신원·권한·라이프사이클을 갖게 한다.

• 신원(Identity): 이 에이전트가 누구인지 증명하는 식별자

• 권한(Permission): 에이전트가 할 수 있는 범위를 명시적으로 정의

• 라이프사이클(Lifecycle): 생성·갱신·폐기를 관리하는 프로세스 — 사람의 입사·재직·퇴사 유비

독립 신원이 있어야 다단계 위임 체인을 추적할 수 있다. “사람 → 에이전트A(범위: 문서 읽기) → 에이전트B(범위: Slack 쓰기) → 외부 API”처럼 이어지는 각 홉에서 “누구의 의도로, 어떤 에이전트가, 무엇을 했는지”를 되짚을 수 있어야 책임 소재가 선다.

1. 1단계 — 아키텍처 선택 — 권한 계승형과 독립 아이덴티티형 중 유스케이스에 맞는 모델을 선택하라. 추적성이 중요하면 독립 아이덴티티형을, 사용자 행동과의 일치가 중요하면 권한 계승형을 택하라.

2. 2단계 — 스코프 설계 — “어떤 파일”이라는 나열형 대신 “기밀 등급이 낮은 것”, “이 프로젝트에 관한 것” 같은 조건 기반(ABAC적) 스코프로 설계하라. 나열형은 자산이 늘어날수록 유지보수가 무너진다.

3. 3단계 — 지명 스폰서 배정 — 모든 에이전트 신원에 책임자 1명을 지명하라. IT 관리자일 필요는 없다 — 업무 이해관계자도 가능하다. 스폰서가 부서를 옮기거나 퇴사하면 자동으로 인계되는 프로세스를 갖춰라.

4. 4단계 — 고위험 행동에 인간 승인 삽입 — 이메일 발송, 데이터 삭제처럼 되돌리기 어려운 행동에는 Human-in-the-loop 승인을 워크플로우에 강제하라.

5. 5단계 — 의미 기반 정책 계층 추가 — 신원 통제(누가/무엇이)와 콘텐츠 검사(안전한 내용인가)만으로는 “호출 파라미터 값에 따라 허용 여부가 달라지는 규칙”을 표현할 수 없다. 이런 맥락 의존 규칙은 자연어로 기술하고 LLM이 매 호출마다 평가하는 의미 기반 정책 계층을 추가하라.

6. 6단계 — 라이프사이클 관리 자동화 — “지금 조직에 어떤 에이전트가 있고, 무엇을 할 수 있고, 마지막으로 언제 무엇을 했는지” 상시 파악할 수 있는 상태를 유지하라.

① Semantic Governance Policy(SGP) — IAM 정책은 “누가(source) → 무엇에(target)” 접근 가능한지만 정적으로 결정한다. 콘텐츠 검사 도구는 프롬프트·응답의 위험성만 본다. 둘 다 “2만 엔을 초과하는 자동 결제는 금지” 같은, 호출 파라미터 값에 따라 허용 여부가 달라지는 규칙은 표현하지 못한다. SGP는 이런 규칙을 자연어로 적어 두고, 실제 툴 호출 시점에 LLM이 사용자 의도와 조직 규칙 양쪽에 부합하는지 판정한다. 위반 시 호출을 중단하거나 사람의 승인을 요구한다. 세 메커니즘(신원 통제·콘텐츠 검사·SGP)은 배타적이지 않다 — 게이트웨이에서 동시에 병렬 적용해 계층을 이룬다.

② 에이전트 스폰서 모델 — Microsoft Entra Agent ID가 구현한 방식이다. 모든 에이전트 신원에 책임자 1명을 지명한다. 스폰서는 접근 요청·리뷰·라이프사이클 결정(갱신·연장·폐기) 권한을 갖고, 부서 이동이나 퇴사 시 Lifecycle Workflows가 자동으로 매니저나 공동 스폰서에게 인계한다. 행동별 승인 게이트가 “이 행동을 지금 승인할까”를 묻는다면, 스폰서 모델은 “이 에이전트 전체를 누가 책임지는가”를 상시 묻는다 — 인계가 끊기면 아무도 책임지지 않는 “고아 신원(orphaned identity)”이 생긴다는 것이 핵심 리스크다.

③ 읽기 전용 IAM을 통한 위임 경계 구조화 — Part 4.5에서 다룬 클라우드 패턴이 AI 에이전트에도 그대로 적용된다. AI 에이전트에 ViewOnlyAccess만 부여해 쓰기 액션 자체를 물리적으로 차단하고, 실행은 관리자 권한을 가진 사람에게만 남긴다.

• 모든 AI 에이전트가 독립 신원 또는 명확히 정의된 권한 계승 규칙을 갖는가?

• 에이전트 신원마다 책임지는 사람(스폰서)이 지명되어 있는가, 스폰서 인계 프로세스가 자동화되어 있는가?

• 되돌리기 어려운 고위험 행동에 Human-in-the-loop 승인이 강제되어 있는가?

• 신원 통제·콘텐츠 검사만으로 표현할 수 없는 맥락 의존 규칙(금액 상한 등)을 다루는 정책 계층이 있는가?

• 다단계 위임 체인(사람→에이전트A→에이전트B→외부 API)을 감사 로그로 추적할 수 있는가?

• “지금 조직에 어떤 에이전트가 있는가”를 한눈에 파악할 수 있는 인벤토리가 있는가?

• 에이전트에 사용자 권한을 그대로 물려준다: 사용자가 할 수 없는 일까지 에이전트를 거쳐 실행할 수 있게 된다.

• 나열형 스코프를 고수한다: 자산이 늘어날 때마다 스코프 목록을 손으로 갱신해야 해 곧 무너진다.

• 스폰서를 지명만 하고 인계 프로세스를 만들지 않는다: 스폰서가 퇴사하면 고아 신원이 남는다.

• 신원 통제만 있고 의미 기반 정책이 없다: “금액이 얼마를 넘으면 금지” 같은 맥락 의존 규칙을 강제할 방법이 없다.