두 낯선 사람이 제 댓글에서 에이전트 위임 프로토콜을 만들었습니다 — 그래도 규제자가 필요합니다

AI 요약

글쓴이는 자신의 이전 댓글에서 에이전트 권한을 상태 버전 목록과 대조하는 방식을 두고, 목록은 시간이 지나면 낡으므로 짧은 만료 시간(expiry)을 사용해야 한다고 주장했다고 설명합니다. 그러나 @anp2network는 결제 승인(payment authorization)의 유효성은 시계가 아니라 승인 대상이 명시하는 효과(effect)에 달려 있다고 반박합니다. 예를 들어 40파운드 결제 승인은 4,000파운드 결제로 재사용될 수 없습니다. 빠르게 만료되기 때문이 아니라, 승인에 금액과 수취인이 포함되고 실제 자금을 이동시키는 쪽이 그 조건을 확인하기 때문입니다. 따라서 핵심 질문은 “아직 최신인가”가 아니라 “이미 사용된 승인인가”가 됩니다.

■ 작업 전체가 아니라 연산마다 발급하는 위임

이 논의에 @peterbuildssecure가 합류하면서 AI 에이전트용 권한 부여(authorisation) 프로토콜의 형태가 구체화됩니다. 6시간 동안 실행되는 에이전트 작업을 하나의 거래로 취급하지 않고, 상태를 변경하는 도구 호출(tool call) 40개 또는 그에 준하는 개별 연산으로 나눕니다. 각각의 연산에는 별도의 위임(mandate)을 발급하고, 효과를 수행한 주체가 이를 한 번만 소진하도록 합니다. 이렇게 하면 장시간 작업에 포괄적인 권한 하나를 부여하는 대신, 각 상태 변경이 독립적인 경계를 갖게 됩니다.

하지만 단일 사용만으로는 타임아웃(timeout) 문제가 해결되지 않습니다. 호출자 측에서는 응답이 오지 않았지만, 실제 효과를 담당하는 시스템(effect owner)은 이미 작업을 커밋했을 수 있습니다. 이 상황에서 호출자가 타임아웃을 실패로 간주하고 같은 요청을 재시도하면, 원래 요청과 재시도 요청이 모두 실행될 위험이 생깁니다. 즉, 호출자에게 결과가 도착하지 않았다는 사실만으로 효과가 발생하지 않았다고 판단할 수 없습니다.

■ 타임아웃에는 대기 대신 펜싱을 적용합니다

@peterbuildssecure는 이 상태를 “pending”으로 계속 기다리는 대신 “fencing”해야 한다고 제안합니다. 발급자(issuer)는 타임아웃이 발생했을 때 취소(cancellation)를 기록하지만, 이 취소 기록은 발급자의 저장소에만 남아서는 안 됩니다. 지연된 원래 메시지는 발급자가 아니라 효과 소유자에게 도착하기 때문입니다. 따라서 효과 소유자가 원래 요청을 받았을 때 해당 요청이 더 이상 실행되어서는 안 된다는 사실을 확인할 수 있도록, 차단 정보(tombstone)를 효과 소유자 쪽에 기록해야 합니다.

여기에도 경쟁 조건이 있습니다. 취소 쓰기가 방금 실패한 호출과 다른 채널을 사용하면, 원래 메시지와 취소 메시지의 순서가 뒤바뀌거나 한쪽만 반영될 수 있습니다. @anp2network는 이를 해결하기 위해 취소를 교체 요청(replacement)에 포함하자고 제안합니다. 예를 들어 M2가 M1을 “supersedes”한다고 명시하고, 효과 소유자가 M2를 수락하면서 같은 커밋 안에서 M1을 펜싱합니다. 그러면 새로운 요청을 처리하는 과정에서 이전 요청을 차단하는 상태까지 원자적으로 반영할 수 있습니다.

■ 차단 기록은 두 단계로 보존합니다

차단 기록을 영구 보존할 필요도 없습니다. @peterbuildssecure는 두 단계의 보존 구조를 제시합니다. 정직하게 지연된 원래 메시지가 도착할 수 있는 기간에는 실제 실행을 막는 강한 차단 기록을 유지합니다. 그 기간이 지난 뒤에는 저장 비용이 낮은 식별자 마커(id marker)만 남깁니다. 전자는 늦게 도착한 요청을 실제로 거부하기 위한 기록이고, 후자는 이미 처리되었거나 폐기된 식별자를 추적하는 값입니다.

글쓴이는 이 일주일간의 논의를 압축하면, 상태가 사라지는 것이 아니라 계속 더 작아지고 저장 위치가 바뀐다고 정리합니다. 상태 버전 목록이 낡으면 만료 시간을 도입하고, 만료 시간에 의존하면 단일 사용으로 바꾸며, 단일 사용에는 소진 기록이 필요합니다. 소진 기록은 효과 소유자 쪽에 있어야 하고, 효과 소유자가 이를 영원히 보관할 수 없으므로 강한 차단 기록과 값싼 식별자 기록으로 나눕니다.

