에이전트가 작성한 메일을 사람이 승인했는데 전송 직전에 수신자와 내용이 바뀌었습니다. 사람 승인은 어떤 실행에 묶어야 하나요?

승인은 '이 에이전트를 신뢰한다'는 포괄 허가보다 실제 실행할 대상·행동·인자·결과 범위에 묶어야 합니다. 승인한 메일의 수신자·본문·첨부와 실제 전송이 달라지면 기존 승인으로 실행하지 않겠습니다. 사람이 중간에 있었다는 사실만으로 안전해지는 것이 아니라, 승인 시점의 의도와 실행 시점의 내용이 일치해야 합니다.

초안과 실행 요청을 고정합니다

에이전트는 먼저 초안을 만들고, 실행기는 수신자·제목·본문·첨부의 버전이나 해시를 포함한 변경안을 표시합니다. 사용자가 승인하면 그 특정 변경안에 대한 승인 기록을 만들고 실행 직전에 다시 대조합니다. 모델이 이후 문장을 수정하거나 도구가 다른 대상을 해석했다면 재승인이 필요합니다. 승인 토큰은 사용자·작업·행동·기한에 묶고 한 번 사용하거나 허용된 재시도만 가능하게 합니다.

모든 읽기마다 승인하면 사용자가 피로해져 중요한 경고를 놓칠 수 있습니다. 읽기 전용 조회, 되돌릴 수 있는 초안 변경, 외부 전송·결제·삭제를 위험과 효과별로 나눕니다. 민감 자료의 외부 조회나 비싼 검색처럼 읽기도 별도 비용·노출을 만들 수 있으므로 단순 read/write 구분만으로 끝내지 않습니다. 승인 화면에는 무엇이 바뀌고 누구에게 공개되며 되돌릴 수 있는지를 보여 줍니다.

승인 뒤 환경 변화도 검사합니다

주문 환불 승인 당시 잔액과 실행 시점 잔액이 달라질 수 있습니다. 승인된 금액과 현재 상태를 조건부 갱신으로 다시 검증하고, 조건이 깨지면 새로운 안을 제시합니다. 이것은 승인과 실행 사이의 TOCTOU 문제입니다. 사람이 허용했다고 현재 DB 제약이나 서버 인가를 생략하지 않습니다.

권한 거절과 대기 상태도 정상 결과로 처리합니다. 모델이 사용자의 침묵을 승인으로 해석하거나 다른 에이전트의 메시지를 사용자 동의로 바꾸지 않게 합니다. 네트워크 재시도로 전송 결과가 불확실하면 같은 논리 키와 승인된 인자를 유지하고 결과를 조회합니다. 테스트는 승인 후 내용 변경, 오래된 승인 재사용, 다른 사용자 승인, 중복 클릭, 일부 전송 성공을 포함합니다. 사람의 판단과 런타임의 결정적 검증이 함께 있어야 승인 UI가 실제 안전 경계가 됩니다.

실행 사례로 확인합니다

승인 화면이 너무 긴 JSON만 보여 주면 사람이 중요한 수신자나 금액을 놓칠 수 있습니다. 변경 전후 차이와 핵심 효과를 우선 표시하고 자세한 인자는 펼쳐 볼 수 있게 설계합니다. 다만 요약과 실제 실행 인자가 다르면 안 되므로 둘은 같은 구조적 변경안에서 생성해야 합니다. 승인 대기 중 작업이 만료되거나 사용자가 취소하면 남은 실행권을 폐기하고 뒤늦게 도착한 승인 응답도 상태를 다시 검사합니다. 사용자가 이미 승인한 내용을 반복 확인하는 것과 실제로 조건이 바뀌어 재승인이 필요한 경우를 구분하면 피로를 줄이면서 안전 경계를 유지할 수 있습니다. 승인 기록의 보존과 접근권한도 감사 요구에 맞춰 관리합니다.