누가 에이전트를 승인했는지 증명할 수 없다: 13개 프로토콜을 모두 점검하다

우리는 10축 루브릭(rubric)으로 13개의 에이전트 간 프로토콜을 평가했으며, 모든 셀에 기록된 근거를 제시했습니다. 이것이 그 결과입니다. 전체 설문조사는 첨부되어 있습니다.

우리가 찾을 수 있었던 모든 프로토콜 비교는 서술적이었습니다. 프로토콜 A는 발견(discovery)을 강조하고, 프로토콜 B는 더 풍부한 작업 모델(task model)을 가지고 있으며, 둘 다 유망하지만 추가적인 작업이 필요합니다. 네 가지 광범위한 설문조사가 존재하며 모두 유용합니다. 하지만 그 어떤 것도 비교를 확인할 수 있게 해주지는 않습니다.

그래서 우리는 대신 루브릭을 만들었습니다. 10개의 축(axis)과 순서적 레벨(ordinal levels)로 구성되어 있으며, 각 레벨은 품질에 대한 판단이 아니라 명세서(specification)에서 찾을 수 있는 속성(property)에 고정되어 있습니다. 그런 다음 우리는 13개의 명세서를 읽고 그중 8개를 모든 10개 축에 대해 점수화했습니다. 이 여든 개의 셀 각각에 대해 해당 레벨로 배치한 명세서의 문장을 기록했습니다.

레벨을 근거(anchoring)하는 요점은 점수가 의견이 아니게 된다는 것입니다. 만약 당신이 A2A가 승인 측면에서 레벨 1보다 더 나은 자격이 있다고 생각한다면, 그것은 우리의 취향에 반대하는 것이 아닙니다. 당신은 특정 조항(clause)이 존재한다고 주장하고 있는 것이며, 우리는 함께 가서 확인할 수 있습니다.

루브릭이 세 번째 축에서 발견한 것

세 번째 축은 승인(authorisation)이 어떻게 전파되는지 묻습니다. 에이전트 A가 원칙자 P를 대신하여 에이전트 B에게 무언가를 하도록 요청합니다. B는 P가 이것을 승인했음을 증명할 수 있습니까?

레벨은 0부터 3까지입니다. 레벨 1은 OAuth 스코프(scopes) 또는 토큰 포워딩(token forwarding): A가 자신의 토큰을 B에게 건넵니다. 레벨 2는 명시적인 스코프, 오디언스(audience), 시간 제한이 있는 서명된 역량권(signed capability)으로 두 개의 이름 붙은 당사자를 바인딩합니다. 레벨 3은 체인이며, 각 경유지(hop)의 권한은 그 부여를 목격하지 않은 에이전트에 의해 독립적으로 검증될 수 있습니다.

레벨 3은 비어 있습니다. 희박하다는 의미가 아닙니다. 빈 것입니다.

file-1

8개의 프로토콜이 점수화되었습니다. 승인 축의 최고 레벨에는 거주자가 없습니다.

여덟 개 중 네 개는 레벨 1에, 네 개는 레벨 2에 위치합니다. 그중 어느 것도 제3자가 확인할 수 있는 위임 체인을 명시하지 않습니다. 이들 모두가 메커니즘을 "주변의 아이덴티티 아키텍처(surrounding identity architecture)"에 맡기는데, 이는 다른 사람의 문제라는 것을 말하는 사양 계층적 방식입니다.

상거래 프로토콜은 레벨 3까지 도달하며, 이것이 신중하게 언급할 가치가 있는 세부 사항입니다. 이들의 의도, 위임(mandate), 그리고 수령 봉투는 결제 승인이 다른 방식으로 작동하지 않았기 때문에 구조적으로 그곳에 위치합니다. 따라서 해당 분야는 피어 메시징 계층이 부족한 것의 작동 예시를 가지고 있습니다. 그것은 단지 돈만 이동시키는 계층에 놓여 있을 뿐입니다.

