프롬프트만으로는 막을 수 없다. AI 에이전트가 BigQuery의 예상치 못한 테이블을 참조한 이야기

서론

Google Cloud의 BigQuery, Cloud Storage, Vertex AI 등을 활용하여 자연어로 회사 정보나 상품 정보를 검색하는 AI 에이전트를 개발하고 있었습니다.

처음에는 검색 대상 테이블을 프롬프트로 지정했습니다. 하지만 테스트 중, 지정하지 않은 테이블의 정보까지 활용하여 답변하고 있음을 알게 되었습니다.

원인은 AI 에이전트가 사용하는 서비스 계정의 권한에 있었습니다.

이번 경험을 통해 깨달은 것은, 프롬프트로 '참조하지 말라'고 지시하는 것과, 권한적으로 '참조할 수 없는' 상태로 만드는 것은 별개라는 것입니다.

본 기사에서는 실제로 발생했던 사안과 대책, 그리고 거기서 생각해낸 AI 에이전트의 권한 설계에 대해 소개합니다.

개발하던 시스템

이번 시스템에서 AI 에이전트는 BigQuery를 검색하여 사용자의 자연어 문의에 답변을 합니다.

BigQuery에는 다음과 같은 정보가 저장되어 있었습니다.

검색 대상을 프롬프트로 지정했기 때문에, 처음에는 그 범위 내에서 검색될 것이라고 생각했습니다.

'생각보다 답변이 잘 된다'가 의아함의 시작

테스트에서는 다양한 자연어 문의를 시도해 보았습니다.

첫인상은 '생각했던 것보다 제대로 답변할 수 있다' 였습니다.

지정한 테이블만으로는 답변하기 어려워 보이는 질문에도 그럴듯한 답변이 돌아왔습니다.

처음에는 AI 에이전트가 문의를 잘 해석하고 있다고 생각했습니다.

하지만 답변 내용을 확인해 보니, 검색 대상으로 지정하지 않은 테이블의 정보가 포함되어 있는 것을 알게 되었습니다.

즉, AI가 예상보다 똑똑해서가 아니라, 예상 이상의 정보에 접근할 수 있었기 때문이었습니다.

원인은 프롬프트가 아닌 권한이었다

AI 에이전트에게는 다음과 같이 검색 대상을 지정했습니다.

프롬프트 발췌)

당신은 <업무 데이터>에 접근할 수 있는 데이터 분석 에이전트입니다.
자연어 질문에 대해 BigQuery에서 데이터를 가져와 일본어로 답변해 주세요.
## 중요한 지시
...

지정 외 테이블을 참조한 원인으로 처음에는 프롬프트의 모호함이나 에이전트의 판단을 의심했습니다.

하지만 조사 결과, 시스템과 AI 에이전트가 서비스 계정을 분리하지 않았고, AI 측에도 시스템과 동등한 BigQuery 접근 권한이 부여되어 있었습니다.

코드 예)

import google.auth
# 앱 자체(Cloud Run / 컨테이너의 실행 SA, 또는 ADC)의 인증 정보를 그대로 사용
credentials, _ = google.auth.default(...)

프롬프트에서는 검색 대상을 한정했더라도, 실제 권한으로는 다른 테이블도 참조할 수 있는 상태였던 것입니다.

에이전트는 답변을 생성하는 과정에서, 권한상 접근 가능한 다른 테이블을 이용하는 경우가 있었습니다.

왜 발견이 늦었나

곤란했던 점은, 권한 부족처럼 에러가 나는 것이 아니라 정상적으로 처리가 되어버린다는 것입니다.

부족한 정보를 다른 테이블에서 보완함으로써 오히려 답변 품질이 높아 보이는 경우도 있었습니다.

게다가 질문에 따라 참조하는 곳이 달라지기 때문에 발견이 늦었습니다.

프롬프트로 금지하면 막을 수 있을까?

원인 파악 후, 프롬프트에 '지정된 테이블 외를 참조하지 말 것'이라고 명시했습니다.

테스트 상으로는 지정 외 테이블의 참조가 줄어드는 것을 확인할 수 있었습니다.

하지만 이는 접근 제어로 보장되는 것이 아닙니다.

프롬프트상으로는 금지되어 있어도, 권한적으로는 실행할 수 있는 상태가 남아있기 때문입니다.

사람에게 '이 폴더 외에는 보지 말아 주세요'라고 전해도, 실제로는 열람 권한이 부여된 상태와 같습니다.

