Executive Summary

메타의 한 내부 AI 에이전트가 약 두 시간 동안 볼 자격 없는 데이터를 사내에 노출했다. 이 사건에서 가장 중요한 사실은, 아무것도 뚫리지 않았다는 것이다. 외부 공격자가 침입한 것도, 자격증명이 도난당한 것도, 방화벽이나 접근 경계가 무너진 것도 아니었다. 에이전트는 유효한 자격증명을 들고 모든 신원 확인을 정상적으로 통과했다.

그런데도 데이터는 샜다. 실패가 일어난 곳은 인증(authentication) 다음 단계였다. 에이전트가 누구인지는 정확히 확인됐지만, 그 에이전트가 무엇까지 볼 자격이 있는지를 확인하는 인가(authorization)가 데이터에 손을 뻗는 시점에 강제되지 않았다. 유효한 자격을 가진 대리인이 자기 권한으로 잘못된 요청을 실행하는 이 구조는 보안학의 고전인 혼란한 대리인(confused deputy) 문제 그대로다. 아무것도 뚫리지 않아도 새는 이유가 여기에 있다.

이 지점에서 이 글은 최근의 지배적인 담론과 갈라선다. 기업 AI 에이전트를 둘러싼 이야기는 대개 "모델이 자신 있게 틀린 답을 한다(confidently wrong)"는 성능 문제로 수렴한다. 그러나 메타 사건이 드러낸 것은 성능이 아니다. 접근할 자격이 없는 데이터에 에이전트가 도달했다는 것, 그것은 모델이 무엇을 아는가의 문제가 아니라 무엇까지 볼 자격이 있는가의 문제다. 성능 담론이 아니라 데이터 거버넌스의 문제인 것이다.

이미 다룬 각도, 그리고 아직 남은 각도

페블러스는 최근 몇 주 사이 에이전트 데이터 유출을 여러 각도에서 다뤘다. 유출이 어디로 새는지(도구 호출·로그·에이전트 간 메시지), 그것을 떠받치는 컨텍스트 레이어가 왜 투자처가 됐는지, 그리고 에이전트가 누구인지(신원과 계보)를 짚었다. 이 글은 그 세 편이 건드리지 않은 두 축을 좁혀 본다. 무엇까지 볼 자격이 있는가(권한), 그리고 그 자격이 언제 무너지는가(검색 시점)다.

한 문장으로 줄이면 이렇다. 신원(누가)과 통로(어디로)는 이미 다뤘다. 이 글은 권한(무엇까지)과 시점(언제)이다.

원본 데이터 웨어하우스는 누가 무엇을 보는지를 정교하게 강제한다. 역할 기반 접근 통제(RBAC)는 직무에 따라, 속성 기반 접근 통제(ABAC)는 부서·지역·보안 등급 같은 속성에 따라 접근을 나눈다. 행 수준 보안(RLS)은 같은 표를 조회해도 사람마다 다른 행만 보이게 하고, 컬럼 마스킹은 특정 열의 값을 가린다. 여기까지는 수십 년간 다듬어진, 잘 작동하는 통제다.

문제는 이 데이터를 AI 에이전트에게 먹이기 위해 옮기는 순간 시작된다. 검색 증강 생성(RAG) 파이프라인은 문서를 잘게 청크로 쪼개고, 각 청크를 임베딩이라는 숫자 벡터로 바꿔 벡터 인덱스에 저장한다. 그런데 이 벡터 인덱스에는 원본이 지녔던 행·열 권한 술어를 담을 자리가 없다. 벡터는 의미의 근접도를 표현하도록 설계된 자료구조이지, "이 값은 인사팀만 볼 수 있다"는 규칙을 표현하도록 만들어지지 않았다. 게다가 청킹은 RLS나 컬럼 마스킹이 의존하던 행과 열의 경계 자체를 허문다. 한 문서를 여러 조각으로 나누는 순간, 어느 조각이 어떤 권한에 속하는지를 원본만큼 정밀하게 되짚을 수 없게 된다.

많은 조직이 이 공백을 메타데이터로 메운다. 청크마다 "이 문서는 이 팀만"이라는 접근 제어 목록(ACL)을 태그로 붙이는 것이다. 붙일 수는 있다. 그러나 그것은 원본 권한의 복사본이지 상속이 아니다. 복사본은 별도의 동기화 파이프라인을 통해 원본과 맞춰야 하고, 그 동기화가 조금이라도 늦으면 인덱스의 권한은 원본과 어긋나기 시작한다. 이것이 뒤에서 다룰 권한 드리프트의 기술적 실체다.

