AI 에이전트의 권한은 설계하지 않으면 저절로 넓어진다 — 접근 범위 통제를 위한 구현 청사진

SaaS 제품에 AI 에이전트를 붙이려는 팀이 가장 먼저 마주치는 질문은 대개 "어떤 모델을 쓸까"다. 그런데 실제로 먼저 정해야 할 것은 따로 있다. 에이전트가 어떤 데이터에, 언제, 어떤 조건에서 닿을 수 있는지다.

이 질문을 나중으로 미루면 어떤 일이 생기는지, 최근 구체적인 사례가 공개됐다. Google Gemini가 Gmail 사용자에게 이메일 내용을 기반으로 답변을 제공하면서, 사용자는 자신이 접근을 허용한 적이 없다고 인식했다. Gemini는 대화 중에 "Gmail에 대한 접근 권한이 없다"고 부인했지만, 같은 대화 안에서 이메일 구독 목록과 실제 메일 내용을 참조했다. 권한은 Google Workspace 확장 설정에 연결되어 있었는데, 사용자가 거기서 직접 비활성화하지 않는 한 에이전트는 계속 이메일을 읽을 수 있었다.

이 구조에서 중요한 지점은 Gemini가 악의적이었는가가 아니다. 시스템이 설계된 방식 자체가 사용자에게 접근 여부가 보이지 않도록 만들었다는 것이다. 제품을 만드는 팀 입장에서 이 사례가 던지는 질문은 하나다. 우리 제품에 붙일 에이전트는 지금 어떤 구조로 되어 있는가.

암묵적 권한 확대가 일어나는 구체적인 경로

"사용자가 동의했다"는 말이 실제로 무엇을 의미하는지 팀 안에서 확인해보면, 생각보다 답이 제각각인 경우가 많다. 약관 동의를 가리키는 사람도 있고, 기능 온보딩 화면의 체크박스를 가리키는 사람도 있다. 에이전트에게 직접 연결된 권한 범위를 명시적으로 정의한 문서가 있는지 물어보면, 대부분의 팀에서 그 문서는 없다.

암묵적 권한 확대는 보통 세 가지 경로를 통해 발생한다.

첫째, 플랫폼 통합 시 기본값이 넓게 설정되어 있을 때. 외부 서비스나 내부 시스템과 에이전트를 연결할 때, SDK나 API의 기본 스코프(scope)는 개발 편의를 위해 넓게 설정되는 경우가 많다. 개발팀이 이 기본값을 검토하지 않으면, 에이전트는 제품 기획서에 없던 데이터까지 기술적으로 접근 가능한 상태가 된다.

둘째, 에이전트가 컨텍스트를 채우기 위해 주변 데이터를 끌어올 때. 답변 품질을 높이기 위해 에이전트가 사용자의 과거 활동 이력, 연결된 계정, 다른 모듈의 데이터를 참조하도록 구성하면, 이 연결 범위가 사용자에게 전혀 드러나지 않는다. 에이전트 입장에서는 더 나은 답을 내기 위한 자연스러운 확장이지만, 사용자 입장에서는 동의하지 않은 데이터가 읽히는 것이다.

셋째, 기능이 추가될 때 권한 범위 검토가 함께 이루어지지 않을 때. 초기 설계에서 정한 권한 경계가 문서화되지 않으면, 이후 기능을 붙일 때마다 그 경계가 어디였는지 팀이 알 수 없다. 결과적으로 각 스프린트마다 조금씩 접근 범위가 넓어지고, 어느 시점부터 전체 범위를 파악하는 사람이 없어진다.

요구사항 단계에서 정해야 할 것들

에이전트의 권한 경계는 개발이 시작되기 전에 문서화되어야 한다. 이 단계에서 만들어야 할 산출물은 복잡하지 않다. 핵심은 세 가지 항목을 명시하는 것이다.

접근 허용 범위: 에이전트가 읽을 수 있는 데이터 유형과 테이블·API 엔드포인트를 열거한다. "사용자 데이터에 접근"처럼 넓게 쓰면 구현 단계에서 해석이 달라진다. "현재 로그인한 사용자의 현재 세션 내 메시지만"처럼 조건을 붙여서 써야 한다.

접근 금지 범위: 허용하지 않는 것을 명시하는 작업이 허용 목록을 만드는 것보다 더 중요할 수 있다. 사용자가 생성하지 않은 데이터, 타 사용자의 데이터, 서비스 운영 로그 등 기술적으로는 접근 가능하지만 에이전트에게 닿아서는 안 되는 범위를 명확히 한다.

사용자 가시성 요건: 에이전트가 어떤 데이터를 참조했는지 사용자가 확인할 수 있어야 한다면, 그 표시 방식도 요구사항에 넣어야 한다. Gemini 사례에서 사용자를 더 혼란스럽게 만든 것은 접근 자체보다 접근이 어디에서 제어되는지 알 수 없었다는 점이었다.

이 문서는 PM이 작성하고, 개발과 보안 담당자가 검토해서 서명하는 형태가 가장 현실적이다. 스프린트 시작 전에 이 문서가 없다면, 구현이 시작되어서는 안 된다.

코드 수준에서 권한 경계를 강제하는 방법

요구사항 문서가 있어도 구현에서 이를 강제하지 않으면 의미가 없다. 실무에서 권한 경계를 코드 수준에서 유지하는 방식은 크게 두 가지다.

