에이전시 스택은 네 개의 레이어를 가지고 있습니다. 대부분의 배포는 세 개가 누락되었습니다.

신원, 평판, 위임, 그리고 결제는 온체인에 존재해야 합니다. 많은 실제 배포에서 아직도 그렇지 않으며, 이는 규정 준수의 사후 생각이 아니라 아키텍처 문제입니다.

저는 실제 에이전트 배포가 어떻게 연결되어 있는지 보는 데 많은 시간을 할애하고 있으며, 패턴은 종종 동일합니다: 모델은 충분히 능력 있고, 오케스트레이션 프레임워크는 합리적이지만, 인증 레이어는 여전히 몇 달째 교체되지 않은 공유 API 키입니다.

자율 에이전트 인프라는 그 위에서 실행되는 모델들의 속도를 따라가지 못했습니다. 에이전시 스택은 체인에 네이티브해야 하는 네 가지 구성 요소, 즉 신원, 평판, 위임, 그리고 결제를 가지고 있습니다. 제가 보는 대부분의 실제 배포에서는 이들이 사후에 추가되거나, 존재조차 하지 않을 경우가 많습니다.

그리고 이는 규제된 금융 분야에서 어느 곳보다 더 중요합니다. 토큰화된 증권을 거래하거나, 재무 행동을 승인하거나, 포지션 간에 할당할 수 있는 에이전트는 자신이 어떤 권한을 부여받았는지, 누가 권한을 부여했는지, 어떤 한도 내에서였는지, 그리고 그 권한의 온체인 기록이 어디에 존재하는지를 보여줄 수 있어야 합니다. 대부분의 배포는 오늘날 이를 명확히 답변하지 못합니다. 그 기록이 없으면, 에이전트 자체가 감사 및 규정 준수 위험이 됩니다.

공유 API 키가 잘못된 기본 요소인 이유

대부분의 에이전트 배포가 SaaS에서 물려받는 인증 모델은 헤더에 전달되는 공유 비밀키입니다. 이는 호출 서비스를 인증하지만, 호출을 수행하는 특정 에이전트나 그 에이전트가 허용된 작업에 대해 아무것도 말해주지 않으며, 규제기관이 검사할 수 있는 형태로 감사에 남는 기록도 남기지 않습니다. 모든 에이전트 행동은 키를 보유한 사람에게만 귀속되므로, 실제로는 에이전트가 하나 이상이거나 운영자가 둘 이상이면 귀속이 무너집니다.

대안은 서명 기반의 요청당 결제입니다. 각 요청은 에이전트 자체 지갑으로 서명되고 호출 시점에 암호적으로 정산됩니다. 이것이 x402 가 구축된 이유이며, 인증과 결제가 함께 처리됩니다. 이를 통해 기관은 어떤 지갑이 언제 어떤 행동을 했으며 무엇에 대해 비용을 지불했는지에 대한 기록을 얻으며, 감사 검토를 견딜 수 있는 원장을 확보합니다.

신원 격차

ERC-8004는 신뢰 없는 에이전트를 위한 온체인 신원을 정의합니다: 에이전트가 제어 지갑, 서비스 엔드포인트, 모델 참조와 함께 등록되는 레지스트리입니다. 현재 그 에이전트는 공급업체 인프라 내부에서 실행되는 불투명한 프로세스에 불과합니다. 레지스트리 항목은 이를 검증 가능한 출처를 가진 일급 온체인 행위자로 만들며, 스마트 계약이나 규정 준수 대시보드가 중개자를 신뢰하지 않고 직접 확인할 수 있습니다.

평판 레이어는 이를 기반으로 구축됩니다. ERC-8004 레지스트리에 기록된 피드백 신호는 불변이며, 타임스탬프가 붙고, 귀속됩니다. 에이전트에 대한 신뢰 결정을 내리고자 하는 모든 시스템은 해당 레지스트리를 직접 읽을 수 있습니다. 공급업체가 관리하는 점수나 Discord 평점과 달리, 여기서 신뢰는 데이터베이스를 제어하는 사람보다 네트워크의 속성입니다.

두 레이어 모두 오늘날 특별한 엔지니어링 없이 구현할 수 있습니다. 대부분의 배포가 이를 갖추지 못한 이유는 가장 저항이 적은 구현 경로가 여전히 에이전트를 일급 행위자가 아닌 서비스 계정으로 취급하기 때문입니다. 프로토타입에서의 합리적인 지름길이 생산 환경에서 복합적인 아키텍처 부채가 됩니다.

위임 문제는 규제된 금융이 다른 모든 분야와 차별화되는 지점입니다

신원과 평판은 에이전트가 누구이며 어떻게 행동했는지를 알려줍니다. 그러나 에이전트가 무엇을 할 권한이 있는지는 규정하지 않습니다. 많은 에이전트 사용 사례에서는 애플리케이션 레이어의 제어가 그 격차를 메울 수 있습니다. 규제 자산을 다루는 에이전트의 경우, 권한 부여 질문은 법적 질문이 됩니다. 답변은 규제기관을 만족시킬 수 있는 형태로 존재해야 합니다.