사용자로부터 어떤 입력을 받더라도, 프롬프트의 지시만으로 지정 외 테이블에 대한 접근을 확실히 막는다고 할 수는 없습니다.

접근 제어 관점에서는, 처음부터 불필요한 데이터를 참조할 수 없는 상태로 만드는 것이 필요합니다.

대책: AI 전용 서비스 계정으로 분리

궁극적으로는 AI 에이전트 전용 서비스 계정을 준비하여 시스템용 서비스 계정과 분리했습니다.

그 위에, AI용 서비스 계정의 권한도 최소화하고 검색 대상 데이터셋/테이블에 필요한 참조 권한만 부여했습니다.

코드 예시)

import google.auth
from google.auth import impersonated_credentials
source_credentials, _ = google.auth.default(
...

프롬프트에 추가한 지시

## 금지 사항
1. 상기 '대상 데이터베이스 정보'에 기재된 테이블 외에는 참조해서는 안 됩니다.
같은 데이터셋 내의 다른 테이블이나, 다른 데이터셋/프로젝트도 대상이 아닙니다.
...

이번 대책에서 중시한 점은 다음과 같습니다.

• 시스템과 AI 에이전트의 실행 주체를 분리하는 것
• AI에 필요한 최소한의 권한만 부여하는 것
• 프롬프트에서도 검색 대상을 명시하는 것

권한으로 접근 가능한 범위를 제한하고, 그 범위 내에서 프롬프트로 동작을 제어하는 설계로 변경했습니다.

AI 에이전트는 하나의 역할(Role)로 생각해야 한다

생성 AI를 이용할 때는 프롬프트나 업로드하는 파일 등, AI에게 '무엇을 전달할지'를 의식하는 경우가 많습니다.

하지만 AI 에이전트는 도구(Tool)를 통해 데이터베이스나 API, 외부 서비스에 접근합니다.

따라서, **AI에게 '무엇을 전달할지'에 더하여, AI가 '무엇에 접근할 수 있는지'**를 확인할 필요가 있습니다.

중요한 것은 AI에게 전달하는 도구, 그 도구의 실행 주체(Identity), 부여된 권한을 세트로 파악하는 것입니다.

인간 사용자에게 일반 사용자/관리자 등의 역할이 있는 것처럼, AI 에이전트도 시스템 내 하나의 역할로 생각할 수 있습니다.

이번 검색 에이전트라면, 역할은 '특정 데이터를 검색하는 것'입니다. 그 역할에 필요한 참조 권한만 가지면 충분하며, 시스템 전체와 같은 권한은 필요하지 않습니다.

이 경험을 통해 생각해 본 멀티 에이전트의 권한 설계

여기서는 이번 사례가 아니라, 경험을 통해 생각한 개인적인 소감입니다.

여러 AI 에이전트가 역할을 분담하는 멀티 에이전트 구성에서는 더욱 권한 분리가 중요하다고 생각합니다.

예를 들어, 각 에이전트의 권한을 다음과 같이 설계할 수 있습니다.

하지만 AI 에이전트의 경우, 전체를 지휘하는 에이전트가 모든 리소스에 대한 직접 접근 권한을 가질 필요는 없습니다.

실제로 처리를 담당하는 에이전트별로 필요한 권한을 주면 된다고 생각합니다.

물론, 지휘 에이전트가 다른 에이전트에게 작업을 요청할 수 있는 범위까지 포함하여 제어해야 합니다.

'부모니까 강한 권한'이 아니라, '그 역할에 어떤 권한이 필요한가'로 설계한다는 생각입니다.

요약

이번 경험을 통해 얻은 교훈은 주로 3가지입니다.

• 프롬프트의 지시와 접근 권한은 별개

'참조하지 않는 것'과 '참조할 수 없는 것'은 다릅니다. -

• AI 에이전트에게도 최소 권한을 적용한다

도구의 실행 주체를 파악하고, 역할에 필요한 권한만 부여합니다. -

• 답변 내용뿐 아니라 실제 참조처도 확인한다

답변이 정확하더라도 예상치 못한 데이터를 이용하고 있을 가능성이 있습니다.

무엇이든 할 수 있는 AI 에이전트는 편리하지만, 필요 없는 것까지 할 수 있게 만들 필요는 없습니다.

이번에 예상보다 더 많이 답변할 수 있다는 것이 문제 발견의 계기가 되었습니다.

AI 에이전트를 시스템에 통합함에 있어, 앞으로도 의식하고 가고 싶은 시점입니다.

Discussion