■ 마지막에 남는 숫자는 기술만으로 정하지 못합니다

이 설계가 마지막에 도달하는 값은 차단 기록을 얼마나 오래 유지할지에 대한 보존 기간(retention window)입니다. 글쓴이는 논의에 참여한 사람들이 이 숫자를 도출하지 못한 이유가 능력 부족이 아니라고 봅니다. 이 값은 순수한 추론만으로 계산되는 종류가 아니기 때문입니다. 결제 시스템에도 같은 숫자가 있지만, 결제 업계는 이를 자체적으로 계산하기보다 정산 창(settlement window)과 보존 정책으로 부여받습니다. 여러 참여자가 같은 규정집과 같은 개정판을 읽고, 이후 어느 한쪽이 자신에게 유리하게 규칙을 바꾸면서 이를 단순한 해석이라고 부를 수 없도록 만드는 권한 구조가 함께 존재합니다.

@anp2network는 반드시 규제기관(regulator)이 있어야 하는 것은 아니라고 반박합니다. 효과 소유자가 변경할 수 없는 공개 개정 이력(public revision history)을 갖춘 엔지니어링 기준만으로도 상당 부분 같은 효과를 얻을 수 있다는 주장입니다. 글쓴이도 공개성은 일방적인 변경을 드러내는 데 도움이 된다는 점을 인정합니다. 다만 공개 이력은 변경을 보이게 만들 뿐, 변경에 비용을 부과하지는 않습니다. 카드 결제 네트워크는 규칙을 위반한 회원을 퇴출할 수 있지만, 커밋 이력은 누구도 퇴출하지 않습니다. 글쓴이는 이 차이가 구속력 있는 규칙(rule)과 강하게 표현된 선호(strongly worded preference)의 차이라고 설명합니다.

■ 에이전트 안전성에서 확인해야 할 보존 값

글쓴이는 올해 읽은 에이전트 안전성 메커니즘마다 결국 비슷한 숫자에 도달한다고 말합니다. 감사 추적(audit trail)을 조회할 수 있는 기간, 멱등성 키(idempotency key)가 재실행을 차단하는 시간, 폐기된 자격 증명(revoked credential)이 캐시에 계속 폐기 상태로 남는 기간, 정책 스냅샷(policy snapshot)이 검사에 사용될 수 있는 최대 경과 시간이 그 예입니다. 메커니즘 자체는 유효할 수 있고, 과거 결제 시스템보다 더 잘 설계된 경우도 있습니다. 그러나 밑바닥에는 항상 설정 기본값(configuration default)이 남습니다.

그 숫자를 누가 소유하고 어떤 근거로 바꾸는지 정하지 않았다면, 기본값은 저장 비용이 문제가 된 스프린트에서 플랫폼 팀이 적당하다고 판단한 값이 되기 쉽습니다. 글쓴이는 이를 플랫폼 팀에 대한 비판으로 제시하지 않습니다. 반대편에 책임을 묻거나 합의를 갱신할 주체가 없는 숫자는 어떤 조직에서도 같은 방식으로 결정된다는 설명입니다.

결론에서 글쓴이는 모든 시스템에서 자신의 보존 숫자를 찾아보라고 요청합니다. 멱등성 키의 TTL(Time to Live), 실제 중복 제거 캐시(deduplication cache)가 커버하는 시간, 아웃박스(outbox) 행을 정리하거나 vacuum하는 시점, 폐기 기록이 유지되는 기간을 확인해야 합니다. 그리고 그 값을 누가 입력했는지, 입력 당시 무엇을 알고 있었는지, 너무 짧은 값으로 문제가 발생했을 때 책임이 어떻게 되는지를 물어야 합니다. 마지막 질문의 답이 “아무 일도 일어나지 않는다”라면, 시스템에는 메커니즘은 있지만 규칙을 소유하는 구조는 없는 셈입니다.

글쓴이는 규제기관이라는 비유가 모든 환경에 그대로 적용되지는 않는다고 덧붙입니다. 결제에서는 잘못된 자금 이동이 국가가 이해하고 개입할 수 있는 대상이지만, 에이전트가 잘못된 S3 prefix를 삭제하는 문제에는 동일한 형태의 기관을 원하기 어렵습니다. 한 회사 안에서는 호출자와 효과 소유자가 대체로 같은 조직에 있으므로, 필요한 것은 별도의 규제기관보다 명시된 소유자와 충분히 검토되는 변경 절차입니다. 40초 만에 승인되는 Pull Request가 아니라, 해당 숫자를 정한 사람이 어떤 가정을 했고 틀렸을 때 무엇을 바꿀지 기록하는 절차가 필요하다는 주장입니다.

원문: dev.to / 번역·요약: Trawling