AI VIDEO BRIEFING
AI 에이전트 보안: 세분화 권한(FGA)과 관계 기반 접근제어로 RAG 유출 막기
AI 에이전트가 사내 문서를 무차별로 읽지 않게 하려면 역할이 아니라 관계 기반의 세분화된 권한이 필요하다. NDC 시드니 강연을 토대로 RAG 사전 필터링과 도구 호출 권한 설계를 정리하고, 권한 없는 에이전트가 어떤 사고를 내는지 짚는다.
핵심 메시지
- 에이전트 보안의 핵심 질문은 모델 성능이 아니라 '누가 무엇에 접근할 수 있는가'라는 권한 설계다.
- OWASP가 정리한 LLM 보안 위험 중 애플리케이션 개발자가 직접 통제할 수 있는 대표 항목이 민감정보 노출이다.
- 권한 모델은 접근제어목록(ACL) → 역할 기반(RBAC) → 속성 기반(ABAC) → 관계 기반(ReBAC)으로 진화해 왔다.
- RAG에서는 검색한 뒤 걸러내는 사후 필터링보다, 검색 전에 권한으로 후보를 줄이는 사전 필터링이 안전하다.
- 에이전트에게는 권한을 0에서 시작해 작업 단위로만 부여하고, 권한이 없으면 사용자에게 명시적 승인을 받게 해야 한다.
쉽게 이해하기
발표자는 시드니의 하버브리지와 본다이 비치를 예로 들며 강연을 열었다. 다리는 누구나 건널 수 있지만 올라가려면 허가가 필요하고, 아름다운 해변에서도 안전요원은 지정된 구역 밖 수영을 막는다. AI 에이전트 역시 사람이 매번 지시하지 않아도 스스로 계획하고 판단하고 실행하며 백그라운드에서도 동작하는 만큼, '무엇까지 할 수 있는가'라는 경계선이 시스템 차원에서 그어져 있어야 한다는 것이 강연의 출발점이다.
발표자가 현장에서 손을 들어보게 했을 때 실제 프로덕션에 에이전트를 올린 청중은 매우 적었다. 그는 최근 알려진 기업 보안 사고들을 언급하며, 사내 도구에 AI 접근 권한을 열어준 것이 자격 증명 유출로 이어진 사례를 적절한 권한 통제가 있었다면 막을 수 있었을 문제로 규정했다. OWASP가 정리한 LLM 보안 위험 가운데 프롬프트 주입이나 모델 오염은 연구자의 영역이지만, 민감정보 노출은 애플리케이션 개발자가 데이터 모델을 설계하는 단계에서 직접 통제할 수 있는 항목이다.
그래서 이 강연은 스스로 'AI 강연이라기보다 보안 강연'이라고 밝힌다. 발표자는 모든 생성형 AI 에이전트가 네 가지를 점검해야 한다고 정리했다. 요청한 사람이 누구인지 항상 확인할 것, 에이전트가 사용자를 대신해 호출할 때의 권한을 따로 점검할 것, 비동기로 도는 워크플로의 진행 상황을 볼 수 있게 할 것, 그리고 데이터 접근 통제를 실제로 강제할 것이다.
권한 모델의 역사는 커피콩이 점점 곱게 갈리는 과정에 비유됐다. 1960~70년대의 접근제어목록은 '이 사용자가 이 파일을 읽을 수 있는가'만 물었고, 이후 등장한 역할 기반 접근제어는 사용자마다 역할을 붙여 관리를 단순화했다. 그러나 조직이 커져 역할이 100개를 넘어가면 조합 관리가 어려워지고, 속성 기반으로 넘어가도 폴더 계층이 깊으면 결국 권한이 없다는 사실을 확인하기 위해 여러 단계의 데이터베이스 조회를 낭비하게 된다. 관계 기반 접근제어는 사용자·문서·폴더를 노드로 놓고 관계를 그래프로 정의해, 상위 폴더의 열람 권한만 정의해 두면 그 안의 문서 권한이 자동으로 추론되게 한다.
RAG에 적용하는 방법으로는 두 가지가 제시됐다. 검색을 먼저 하고 결과에서 권한 없는 문서를 빼는 사후 필터링, 그리고 사용자 권한으로 후보 집합을 먼저 좁힌 뒤 벡터 검색을 수행하는 사전 필터링이다. 발표자는 사후 필터링에서는 권한 없는 문서가 이미 시스템 안으로 끌려 나온 순간이 존재하므로 공격 표면이 남는다며 사전 필터링을 권했다. 데모에서는 권한 통제를 끄면 재무 담당자가 시스템 설계 문서를, 인턴이 재무 전망을 그대로 받아보다가, 통제를 켜면 '현재 권한으로는 접근할 수 없다'는 응답으로 바뀌는 장면이 이어졌다.
주요 인사이트
- AI 보안 사고의 상당수는 모델 결함이 아니라 권한 설계 부재에서 나온다. 발표자가 강연을 '보안 강연'이라 부른 이유다.
- 관계 기반 모델의 진짜 이점은 표현력보다 운영성이다. 명시하지 않은 권한도 그래프에서 자동 추론되므로 규칙 관리 부담이 급격히 줄어든다.
- 사후 필터링은 결과적으로 같은 답을 주더라도, 권한 밖 문서가 파이프라인 안에 존재했다는 사실 자체가 위험이다. 순서를 바꾸는 것만으로 공격 표면이 줄어든다.
- 에이전트의 권한은 사용자의 권한과 같아서는 안 된다. 사용자는 넓은 권한을 갖더라도 에이전트는 지금 맡은 작업에 필요한 만큼만 가져야 한다.
- 권한 검사에 걸린 에이전트를 그냥 실패시키는 대신 사용자에게 승인을 요청하게 만들면, 보안과 사용성을 동시에 확보할 수 있다.
자주 묻는 질문
역할 기반 접근제어(RBAC)만으로는 왜 부족한가?
역할이라는 단일 속성 하나로 권한을 나누기 때문이다. 조직이 커져 역할이 수십, 수백 개가 되면 조합 관리가 복잡해지고, 문서 한 건 단위의 세밀한 통제가 어렵다. 발표자는 이를 '거친(coarse-grained) 권한'이라고 불렀다.
RAG에서 사전 필터링과 사후 필터링은 무엇이 다른가?
사후 필터링은 벡터 검색으로 문서를 모두 가져온 뒤 권한 없는 것을 제거한다. 사전 필터링은 사용자 권한으로 접근 가능한 문서 집합을 먼저 구해 검색 조건에 메타데이터 필터로 넣는다. 후자는 권한 밖 문서가 애초에 검색되지 않으므로 더 안전하다.
에이전트의 도구 호출 권한은 어떻게 설계하라고 했나?
권한이 하나도 없는 상태에서 시작해, 수행할 작업 단위로 필요한 도구 호출만 허용하라는 것이다. 예를 들어 특정 작업에는 슬랙 채널 목록 조회만 허용하고, 메시지 전송은 별도 권한을 가진 작업에만 허용하는 식이다.
이 접근법은 AI 서비스에만 쓸 수 있나?
아니다. 발표자는 관계 기반 접근제어가 AI가 아닌 일반 애플리케이션에도 그대로 적용된다고 강조했다. 구글 드라이브처럼 폴더와 문서에 권한이 상속되는 구조라면 같은 모델이 유효하다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