읽기 전용만으로는 부족합니다: AI 에이전트를 위한 가드레일
시니어 엔지니어들은 AI 에이전트를 안전하게 유지하기 위해 종종 한 가지를 제안합니다. 바로 읽기 전용(read-only) 권한을 부여하는 것입니다.
안전하게 들립니다. 에이전트는 시스템을 망가뜨리지 않고도 느린 쿼리를 조사하거나 스키마를 요약할 수 있습니다.
하지만 읽기 전용은 안전 모델이 아닙니다. 그것은 제약 사항일 뿐입니다.
에이전트가 유용한 작업을 수행해야 하는 순간, 읽기 전용 권한은 발목을 잡습니다. 에이전트가 잘못된 인덱스나 손상된 행을 발견하더라도 이를 수정할 수 없습니다. 결국 불이 난 곳을 가리키기만 할 뿐, 호스를 들고 불을 끌 수는 없는 조수를 두게 되는 셈입니다.
팀들은 종종 포기하고 에이전트에게 쓰기(write) 권한을 넘겨줍니다. 바로 그때 진짜 위험이 시작됩니다.
진짜 질문은 "에이전트가 써도 되는가"가 아닙니다. 진짜 질문은 "그 쓰기 작업을 어떻게 관리(govern)할 것인가"입니다.
지침(instructions)으로 쓰기 작업을 관리하려 하지 마세요. 시스템 프롬프트에 "절대 테이블을 삭제하지 마시오"와 같은 규칙을 넣지 마세요.
프롬프트 인젝션(Prompt injection)은 이러한 규칙을 무용지물로 만듭니다. 공격자는 데이터 행이나 주석을 사용하여 에이전트가 규칙을 무시하도록 속일 수 있습니다. 가드레일이 에이전트와 동일한 컨텍스트(window) 내에 있다면, 에이전트는 논리적으로 그 규칙을 우회할 수 있습니다.
관리되지 않는 쓰기(ungoverned writes)와 중재된 쓰기(mediated writes)를 구분해야 합니다.
• 관리되지 않는 쓰기: 에이전트가 명령 실행을 결정하면 데이터베이스가 이를 즉시 실행합니다. 유일한 통제 수단은 에이전트 자신의 판단뿐입니다. • 중재된 쓰기: 명령이 에이전트 외부의 체크포인트를 통과합니다. 이 체크포인트는 에이전트와 데이터베이스 사이의 데이터 경로에 위치합니다.
중재된 쓰기는 다음과 같이 작동합니다:
- 에이전트가 문장(statement)을 제안합니다.
- 프록시(proxy) 또는 컨트롤 플레인이 해당 문장을 파싱합니다.
- 프록시가 위험도를 분류합니다.
- 프록시가 실행을 허용할지, 아니면 사람에게 승인을 요청할지 결정합니다.
이 접근 방식은 프롬프트 인젝션으로부터 보호해 줍니다. 악의적인 지침이 에이전트를 속여 DROP TABLE 명령을 쓰게 만들 수는 있지만, 프록시를 속일 수는 없습니다. 프록시는 에이전트의 의도를 읽지 않고, 실제 SQL 명령만 확인하기 때문입니다.
안전을 위해 다음과 같은 구조를 사용하세요:
- 안전한 읽기는 자동 허용합니다. 작업 속도를 유지하기 위해 에이전트가
SELECT쿼리를 자유롭게 실행할 수 있도록 합니다. - 위험한 쓰기는 차단합니다.
DELETE,UPDATE또는 스키마 변경 시에는 사람의 승인을 요구합니다. - 모든 것을 기록합니다. 누가 변경을 제안했고 누가 승인했는지에 대한 불변(immutable)의 기록을 남깁니다.
안전을 위해 읽기 복제본(read replicas)에 의존하지 마세요. 복제본은 조사에는 도움이 되지만, 문제를 수정할 수는 없습니다. 운영 환경의 문제를 해결하려면 반드시 기본(primary) 데이터베이스에 써야 합니다.
중재(Mediation)를 통해 데이터를 안전하게 보호하면서도 에이전트가 유용하게 작동하도록 할 수 있습니다.
Optional learning community: https://t.me/GyaanSetuAi