데이터 거버넌스 플랫폼 아틀란(Atlan)은 이 대비를 이렇게 못 박는다. 원문은 이렇다. "an agent retrieving data through an MCP server or RAG pipeline should inherit the same access entitlements that govern that data in the source warehouse, not a separate, manually configured permission set that drifts over time." 옮기면, MCP 서버나 RAG 파이프라인을 통해 데이터를 검색하는 에이전트는 원본 웨어하우스에서 그 데이터를 다스리던 접근 권한을 그대로 상속해야 하며, 시간이 지나며 어긋나는 별도의 수기 권한 세트를 쓰면 안 된다는 뜻이다.

학계에서 이 문제를 정면으로 형식화한 사례는 아직 드물다. 정유안·이 등의 permission-aware RAG 연구는 기존 RAG가 검색된 모든 콘텐츠를 동등하게 접근 가능하다고 암묵적으로 가정하며, 서로 다른 권한 모델을 억지로 병합하면 오히려 드리프트와 의도치 않은 노출을 부른다고 지적한다. 대안은 소스의 IAM을 검색 시점에 실시간으로 질의해 상속하는 것이다. 다만 이런 정면 논문은 손에 꼽고, 나머지는 대부분 산업 현장의 구현이 학술적 형식화를 앞서가고 있는 단계다.

권한을 복사하는 순간에는 원본과 사본이 일치한다. 문제는 그다음이다. 조직은 멈춰 있지 않는다. 사람이 팀을 옮기고, 프로젝트가 끝나고, 계약직이 나가고, 임시로 열어 준 접근이 회수되지 않은 채 남는다. 원본 웨어하우스는 이런 변화를 반영하지만, 검색 계층에 따로 설정된 권한 사본은 누군가 챙겨서 맞춰 주지 않으면 옛날 상태에 머문다. 이렇게 원본과 사본이 시간이 지나며 벌어지는 것을 권한 드리프트(entitlement drift)라 하고, 필요 이상으로 권한이 쌓인 상태를 과권한(over-permissioning)이라 한다.

구체적인 장면으로 옮겨 보면 이렇다. 재무팀에서 마케팅팀으로 옮긴 직원을 생각해 보자. 원본 웨어하우스는 그의 옛 재무 데이터 접근을 인사 시스템의 발령에 맞춰 곧 회수한다. 그러나 검색 계층에 복사돼 있던 권한 태그는 그 발령을 자동으로 따라오지 못하고, 누군가 동기화 파이프라인을 손봐 주기 전까지 옛 상태로 남는다. 그리고 그를 대신해 일하는 에이전트는 바로 그 낡은 권한을 근거로 재무 문서를 계속 검색 대상에 올린다. 권한이 어긋난 곳은 한 군데인데, 그 틈으로 새는 것은 원본이 이미 닫은 문 전체다.

규모를 보면 이것이 예외적 사고가 아니라 상태임을 알 수 있다. Oso와 Cyera가 약 240만 명의 신원과 36억 건의 권한을 분석한 결과, 부여된 권한의 96%가 90일 동안 한 번도 사용되지 않았다. 대부분의 조직에서 사람들은 자신에게 열려 있는 문의 극히 일부만 실제로 연다는 뜻이다. IBM의 침해 비용 보고서(2024년 3월~2025년 2월 조사)는 다른 각도에서 같은 공백을 비춘다. AI 모델이나 앱과 관련된 침해를 겪은 조직의 97%가 적절한 AI 접근 통제를 갖추지 못하고 있었다.

여기서 핵심적인 비대칭이 나타난다. 사람에게 과권한은 대체로 잠재 위험이다. 96%의 미사용 권한이 말해 주듯, 사람은 열려 있는 접근을 대부분 행사하지 않는다. 그러나 에이전트는 다르다. 에이전트는 사람의 권한 세트를 그대로 복사받은 다음, 그것을 기계 속도로 전부 활성화한다. 사람이 평생 열지 않았을 문까지 에이전트는 과업을 처리하며 순식간에 열어 본다. 잠재 위험이 즉시 위험으로 바뀌는 것이다.