우리는 반례를 찾으러 갔는데, 보편적인 주장은 정직하게 깨보려는 시도를 받을 자격이 있기 때문입니다. 가장 좋은 후보는 ACNBP입니다. 이 프로토콜은 세트 내에서 가장 넓은 위협 커버리지를 가지고 있으며, 12개 중 10개 클래스를 다루고 A2A와 MCP의 경우 12개 중 1개를 다룹니다. 여기에는 역대급으로 엄격한 단일 호프(single-hop) 원시 요소인 능력 바인딩 의식(Capability Binding ceremony)이 있습니다. 하지만 여전히 정확히 두 당사자만을 바인딩합니다. 한 주 저자는 이것이 의도된 범위임을 확인해 주었고, 이러한 답변은 발견을 약하게 만들기보다 더 강력하게 만듭니다.

단일 호프에서의 엄격함(Rigour)은 이동하는 권한(authority)이 아닙니다. 이들은 다른 속성이며, 우리는 아무 프로토콜도 두 번째 속성을 가지고 있지 않다는 것을 알기 위해 루브릭을 분리해야 했습니다.

빈 셀이 중요한 이유

배포는 사양을 기다리지 않습니다. 그들은 오늘 작동하기 위해 위임이 필요하므로 토큰을 전달하며, 보안 문헌은 이미 이것이 얼마나 비용이 드는지 측정했습니다.

AgentLeak 벤치마크는 이 문제를 우리에게 재정의한 수치입니다. 에이전트 간 메시지는 개인 식별 콘텐츠(personally identifiable content)를 68.8%에서 유출합니다. 모든 사람이 감사하는 출력 채널은 27.2%에서 유출됩니다. 출력 전용 감사는 위반 사항의 약 41.7%를 놓칩니다.

따라서 이 격차는 명세(specification) 계층의 누락이며, 배포(deployment) 계층에서 측정 가능한 비용을 수반합니다. 이는 '승인 과정에 더 많은 작업이 필요하다'라는 말보다 더 실행 가능합니다. 이것은 우리가 다음 표준화 주기 의제 맨 위에 올릴 항목입니다.

예상치 못한 결과

file-2

우리는 루브릭(rubric) 점수가 채택률을 어느 정도 추적할 것이라고 가정했습니다. 하지만 그렇지 않습니다. 오히려 반대 방향으로 움직입니다.

점수가 가장 높은 두 프로토콜인 ACNBP (24점)와 LOKA (23점)는 우리가 문서화한 배포 규모가 가장 작습니다. 반면, 배포 규모가 가장 큰 A2A (14점)와 MCP (10점)는 평범한 프로필을 가지고 있습니다. A2A와 MCP 각각은 12가지 위협 클래스 중 정확히 하나를 규범적으로 다룹니다.

채택률을 예측하는 것은 제도적 위치입니다. 재단(Foundation)의 관리, 공급업체(vendor)의 지원, 생태계 지원입니다. 명세 수준에서의 기술적 엄격함은 거의 아무것도 예측하지 못합니다.

우리는 이것을 불만 제기가 아닌 발견 사항으로 보고하는데, 왜냐하면 이는 이 작업을 수행하는 모든 사람에게 영향을 미치기 때문입니다. 가장 영향력 있는 기술적 기여는 기관이 채택할 위치에 놓인 것입니다. 이것은 AAIF와 W3C 트랙과 나란히 작업하기보다는 그 안에서 작업해야 한다는 주장입니다. 우리는 우리 자신의 조언을 따랐습니다.

MCP 대 A2A는 범주 오류(category error)입니다

file-3

이 분야에서 가장 논쟁이 많은 경쟁은 경쟁이 아닙니다. MCP는 도구 결합(tool-binding) 프로토콜이고, A2A는 피어 메시징(peer-messaging) 프로토콜이며, 이들은 분류학(taxonomy)의 다른 계층을 차지합니다. 실제 환경에서는 서로 조합하여 사용됩니다. 대체하는 것이 아닙니다.

가장 명확하게 권장되는 스택은 어느 곳에도 배포되어 있지 않다: A2A의 태스크 레이어 아래에 ANP의 아이덴티티 레이어가 있다. ANP는 DID와 검증 가능한 자격 증명(verifiable credentials)에서 아이덴티티 축을 선도한다. A2A가 태스크 축을 선도한다. 조사된 프로토콜 중 어느 것도 배포된 태스크 모델과 분산형 아이덴티티 모델을 결합하지 못했다.

