에이전트가 승인한 후 이메일을 변경했다: TypeScript로 페이로드 바운드 게이트 구축하기

approvedTasks.add('weekly-summary');

git clone https://github.com/bobbyhalljr/payload-bound-approval.git
cd payload-bound-approval
node demo.ts

import { createHash } from 'node:crypto';

export type Action = Readonly<{...}

흥미로운 부분은 해시(hash) 이후에 무슨 일이 일어나는가입니다. 세 가지 세부 사항이 승인(approval)을 액션(action)에 연결해 둡니다:

**알 수 없는 필드는 실패합니다.** TypeScript 타입은 런타임(runtime)에서 사라집니다. 이메일 제공업체는 편집기(editor)가 얼마나 안심하게 보였는지 신경 쓰지 않습니다. 게이트(gate)는 복사하기 전에 선언된 필드를 확인합니다. 추가적인 `bcc` 필드를 전달한다고 해서 게이트를 빠져나가는 액션이 조용히 확장될 수는 없습니다.

**반환되는 객체는 디스패치 객체입니다.** 게이트는 해싱하기 전에 필드들을 복사하고 동결(freeze)합니다. 유효성 검사 후 원래 객체를 편집하는 호출자(caller)가 그 반환된 액션을 변경할 수 없습니다. 툴 어댑터(tool adapter)는 `decision.action`을 직접 사용해야 하며, 가변적인 입력으로부터 페이로드(payload)를 재구성해서는 안 됩니다.

**승인은 권한을 소모합니다.** 유효성 검사와 사용 표시 사이에 `await`가 없습니다. 이로 인해 이 확인 및 소모 시퀀스(check-and-consume sequence)는 단일 JavaScript 프로세스 내에서 원자적(atomic)입니다. 이는 워커(workers) 간 또는 프로세스 재시작에 걸친 원자성을 제공하지 않습니다.

수신자나 본문이 변경되면, 에이전트(agent)는 새로운 정확한 액션에 대한 추가 검토가 필요합니다. 이전의 '예'는 오래된 페이로드에 붙어 있습니다.

승인 UI, 인증된 사용자, 영속적인 권한 부여 데이터베이스(durable grant database), 취소 서비스(revocation service), 이메일 제공업체 또는 모델은 여기에 없습니다. Fixture에서 사용되는 권한 ID는 예측 가능합니다. 프로덕션 환경의 ID는 추측할 수 없어야 하며, 에이전트는 스스로 권한을 발급해서는 안 됩니다. 에이전트가 자신을 승인하도록 허용하면 클릭 횟수를 많이 절약할 수 있습니다. 브레이크를 제거하는 것도 마찬가지입니다.

애플리케이션은 인증된 실행 컨텍스트(authenticated execution context)에서 테넌트와 액터(actor)를 파생하고, 도구의 전체 런타임 스키마를 검증하며, 검토자에게 정확한 필드를 보여주어야 합니다. 신뢰할 수 없는 JSON을 데이터로 취급하세요. 이 좁은 검증기(narrow validator)는 임의의 실행 가능한 JavaScript 객체, 게터(getters) 또는 프록시(proxies)를 위해 설계되지 않았습니다.

시간은 fixture에서 호출자로부터 옵니다. 프로덕션 환경에서는 신뢰할 수 있는 서버 클럭과 짧게 정책으로 정의된 생명주기가 필요합니다. 또한 일회성 클레임에 대한 영속적인 트랜잭션 또는 조건부 업데이트, 그리고 감사 기록(audit records) 및 취소 확인이 필요합니다.

권한을 소비하는 것이 원격 쓰기 작업(remote write)이 정확히 한 번 발생하도록 보장하지는 않습니다. 소비 후 충돌이 발생하면 작업이 손실될 수 있습니다. 제공업체의 응답이 손실되면 효과가 불분명할 수 있습니다. 승인 클레임에 **멱등성 키(idempotency key)**, 영속적인 디스패치 상태(durable dispatch state), 그리고 조정(reconciliation)을 페어링하세요. 재시도 시에는 새로운 의도를 만들어내기보다는 동일하게 승인된 의도가 복구되어야 합니다.

마지막으로, 해시 비교는 내용이 안전하거나 정확한지에 대해서는 아무것도 말해주지 않습니다. SHA-256은 형편없는 이메일을 충실하게 식별할 수 있습니다. 검토와 정책이 그것을 건물 밖으로 내보내야 할지 결정합니다. 지문(fingerprint)은 그들의 결정에 평가된 바이트를 첨부합니다.

## 다음으로 구현하고 싶은 것들

앱 전반에서 작동하는 에이전트는 여정 동안 살아남는 승인 경계가 필요합니다.

행동을 동결시키세요. 권한을 바인딩하세요. 디스패치 시점에 소비하세요. 네트워크가 불확실해질 때 영수증(receipt)을 보존하세요.

제가 Roster에 대해 생각하는 방식도 이와 같습니다: 책임, 도구, 그리고 실제 작업 주변의 명확한 경계를 가진 AI 직원들입니다. 유용한 단위는 검사할 수 있는 결과와 증거가 있는 할당(assignment)입니다.

[Roster 사용해 보기](https://get-roster.com).