흔한 대응은 주기적인 권한 리뷰다. 분기마다 접근 권한을 점검해 쓰지 않는 것을 회수하는 방식이다. 그러나 이 접근에는 근본적인 한계가 있다. 리뷰는 배치(batch)로, 즉 정해진 시점에 몰아서 이뤄진다. 리뷰와 리뷰 사이의 공백 동안 드리프트는 계속 쌓이고, 그 공백 동안 에이전트는 낡은 권한 스냅샷을 믿고 검색을 계속한다. 사람의 근무 시간 단위로 돌아가는 리뷰 주기와, 초 단위로 데이터를 훑는 에이전트의 속도는 애초에 같은 시간축 위에 있지 않다.

많은 파이프라인은 검색을 먼저 하고 권한을 나중에 확인한다. 벡터 인덱스에서 질문과 가까운 상위 몇 개(top-k) 청크를 먼저 뽑고, 그다음에 사용자가 볼 자격이 없는 것을 걸러 내는 방식이다. 이것을 사후 필터링(post-filter)이라 부른다. 직관적으로는 문제없어 보인다. 어차피 최종 답변에는 인가된 것만 들어가니까.

그러나 이 순서가 곧 유출의 시작점이다. 비인가 청크를 나중에 걸러 낸다는 것은, 그전에 이미 그 청크가 검색 과정에 참여했다는 뜻이다. 유사도 점수가 매겨졌고, 순위에 올랐고, 인덱스에서 조회돼 메모리에 올라왔고, 캐시에 남았다. 정책 엔진을 만드는 Cerbos는 이 상태를 이렇게 요약한다. "the security boundary was already crossed" — 걸러 내는 그 시점엔 보안 경계가 이미 넘어간 뒤라는 것이다. 사후 필터는 유출을 막는 게 아니라, 유출된 뒤에 답변에서만 지우는 셈이다.

유출이 생성 이전에 시작된다는 것은 하나의 관측이 아니라 세 갈래의 증거로 수렴한다. 첫째는 방금 본 사후 필터의 랭킹 오염이다. 어떤 문서가 상위에 랭크됐는지 자체가 정보다. 상위에 뭔가가 걸렸다는 사실만으로도, 그 데이터가 존재한다는 신호가 새어 나간다.

둘째는 멤버십 추론(membership inference)이다. 2025년 ACM CCS에서 발표된 이른바 '심문 공격(Interrogation Attack)' 연구는, 프롬프트 인젝션 같은 공격 없이 정상적인 검색만으로 특정 데이터가 인덱스에 들어 있는지를 알아낼 수 있음을 실증했다. 30번 정도의 평범한 질의 안에서 데이터의 존재 여부가 드러났다. 공격다운 공격이 없어도, 검색 그 자체가 유출 통로가 되는 것이다.

셋째는 캐시 유출과 혼란한 대리인의 결합이다. 'ConfusedPilot' 연구는 검색 캐시에서 기밀이 새는 경로와, 오염된 문서가 에이전트로 하여금 자기 권한으로 엉뚱한 행동을 하게 만드는 경로를 함께 보였다. 검색된 문서 안에 숨겨진 지시가 들어 있으면, 고권한 에이전트는 그것을 자기 권한으로 실행한다. 낮은 권한의 사용자가 던진 요청이, 높은 권한의 에이전트를 거쳐 그 사용자가 결코 할 수 없었을 행동으로 바뀐다.

세 갈래는 모두 한 지점을 가리킨다. LLM이 답을 짓기 훨씬 전, 검색하고 순위를 매기고 캐시하는 단계에서 이미 경계가 무너진다는 것이다. 앞선 글이 "에이전트는 답변이 아니라 통로에서 샌다"고 했다면, 이 글은 그보다 한 걸음 더 거슬러 올라간다. 통로에 닿기도 전, 검색 시점에 이미 새기 시작한다.

처방의 원칙은 두 문장으로 정리된다. 권한이 검색 범위를 먼저 좁혀야 하고(pre-filter), 그 권한은 새로 만드는 것이 아니라 원본에서 상속되어야 한다. 두 원칙은 하나로 이어진다. 원본을 검색 시점에 되물어 상속하면, 그 결과로 검색 범위가 인가된 것만 남도록 먼저 좁혀지기 때문이다. 산업 현장은 이미 이 방향으로 수렴하고 있다.

데이터 계층 — 원본 권한을 검색 시점에 되묻는다

가장 깔끔한 형태는 데이터베이스 자신이 권한을 강제하게 두는 것이다. pgvector로 벡터를 저장하는 PostgreSQL은 행 수준 보안을 그대로 적용할 수 있어, 검색 쿼리가 사용자별로 볼 수 있는 행만 반환한다. 원본 관계형 권한이 검색에 투명하게 상속되는 것이다. 다만 여기에는 함정이 있다. FORCE RLS를 켜지 않으면 테이블 소유자가 정책을 우회하므로, 상속을 믿기 전에 이 설정부터 확인해야 한다.