이 권장 사항은 특히 아이덴티티 레이어에 관한 것이다. ANP의 DID 메커니즘은 스택의 나머지 부분에 의존성이 없다. 그 설명 및 검색 프로토콜은 별개의 문제이다: 이들은 A2A AgentCard와 겹치며, 아래에 쌓이기보다는 그것과 경쟁한다.

이러한 차이는 축들을 개별적으로 점수화했을 때만 눈에 띄었다. 하나의 전반적인 판결을 내리는 방식으로는 이를 숨겼을 것이다.

우리가 주장하지 않는 것들

모든 점수는 한 평가자의 해석이다. 우리는 평가자 간 합의 통계(inter-rater agreement statistic)를 가지고 있지 않으며, 이는 제한 사항 단락에 묻어두기보다는 초록에서 명시한다.

대신 우리가 제공하는 것은 감사 가능성(auditability)이다. 점수들은 YAML 파일에 존재하며, 각 셀마다 증거 문자열과 인용이 있다. 모든 표와 그림은 이 파일에서 생성되므로, 표가 그 뒤의 데이터와 벗어날 수 없다. 당신은 한 셀에 대해 동의하지 않을 수 있고, 당신이 동의하지 않는 정확한 지점을 가리킬 수 있다.

13개 프로토콜 중 5개는 조사되었지만 점수화되지는 않았다. 이들은 상거래-결제(commerce-settlement) 관련 프로토콜들로, 10개 축 중 6개가 참조할 것이 없다. 결제 봉투(settlement envelope)에는 태스크 모델도 없고 멀티모달 콘텐츠 처리 기능도 없다. 다른 것들이 점수화되지 않은 상태에서 이들 중 하나를 점수화하는 것은 본질적인 이유가 아니라 범위(scope)의 문제로 인해 우리 자체 그림의 평균을 움직일 것이다. UCP는 흥미로운 사례이다: 이는 방어 가능한 점수를 반환할 것이지만, 우리는 여전히 그것을 제외했다.

또한 사양들은 검토 주기보다 더 빠르게 움직인다. 그래서 이 조사는 1페이지에 2026년 1분기(Q1)의 마감 시점을 선언하고, 모든 주장 뒤에 정확한 버전과 커밋을 고정한다. 그러한 정밀함은 괴짜 같은 것이 아니다. 우리가 읽은 한 프로토콜은 동일한 버전 문자열을 선언하는 두 개의 릴리스 태그를 배포하는데, 그 차이가 수천 줄의 코드에 달한다.

우리가 예상치 못한 루프

우리는 세 가지 격차에 대해 확장 방안을 제안했습니다. 작업 공간 명명 체계(workspace naming scheme), 컨텍스트 선택 봉투(context-selection envelope), 그리고 이그레스 증명서 봉투(egress-attestation envelope)입니다. 우리는 세 개의 독립적인 제안이 될 것이라고 예상했습니다.

하지만 그것들은 하나의 루프의 세 다리임이 밝혀졌습니다. 규범적 작업 공간 이름이 없는 가드레일 봉투는 중복된 명명 표준을 만들어내야 합니다. 경계 개념이 없는 선택 봉투는 정책을 기반으로 삼을 것이 없습니다. 그리고 이 둘 중 어느 것도 범위가 없으면서도 강제력이 없는 명명 체계입니다.

이는 해당 설문조사가 루브릭 축(rubric axes)들이 독립적으로 다뤄질 수 없는 가장 명확한 논거입니다. 신원 확인(Identity), 권한 부여(authorisation), 그리고 보안은 조직 경계를 넘나드는 모든 배포에서 세 가지 모자를 쓰는 하나의 문제입니다.

이 세 가지 모두는 검증된 표준이라기보다는 다음 개정 주기를 위한 사양 스케치이며, 저희가 과장하여 설명하기보다는 그렇게 명명하는 것이 낫습니다.

전체 논문 읽기: [https://hal.science/hal-05751265]

만약 한 부분이 잘못되었다면, 출판하기 전에 듣는 편이 낫습니다. 이미 여러 곳에서 그런 방식으로 변경되었는데, 여기에는 주 저자가 너무 관대했다고 말한 후 점수를 낮춘 경우도 포함됩니다.