ERC-8226, 즉 규제된 에이전트 위임 표준(RAMS)은 이 격차를 메우기 위해 설계되었습니다. RAMS는 에이전트 신원과 토큰 수준 규정 준수 프레임워크 사이에 위치하는 규정 준수 위임 레이어를 정의합니다. KYC 인증된 주체가 정의된 범위, 관할권, 가치 한도 및 만료일을 가진 위임을 에이전트에게 부여합니다. 실제로 이는 정산 전에 확인할 수 있는 온체인 위임장과 같습니다. 규제된 토큰 계약은 이후 정산이 발생하기 전에 사전 전송 규정 준수 훅 내부에서 위임을 원자적으로 검증합니다.

두 개의 인터페이스가 설계를 담당합니다. `ComplianceProvider`는 모든 KYC 또는 인증 운영자가 구현하며, 특정 범위에 대한 주체의 적격성을 보증합니다. `IAgentMandate`는 부여, 연장, 취소, 실행 및 규제자 수준 동결을 기록하는 레지스트리입니다. 집행은 `recordExecution`을 통해 이루어지며, 이는 전송 시점에 활성 위임의 한도를 확인하고 거래가 이를 초과하면 되돌립니다.

이 아키텍처는 ERC-8004 신원과 ERC-7943과 같은 토큰 규정 준수 프레임워크 사이에 위치하며, 어느 하나를 대체하지 않습니다. 신원은 에이전트가 존재하고 검증 가능함을 말하고, 토큰 규정 준수는 주체가 해당 특정 자산을 보유할 자격이 있음을 말합니다. RAMS는 두 영역이 다루지 않는 부분, 즉 이 주체로부터 이 범위에 대해, 이 한도 내에서, 이 날짜까지의 권한을 추가합니다. 현재 PDF와 백오피스 스프레드시트에만 존재하는 법적 구속력이 있는 위임 레이어가 온체인으로 이동하여 전송 시점에 실제로 집행될 수 있게 됩니다.

준비와 실행의 분리는 마찰이 아니다

한 가지 설계 결정은 직접적인 옹호가 필요합니다: 거래 준비를 서명 및 전송과 분리하는 것입니다. 이는 에이전트를 보다 원활하게 만들려는 많은 시스템에서 생략됩니다.

본능적으로 이를 하나의 단계로 합치면 더 효율해 보이지만, 준비와 전송 사이의 격차가 바로 기관 감시가 필요한 지점입니다. 여기서 규정 준수 담당자는 에이전트가 체인에 알려지기 전에 수행하려는 작업을 검토하고, RAMS 위임 검사는 서명이 생성되기 전에 준비된 페이로드를 활성 범위, 가치 한도 및 관할권에 맞추어 검증하며, CFO는 에이전트가 준비했지만 아직 커밋되지 않은 재무 행동을 승인합니다.

의미 있는 규모로 자율 에이전트를 배포하는 많은 기관들은 이 분리가 없음을 발견하면 결국 이를 재구축합니다. 이는 시스템을 최초 규정 준수 검토를 통과하도록 하는 레트로핏이 아니라, 의도적인 아키텍처 기본 요소로 구축하는 것입니다.

스택이 완전할 때의 모습

네 개의 레이어가 모두 갖춰지면, 이들은 깔끔하게 조합됩니다. ERC-8004는 에이전트 신원과 온체인 평판을 고정하고, ERC-8226은 각 에이전트가 누구를 대신해 무엇을 할 수 있는지를 제한하는 위임 레이어를 추가합니다. x402는 정산을 처리하고 각 요청에 서명하여 모든 행동이 귀속 가능하고 감사 가능하도록 합니다. 그 아래에서 ERC-7943과 같은 규제 자산 프레임워크는 전송 시점에 주체의 적격성과 에이전트의 활성 위임을 모두 검증하여 규정 준수를 강제합니다.

이 구성 요소들은 성숙도 수준이 다르지만, 순수히 이론적인 것은 없습니다. ERC-8004는 배포 가능한 신원 및 평판 기본 요소를 가진 초안 표준 트랙 ERC이며, ERC-7943은 최종 이더리움 표준입니다. ERC-8226은 표준 트랙에 있으며, 핵심 인터페이스는 초기 구현 작업에 충분히 안정적입니다. x402은 실시간으로 운영 중이며 이미 인간과 에이전트를 위한 프로그래밍 가능한 HTTP 결제를 중심으로 설계되었습니다.

이것을 올바르게 구현하는 팀은 지금 바로 이 스택을 구축하거나 감사 및 규정 준수 압력이 레트로핏을 강요할 때까지 기다릴 수 있습니다. 이를 올바르게 구현하는 기관은 위임 및 신원 레이어를 KYC와 보관과 동일하게 첫날부터 인프라 요구사항으로 취급하는 기관이 될 것입니다. 규제기관이 아직 모든 요소를 명시적으로 요구하지는 않았을 수 있습니다. 이 분야에서 실제 시스템을 구축하는 팀들은 사후에 이러한 제어를 추가하는 비용이 얼마나 큰지 이미 알고 있습니다.