당신의 AI 데이터베이스 에이전트는 테넌트 필터(tenant filters)를 기억해서는 안 됩니다

AI 워크플로에서 가장 위험한 데이터베이스 버그는 종종 누락된 필터(filter)입니다. 사용자는 합리적인 질문을 던집니다. 모델은 그럴듯한 SQL을 작성합니다. 쿼리가 실행됩니다. 하지만 테넌트 경계(tenant boundary)가 선택 사항이었거나, 암시적이었거나, 혹은 에이전트가 전혀 보지 못한 애플리케이션 코드 속에 숨겨져 있었습니다. 이것이 바로 AI 데이터베이스 에이전트에게 행 단위 보안(row-level security)과 범위가 지정된 데이터베이스 역할(scoped database roles)이 필요한 이유입니다. 이는 있으면 좋은 기능(nice-to-have)이 아니라, 최소한의 기본 요건(the floor)이어야 합니다.

테넌트 필터를 기억력 테스트로 만들지 마세요. 만약 모든 쿼리가 WHERE tenant_id = ...를 기억해야만 한다면, 그 경계는 이미 너무 취약한 것입니다. 프롬프트(Prompts), 도구 설명(tool descriptions), 그리고 스키마 컨텍스트(schema context)는 에이전트가 더 나은 쿼리를 선택하도록 도울 수는 있습니다. 하지만 이것들이 테넌트 간 데이터 읽기(cross-tenant reads)를 방지하는 유일한 수단이 되어서는 안 됩니다.

더 안전한 설정은 다음을 결합합니다:

• 읽기 전용 역할 (read-only roles)
• 행 단위 보안 정책 (row-level security policies)
• 승인된 보고용 뷰 (approved reporting views)
• 컬럼 마스킹 (column redaction)
• 쿼리 예산 (query budgets)
• 프롬프트, SQL, 결과 범위 및 사용자 식별을 위한 감사 로그 (audit logs for prompt, SQL, result scope, and user identity)

읽기 전용 액세스는 데이터 변조(mutation)를 방지합니다. 하지만 과도한 노출(overexposure)을 방지하지는 못합니다.

긴 버전: AI 데이터베이스 에이전트를 위한 행 단위 보안 (Row-level security for AI database agents)
실질적인 규칙: 만약 데이터 경계가 모델이 필터를 기억하는 것에 의존한다면, 그것은 경계가 아닙니다.