벤더 플랫폼도 같은 원리를 제품화하고 있다고 말한다. 데이터브릭스는 사용자를 대신하는(on-behalf-of) 토큰을 실시간으로 상속시켜 에이전트가 사용자 본인의 권한으로만 데이터에 닿게 한다고 설명한다. 스노우플레이크는 행 접근 정책과 마스킹 정책으로 같은 통제를 걸고, 글린(Glean)은 소스의 권한을 검색 인덱스에 미러링한다고 포지셔닝한다. 정책을 코드로 관리하는 OPA나 Cerbos 같은 도구는 쿼리 실행 계획 단계에서 벡터 스토어에 사전 필터를 밀어 넣는 방식을 제시한다.

신원 계층 — 인접하지만 다른 층위

여기서 흔한 혼동 하나를 정리해야 한다. Okta, CyberArk, Aembit 같은 신원 벤더가 다루는 것은 데이터 계층이 아니라 신원 계층이다. 이들은 필요한 순간에만 자격증명을 발급하고(just-in-time), 사람이 아닌 신원(non-human identity)의 생성과 폐기를 관리한다. 즉 "누가"를 정확하게 만든다. 반면 이 글이 강조하는 데이터 계층은 "그 누가가 검색 시점에 무엇까지 볼 자격이 있나"를 강제한다.

둘은 모두 필요하지만 서로를 대체하지 못한다. 신원만 강화하고 데이터 계층의 권한 상속을 빼면, 메타 사건 같은 인증 이후 유출이 그대로 남는다. 에이전트가 누구인지 완벽하게 확인해도, 그 에이전트가 검색 시점에 볼 자격을 초과한 데이터에 닿을 수 있다면 신원 확인은 유출을 막지 못한다. 신원은 문패를 정확히 다는 일이고, 권한 상속은 그 문을 실제로 잠그는 일이다.

기술적 세부에서도 이 책임 분담이 드러난다. 벡터 DB인 Qdrant는 신원 정보를 페이로드 필터로 자동 매핑해 주지 않으며, 이를 애플리케이션 계층의 책임으로 분명히 한다. 즉 검색 시점에 권한을 거는 일은 벡터 DB가 알아서 해 주는 기능이 아니라, 파이프라인을 짜는 쪽이 명시적으로 설계해야 하는 일이다.

검색 시점에 권한을 강제해야 한다는 결론에 이르면, 다음 반사적 대응은 "그럼 모든 에이전트에 가장 강력한 통제를 똑같이 걸자"가 되기 쉽다. 가트너는 정확히 이 지점에서 경고한다. 2026년 5월 발표에서 가트너는 AI 에이전트 전반에 균일한 거버넌스를 적용하는 것이 오히려 엔터프라이즈 AI 에이전트 실패의 근본 원인이 될 것이라고 짚었다.

이유는 대칭적이다. 단순한 조회용 에이전트에 고자율 에이전트 수준의 무거운 통제를 걸면, 지연이 생기고 담당자들이 통제를 우회하는 섀도 경로를 만든다. 반대로 실제로 행동하는 고자율 에이전트를 단순 에이전트 수준으로만 통제하면, 그것이 곧 과권한이 된다. 하나의 기준을 모두에게 똑같이 적용하는 순간, 한쪽은 과잉 통제로 우회를 부르고 다른 쪽은 과소 통제로 유출을 부른다.

해법은 권한 상속을 에이전트의 자율성 등급에 매핑하는 것이다. 관측만 하는 에이전트, 조언만 하는 에이전트, 승인을 받아 행동하는 에이전트, 스스로 행동하는 에이전트는 저마다 다른 권한 강제가 필요하다. 아래 표는 자율성 등급과 검색 시점 권한 강제를 짝지은 것이다.

아틀란이 정리한 에이전트 가드레일 체크리스트도 이 관점에서 다시 읽으면 하나의 축으로 꿰어진다. 여러 통제 항목이 결국 "이 에이전트가 지금 이 데이터를 볼 자격이 있는가를 검색 시점에 확인하는가"라는 한 질문으로 모인다. 자율성이 높을수록 그 확인은 배치 리뷰가 아니라 매 행동마다 실시간으로 이뤄져야 한다.

