Safe DML

DML은 일반 쿼리보다 더 엄격한 절차를 거칩니다. 사용자가 승인한 변경 내용과 커밋 직전에 실제로 실행되는 내용이 동일해야 하기 때문입니다.

UPDATE와 DELETE

1. 데이터 변경 컴파일

   승인을 요청하기 전에 SQL을 파싱하고 검증하며 권한을 확인한 뒤 실행 가능한 형태로 컴파일합니다.

2. 대상 행 미리보기

   미리보기용 트랜잭션을 열고 변경을 실행하지 않은 상태에서 현재 조건에 맞는 행을 읽습니다.

3. 일회성 승인 정보 생성

   승인 챌린지에 검증된 실행 계획, 정책 버전, 대상 행 수, 행 집합 핑거프린트를 연결합니다.

4. MCP Elicitation으로 사용자 승인 요청

   elicitation/create를 보내 MCP 클라이언트에서 폼을 통한 명시적 승인을 요구합니다.

5. 승인된 챌린지를 한 번만 사용

   승인 후 일회성 챌린지를 검증하고 소비해 일반 권한 토큰처럼 재사용할 수 없게 합니다.

6. 커밋 트랜잭션에서 다시 조회

   대상 행을 다시 읽고 현재 핑거프린트와 행 수를 승인 당시 미리보기 결과와 비교합니다.

7. 모든 항목이 같을 때만 커밋

   실행 계획, 정책, 챌린지, 행 수, 대상 행 집합이 바뀌지 않았을 때만 승인된 데이터 변경을 실행합니다.

INSERT VALUES

INSERT ... VALUES에는 변경 전에 이미 존재하는 대상 행 집합이 없습니다. 따라서 승인 시 행 집합 미리보기 대신 변경할 수 없는 삽입 페이로드와 검증된 실행 계획을 함께 고정합니다.

Elicitation은 필수입니다

execute_dml_sql과 공개된 DML Custom Tools를 사용하려면 MCP 클라이언트가 form Elicitation을 지원해야 합니다. 승인 상호작용을 수행할 수 없는 클라이언트는 이러한 데이터 변경 경로를 사용할 수 없습니다.

이는 단순한 UI 확인 대화상자와 다릅니다. 승인 챌린지는 서버 측 데이터 변경 프로토콜의 일부이며 실제 실행 직전에도 다시 검증됩니다.

관련 문서