주니어 엔지니어를 채용하면 수습 기간, 코드 리뷰 프로세스, 그리고 엄격한 IAM (Identity and Access Management) 경계가 주어집니다. 하지만 사람들은 자신의 데이터에 AI 에이전트 (AI agent)를 배포할 때, 대개 시스템 프롬프트 (system prompt)와 기도 한 번이면 충분하다고 생각합니다.

모델이 제대로 작동하기를 바라는 것은 보안 전략이 아닙니다. 저는 LLM (Large Language Model)이 제 라이브 ADX 클러스터에서 테이블을 삭제(drop a table)하려고 시도했을 때 이 사실을 뼈아프게 배웠습니다. 제가 기도를 멈추고 벽을 쌓았기 때문에 다행히 실행되지는 않았습니다.

저는 시맨틱 거버넌스 (semantic governance)나 프롬프트 엔지니어링 (prompt engineering)에 의존하는 대신, 읽기(read)는 통과하고 쓰기(write)는 입구에서 차단되는 엄격한 경계를 강제합니다.

다음은 제가 에이전트를 잠금 처리하기 위해 사용하는 하나의 거버넌스 패턴과, 이를 구현한 세 가지 서로 다른 방식입니다.

패턴: 단일 ID, 엄격한 정책, 위조 불가능한 영수증

아키텍처는 의도적으로 단순합니다. 에이전트는 데이터베이스와 직접 대화하지 않습니다. 대신 게이트키퍼 (gatekeeper)와 대화합니다. 게이트는 모델이 이 DROP 명령에 대해 얼마나 확신하는지에는 관심이 없습니다.

[ LLM Agent ] ---> ( SQL Query ) ---> [ Gatekeeper Policy ] --(If SELECT)--> [ Database ]
                                              |
                                              v (Outcome Log)
...

• 🔑 단일 ID (One Identity): 게이트웨이는 데이터에 접근할 수 있는 유일한 자격 증명 (credential)을 보유합니다.
• 🚦 쿼리 전 정책 적용 (Policy Before Query): 모든 문장은 데이터베이스 엔진에 도달하기 전에 엄격한 규칙 세트에 따라 평가됩니다.
• 🧾 추가 전용 원장 (Append-Only Ledger): 허용되든 차단되든 모든 판결은 불변 로그 (immutable log)에 기록됩니다. 에이전트는 스스로 위조할 수 없는 영수증을 남기는데, 이는 일부 계약직 직원들에게는 기대하기 힘든 부분입니다.

타당한 반론이 있을 수 있습니다: 읽기 전용 연결 (read-only connection)이나 읽기 복제본 (read replica)을 사용하면 드라이버 수준에서 쓰기가 물리적으로 불가능해지며, 이는 어떤 허용 목록 (allowlist)보다 강력한 경계입니다. 맞습니다. 이 정책 계층은 그것을 대신하는 것이 아니라 그 위에 놓이는 것입니다. 읽기 전용 복제본이라 할지라도 과도하게 광범위한 SELECT 문이 개인정보 (PII)를 싹쓸이하는 것을 막지는 못하며, 추가 전용 원장 (append-only ledger)을 제공하지도 않습니다. 이것은 은탄환 (silver bullet)이 아니라 심층 방어 (Defence in depth)입니다.

코드 보기

환경에 따라 강제 메커니즘은 변경되지만, 로직은 동일하게 유지됩니다.

실제 인프라의 경우, 저는 Terraform으로 프로비저닝된 OPA (Open Policy Agent) 컨테이너를 사용합니다. 이것이 제 공개 terraform-lab에서 가져온 실제 sql_guard.rego 정책입니다. 이는 sql-steward 게이트키퍼 형태를 대신하는 현대적인 rego.v1 구문 약 20줄 분량으로, 문장(statement)에서 동사(verb)를 직접 파싱하고, 완전한 블랙리스트를 사용하며, 기본적으로는 하드 클로즈 상태(hard closed state)로 설정됩니다:

package sql_guard
import rego.v1

...

브라우저 기반 데모의 경우, 저는 클라이언트 측 JavaScript를 사용하여 정확히 동일한 형태를 강제합니다. 페이지는 정적 HTML이며, JS가 방문자의 브라우저에서 직접 실행됩니다. Rego와 동일한 verb() 파서 및 블랙리스트 구조를 공유하는 것을 주목하세요. 알 수 없는 동사는 컴파일러가 오타를 처리하는 방식처럼 취급되어 추측을 거부합니다:

var blocked = ["insert", "update", "delete", "drop", "alter", "truncate", "create", "grant"];

function verb(s) {
...

세 가지 구현 방식

정밀도가 중요합니다. 저는 하나의 거대한 '게이트웨이'를 가지고 있는 것이 아니라, 요구되는 위험 프로파일에 따라 세 가지 다른 환경에 적용된 하나의 패턴을 가지고 있습니다:

만약 당신의 에이전트가 가공되지 않은 개인정보(PII)에 접근할 수 있다면, 당신은 이미 패배한 것입니다. 바로 이 지점에서 강제 집행(enforcement)의 방향이 바뀌어야 합니다. 즉, k-익명성 (k-anonymity)을 향해 나아가야 합니다. 게이트웨이(gateway) 설계는 단순히 동사(verb)를 확인하는 것을 넘어, 쿼리의 대상이 편집 정책(redaction policies)에 부합하는지 평가할 수 있도록 진화해야 합니다. 만약 에이전트가 식별 가능한 단일 행을 추출하려고 시도한다면, 이 게이트웨이의 미래 상태는 데이터를 반환하기 전에 해당 데이터를 가로채거나, 일반화(generalize)하거나, 집계(aggregate)하여 LLM이 오직 익명화된 데이터셋만을 받도록 보장해야 합니다.

저는 이에 대한 전체 설계 — 컬럼 분류(column classification), 준식별자 (quasi-identifier) / k-익명성 (k-anonymity) 패스, 그리고 이것이 강제 집행에 어떻게 연결되는지에 대한 내용 — 를 여기에 작성했습니다: PII classification and anonymization design.

직접 체험해 보세요 🧪

브라우저 구현체를 온라인에 올려두었습니다. 파괴적인 명령어를 통과시켜 보려고 시도해 보세요. 최악의 경우, 당신이 허점을 찾아내어 제가 우스꽝스러워 보일 수도 있겠지만, 제 운영 데이터베이스(production database)에 허점이 발견되는 것보다는 낫습니다.

링크: https://pawan-portfolio.pawankapkoti3889.workers.dev/gatekeeper.html

다음 단계

이 설정은 승인되지 않은 쓰기 작업의 즉각적인 유출 문제를 해결하지만, 이것으로 끝난 것은 아닙니다. 향후 로드맵에는 쓰기 작업을 읽기 작업으로 위장하려는 복잡하고 중첩된 SQL 인젝션 (SQL injections)을 처리할 수 있도록 sql-steward의 의미론적 강제 집행 (semantic enforcement)을 강화하고, 동적인 k-익명성 임계값을 OPA 정책에 직접 통합하는 작업이 포함됩니다.

만약 운영 데이터에 접근하는 AI 에이전트를 구축하고 있다면, 프롬프트 (prompt)를 신뢰하는 것을 멈추십시오. 벽을 세우십시오.

그렇다면 당신은 경계선을 어디에 설정하시겠습니까 — 읽기 복제본 (read replica), 정책 계층 (policy layer), 아니면 둘 다입니까?