데이터 접근 레이어를 에이전트 전용으로 분리한다. 에이전트가 직접 DB 쿼리를 날리거나 범용 API를 호출하지 않도록, 에이전트 전용 데이터 게이트웨이를 만든다. 이 게이트웨이는 요구사항 문서에 정의된 범위만 반환하도록 설계하고, 나머지 요청은 에러로 처리한다. 이렇게 하면 에이전트의 코드 자체는 권한 로직을 모른 채로 유지할 수 있고, 권한 변경이 필요할 때 게이트웨이 한 곳만 수정하면 된다.

모든 데이터 참조 이벤트를 로그로 남긴다. 에이전트가 어떤 데이터에 접근했는지를 요청 단위로 기록한다. 로그에는 최소한 사용자 ID, 에이전트 요청 ID, 접근한 데이터 유형, 타임스탬프가 들어가야 한다. 이 로그는 두 가지 목적에 쓰인다. 하나는 이상 접근 패턴을 탐지하는 것이고, 다른 하나는 사용자 또는 규제 기관의 요청에 응답하는 것이다.

여기서 하나 짚고 넘어가야 할 점이 있다. 에이전트 프레임워크(LangChain, LlamaIndex 등)가 기본으로 제공하는 툴 구성이나 메모리 모듈은, 개발 편의를 위해 설계된 것이지 권한 통제를 위해 설계된 것이 아니다. 이 프레임워크들의 기본값을 그대로 쓰면 권한 경계가 프레임워크의 설계 결정에 종속된다. 프레임워크 위에서 권한 레이어를 별도로 구현해야 하는 이유가 이것이다.

출시 전 검증: 권한 경계가 실제로 작동하는지 확인하는 방법

구현이 끝나면 권한 경계가 문서대로 작동하는지 검증해야 한다. 이 검증은 QA 팀이 기능 테스트를 하는 것과는 다른 관점에서 이루어져야 한다.

확인해야 할 항목은 세 가지다.

경계 밖 접근 시도 시 차단 여부. 에이전트가 접근 금지 범위의 데이터를 요청했을 때 게이트웨이가 이를 거부하고 로그를 남기는지 테스트한다. 단순히 에러가 나는지 확인하는 게 아니라, 그 거부 이벤트가 모니터링 시스템에 잡히는지까지 확인해야 한다.

컨텍스트 확장 경로 차단 여부. 에이전트가 메인 요청과 무관하게 추가 데이터를 가져오려 할 때 이를 막을 수 있는지 확인한다. 프롬프트 인젝션(prompt injection — 사용자 입력을 통해 에이전트의 행동을 의도하지 않은 방향으로 유도하는 공격)을 통해 에이전트가 추가 데이터를 가져오도록 유도하는 시나리오를 포함해야 한다.

사용자 가시성 요건 충족 여부. 에이전트가 어떤 데이터를 참조했는지 사용자 인터페이스에서 확인할 수 있다면, 실제로 그 정보가 정확하게 표시되는지 검증한다. 참조 데이터와 표시 내용이 다르면, 이는 보안 문제이기 전에 신뢰 문제다.

이 검증은 최초 출시 때만 하는 것으로 끝나면 안 된다. 새 기능이 추가될 때마다, 에이전트를 구성하는 외부 서비스가 업데이트될 때마다 반복해야 한다.

운영 단계에서 이상 징후를 먼저 잡는 방법

에이전트가 서비스에 올라간 이후부터는 모니터링이 통제의 중심이 된다. 런타임에서 권한 경계를 넘는 접근이 발생했는지를 감지하려면, 어떤 이벤트를 알람으로 설정할지 미리 정해두어야 한다.

실무적으로 유용한 알람 조건은 다음과 같다. 특정 사용자 세션에서 에이전트가 참조하는 데이터 유형이 평소보다 급증하는 경우, 게이트웨이에서 권한 거부 이벤트가 짧은 시간 안에 반복되는 경우, 에이전트가 접근해서는 안 되는 테이블이나 엔드포인트에 대한 요청이 로그에 남는 경우다.

알람 조건과 함께 응답 절차도 미리 만들어두어야 한다. 이상 접근이 탐지되었을 때 에이전트를 즉시 격리할 수 있는 스위치가 있는지, 영향받은 사용자에게 어떻게 고지할지, 로그를 어디서 얼마나 보관할지를 사전에 결정해두지 않으면, 문제가 생겼을 때 의사결정에 시간이 걸린다.

한 가지 조직적인 조건을 덧붙이면, 이 모니터링 체계를 유지하는 책임이 어느 팀에 있는지 명확해야 한다. 에이전트를 만든 개발팀인지, 보안팀인지, 아니면 제품팀인지. 담당이 불분명하면 로그가 쌓여도 아무도 보지 않는 상태가 된다.

제품팀이 다음 스프린트에서 확인해야 할 것

현재 AI 에이전트를 붙이는 작업이 진행 중이거나 이미 운영 중이라면, 지금 당장 두 가지를 확인하는 것이 출발점이다.

하나는 에이전트가 실제로 접근하는 데이터의 범위를 개발팀에게 물어보는 것이다. 요구사항 문서에 적힌 것과 실제 구현된 것이 다를 수 있다. 특히 외부 플랫폼과의 통합이 있다면, 그 연결에서 기본값으로 열려 있는 스코프가 무엇인지 코드 레벨에서 확인해야 한다.

다른 하나는 에이전트의 데이터 접근 이력을 지금 어디서 볼 수 있는지 확인하는 것이다. 볼 수 있는 곳이 없다면, 로깅 구현이 먼저다. 권한 경계를 아무리 잘 설계해도 실제로 그 경계가 지켜지고 있는지 확인할 방법이 없으면, 그 설계는 운영 단계에서 의미를 잃는다.