마지막으로 한 가지 인과의 과장을 경계할 필요가 있다. 에이전트 파일럿의 상당수가 프로덕션에 이르지 못한다는 통계가 자주 인용되지만, 그 실패를 전부 권한 문제로 돌리는 것은 지나치다. 다만 포레스터의 분석은 파일럿 실패 원인의 33%가 툴이나 데이터 접근 부족에서 온다고 분해한다. 실패의 전부는 아니어도, 성능이 아니라 접근 거버넌스가 실패의 주요 축 가운데 하나라는 것은 외부 기관의 관측으로도 뒷받침된다.

이 주제는 페블러스가 다뤄 온 AI-Ready Data와 데이터 거버넌스 노선의 정면에 놓인다. 데이터 품질이라고 하면 흔히 정확성과 완결성을 떠올리지만, 여기에는 한 축이 더 있다. 접근 정합성(access integrity)이다. 학습·검색 데이터가 원본의 권한 경계를 잃은 채 인덱싱되면, 그 데이터는 품질이 낮은 것이 아니라 위험한 것이 된다. 정확하고 완결적이어도, 볼 자격 없는 사람에게 닿을 수 있다면 그 데이터는 준비되지 않은 것이다.

그래서 데이터를 AI에 먹이기 전에 정제·검증할 때, 정확성과 완결성만이 아니라 권한 메타데이터를 함께 상속하고 보존하는 것이 AI-Ready의 새로운 조건이 된다. 벡터 인덱스로 데이터를 옮기는 순간 원본 거버넌스가 소실되는 문제는, 곧 "AI에 먹이기 전에 데이터가 권한까지 준비되어 있어야 한다"는 명제로 이어진다. 페블러스가 다루는 행·열 수준의 접근 통제는 이 보고서가 말하는 검색 시점 권한 강제의 데이터 준비 계층에서의 구현이다.

RAG와 에이전트를 프로덕션에 올리려는 조직이 "파일럿은 되는데 프로덕션이 막히는" 지점도 대개 여기다. 아래는 자기 파이프라인이 권한을 상속하는지 복사하는지를 스스로 진단해 볼 수 있는 다섯 가지 질문이다.

다섯 질문의 답이 뒤쪽(복사·post·배치·서비스 계정·미기록)으로 기울수록, 조직은 인덱스에 굳어 버린 낡은 권한 스냅샷을 믿고 있는 것이다. 던져야 할 질문은 처음과 같다. 우리 파이프라인은 무엇을 아는가가 아니라 무엇까지 볼 자격이 있는가를, 검색 시점에 강제하고 있는가.

학술

• 1.Jeong, & Lee. (2025). "Permission-Aware RAG: IAM-Based Access Filtering in Multi-Resource Environments." IEEE Access.
• 2.Naseh, A., et al. (2025). "Riddle Me This! Stealthy Membership Inference for Retrieval-Augmented Generation" (Interrogation Attack). ACM CCS 2025. arXiv:2502.00306.
• 3.RoyChowdhury, et al. (2024). "ConfusedPilot: Confused Deputy Risks in RAG-based LLMs." arXiv:2408.04870.
• 4.Zhou, Feng, & Yang. (2025). "Privacy-Aware RAG: Secure and Isolated Knowledge Retrieval." arXiv:2503.15548.

정책 · 통계 · 업계

• 5.Gartner. (2026, May 26). "Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure." Gartner Newsroom.
• 6.Atlan. (2026). "Enterprise AI Agent Guardrails Checklist."
• 7.VentureBeat. (2026). "57% of Enterprises Have Watched AI Agents Be Confidently Wrong — The Fix Is an Agentic Context Layer."
• 8.IBM. (2025). "Cost of a Data Breach Report" (조사 기간 2024.3–2025.2, 600개 조직).
• 9.Oso × Cyera. (2026). "Least Privilege Research Report" (약 240만 신원 · 36억 권한 분석).
• 10.Palo Alto Networks / CyberArk. (2026). "Identity Security Landscape" (머신:인간 신원 비율 109:1).
• 11.CSA × Oasis Security. (2026). "State of Non-Human Identity and AI Security."
• 12.Cerbos. "Authorization for RAG and AI agents" (post-filter 위험 — "the security boundary was already crossed").

페블러스

• 13.페블러스. "AI 에이전트는 답변이 아니라 통로에서 샌다." blog.pebblous.ai.
• 14.페블러스. "컨텍스트 레이어가 차세대 AI 인프라 투자처가 된 이유." blog.pebblous.ai.
• 15.페블러스. "에이전트 200개가 회사를 돌리는데 사번은 없다." blog.pebblous.ai.