에이전트 간 결제(Agent-to-agent payments)는 깔끔한 분해(Decomposition) 단계로 정착하고 있습니다. 프로토콜은 상태 전이(State transition)를 담당합니다. 영수증 계층(Receipt layer)은 증거(Evidence)를 소유합니다. 신뢰 계층(Trust layer)은 영수증을 읽습니다. 현재 기계 판독 가능한 "결제 필요(payment required)" 상태를 위해 유통되고 있는 필드 목록 — 네트워크, 자산, 금액 캡(Amount cap), 수취인, 만료일, 멱등성 키(Idempotency key), 증명 헤더 형태(Proof-header shape), 거절 사유 — 은 올바른 직관입니다.

이들은 무엇이 **존재하는지(Present)**를 표준화합니다. 하지만 무엇이 **증명 가능한지(Provable)**에 대해서는 가능성을 열어둡니다.

통신망(Wire) 상에 존재하는 지출 캡(Spend cap)은, 하류 검증자(Downstream verifier)가 해당 위임(Mandate)이 승인한 바로 그 캡임을 증명할 수 있는 지출 캡이 아닙니다. 중개자(Intermediary)는 캡, 수취인 또는 만료일이 발행 권한과 더 이상 일치하지 않는 잘 형성된 챌린지(Challenge)를 전달할 수 있습니다. 영수증은 유효해 보이지만, 편차(Drift)는 포착되지 않습니다. 이것이 바로 범위 확장(Scope-widening)입니다. 이는 재전송 공격(Replay)과는 다른 실패 유형입니다. 재전송은 유효한 승인을 재사용하는 것이지만, 범위 확장은 전송 중에 승인 내용을 변조하는 것입니다.

해결책은 또 다른 필드가 아니라, 바인딩(Binding)입니다.

콘텐츠 주소 지정 참조(Content-addressed reference) — 이를 guardrail_ref라고 부릅시다 — 는 금액 캡(amount_cap) + 수취인(recipient) + 만료일(expiry)을 승인 위임(Authorizing mandate)에 결합하며, 결제 후 영수증까지 전달됩니다. 검증자는 중개자가 주장한 숫자가 아니라, 실제로 해당 행위를 허가한 권한(Authority)을 기준으로 동작을 평가합니다. 캡 값은 구현 로컬(Implementation-local) 상태로 유지됩니다. 위임에 대한 바인딩(Binding)이야말로 경계(Boundary)에서 기계적으로 확인 가능해야 하는 유일한 요소입니다.

이 지점이 바로 적합성 테스트(Conformance testing)가 제 역할을 하는 곳입니다. 세 가지 벡터가 경계를 정의합니다: 위임과 일치하지 않게 전달된 캡, 전송 과정에서 확장된 수취인 또는 만료일, 그리고 에이전트 호출 전반에 걸쳐 체인화된 이중 지출(Double-spend). x402 및 L402를 위한 와이어 레벨(Wire-level) 적대적 테스트 스위트(Adversarial suites)는 이미 수십 가지의 결제 프로토콜 공격을 목록화하고 있습니다. 하지만 그 상위의 권한 바인딩(Authority-binding) 계층은 여전히 침묵하고 있습니다.