Sierra Personal Agent Protocol, 35개 파트너 추가했지만 기업이 통제권 유지

Sierra는 35개의 새 설계 파트너와 함께 Personal Agent Protocol 초안을 공개하며 Poppy를 제안 단계에서 본격적인 표준화 노력으로 전환했다. Sierra Personal Agent Protocol에는 이제 OpenAI, Bank of America, Mastercard, PayPal, Visa, Cloudflare 등 주요 기업의 의견이 반영되고 있다.

이 발표가 중요한 이유는 개인 에이전트가 사람을 위해 설계된 인터페이스를 통해 기업 시스템에 진입하는 경우가 많기 때문이다. 이들은 페이지를 탐색하고, 양식을 작성하며, 때로는 폭넓은 계정 접근 권한을 지닌 자격 증명을 사용한다. Poppy는 기업이 에이전트를 식별하고, 사용자가 권한을 승인하며, 하나의 세션이 웹사이트, API, 기업 에이전트를 넘나들 수 있도록 하는 중간 경로를 제안한다.

이 중간 경로는 핵심 갈등도 만들어 낸다. 개인 에이전트는 유용하려면 폭넓고 일관된 접근 권한이 필요하지만, 기업은 신원, 권한, 채널, 고객 관계를 통제하고자 한다. Sierra는 그 경계를 협상하기 위해 이례적으로 폭넓은 그룹을 모았다. 다만 이들 기업이 결과물인 프로토콜을 배포할 것인지는 아직 보여주지 못했다.

Sierra Personal Agent Protocol, 35개 설계 파트너 추가

Poppy는 초기 발표 단계에서 공개 기술 초안 단계로 나아갔지만, 참여는 여전히 프로덕션 도입이 아닌 설계 의견 제공을 뜻한다.

Sierra는 2026년 10월 9일 Poppy 초안을 공개했다. 회사는 금융, 소매, 여행, 보험, 미디어, 신원, 통신, AI 분야에 걸친 35개의 추가 설계 파트너도 발표했다.

새 그룹에는 Adyen, Atomic, Bank of America, BBVA, Chime, Cigna, Cloudflare, Comcast, DIRECTV, ElevenLabs, FOX, Gap Inc., GEICO, Hertz가 포함된다. 또한 Insurify, Klaviyo, Liberty Mutual, Mastercard, Nordstrom, Notion, Okta, OneSignal, OpenAI, PayPal, Plaid, SiriusXM도 포함된다.

Synchrony, Target, United Airlines, Venmo, Visa, Wells Fargo, Zapier, Zendesk, 1Password가 추가 그룹을 완성한다. 이들 조직은 Meta, Genesys, Instinct, NiCE, Rocket, Shopify, Stripe, Walmart 등 초기 발표에 참여한 기업들과 합류한다.

초기 그룹과 35개 추가 기업의 구분은 중요하다. Sierra는 총 35개 참여 기업을 발표한 것이 아니다. 10월 6일 Meta와 여러 비즈니스 기술 파트너와 함께 프로젝트를 소개한 뒤, 35개 기업을 추가로 발표했다.

Sierra에 따르면 새 기업들은 각자의 비즈니스 요구사항을 바탕으로 피드백을 제공할 예정이다. 이 목록은 일반적으로 거래에서 서로 다른 위치를 차지하는 조직들을 한데 모은다.

은행과 결제 네트워크는 신원, 사기, 승인, 결제를 관리한다. 소매업체는 재고, 결제, 반품, 고객 계정을 통제한다. 신원 제공업체는 인증을 관리한다. AI 기업은 접근 권한을 요청할 개인 에이전트를 구축한다.

이들의 이해관계는 겹치지만 동일하지는 않다. 하나의 통합으로 많은 기업에 도달할 수 있을 때 에이전트 개발자는 이점을 얻는다. 은행은 각 행위가 추적 가능하고, 제한되며, 되돌릴 수 있을 때 이점을 얻는다. 소매업체는 서비스 정책이나 고객 관계에 대한 통제권을 잃지 않으면서 에이전트 트래픽을 원한다.

그렇기에 파트너 목록은 익숙한 로고의 집합 이상이다. 이는 Sierra가 탐색, 위임된 접근, 실제 행위 간 경계에 합의해야 하는 당사자들과 접촉할 수 있게 해준다.

그러나 설계 파트너가 자동으로 구현 업체가 되는 것은 아니다. Sierra는 Poppy의 프로덕션 사용 수치, 완료된 통합, 거래량을 공개하지 않았다. 이번 발표는 모든 명시 기업에 걸친 운영 지원이 아니라 설계 과정 참여를 확립한다.

Sierra는 다음 달에 설계 워크숍을 진행하고 참조 구현을 공개할 것이라고 밝혔다. 이러한 결과물은 파트너 수보다 더 강력한 시험대가 될 것이다. 개발자는 구현 비용을 판단하기 전에 작동하는 코드, 테스트 환경, 안정적인 적합성 규칙이 필요하다.

따라서 현재 공개는 프로토콜의 성숙도보다 신뢰도를 바꾼다. Poppy는 이제 공개 사양과 많은 관심 기업을 확보했다. 하지만 여전히 Draft 0.1 단계이며, 주요 기술 및 거버넌스 결정은 열려 있다.

Poppy는 권한을 제품으로 만든다

Poppy의 주요 기여는 또 하나의 에이전트 메시징 형식이 아니다. 기업이 통제하는 시스템 안에서 동작하는 에이전트를 위한 공유 세션 및 권한 모델이다.

Draft 0.1 사양은 개인 에이전트를 한 명의 사용자를 위해 동작하는 소프트웨어로 정의한다. 또한 기업을 해당 에이전트가 자사 서비스와 상호작용하도록 허용하는 조직으로 정의한다.

참여 기업은 /.well-known/poppy.json에 탐색 문서를 게시한다. 이 문서는 조직을 식별하고 인증 옵션, API, 웹사이트 접근, 기업 에이전트, 지원 확장 기능을 나열한다.

이 패턴은 다른 well-known 웹 탐색 메커니즘과 유사하다. 에이전트 개발자가 별도의 통합 지침을 찾아야 하는 대신, Poppy는 에이전트에 예측 가능한 하나의 시작 주소를 제공한다.

탐색은 첫 번째 계층일 뿐이다. 개인 에이전트는 특정 사용자를 위한 세션을 열고 기업에 자신을 식별한다. 이 설계는 기업이 자동화된 활동과 사람이 사이트를 직접 사용하는 활동을 구분할 수 있게 한다.

세션은 계정 접근 없이 시작할 수 있다. 예를 들어 에이전트는 게스트로서 제품 재고 여부를 확인하거나 반품 정책을 문의할 수 있다. 작업에 개인 계정 정보나 계정 변경이 필요할 때 사용자가 로그인한다.

Poppy는 직접 로그인, 기기 로그인, 중개 로그인을 정의한다. 직접 로그인은 인증을 기업 자체 페이지에서 유지한다. 기기 로그인에서는 사용자가 링크를 따라가고 코드를 입력해 다른 기기에서 접근을 승인한다.

중개 로그인은 기업이 해당 방식을 허용할 경우 에이전트가 기업 지정 엔드포인트로 자격 증명을 전송하도록 한다. 이 옵션은 호환성을 제공하지만, 초안에서 가장 민감한 보안 질문 중 하나도 만들어 낸다.

승인이 완료되면 에이전트는 범위가 지정된 접근 권한을 받는다. 광범위한 poppy:read 범위는 계정 정보 조회를 다루고, poppy:write는 교환이나 예약 변경과 같은 변경을 다룬다. 기업은 더 좁은 활동을 위해 추가 범위를 정의할 수 있다.

이 범위는 만족스럽지 못한 두 극단 사이에 권한 사다리를 만든다. 기업은 모든 에이전트를 차단할 필요가 없다. 사용자 역시 계정을 통해 이용 가능한 모든 기능을 에이전트에 부여할 필요가 없다.

세션은 지원되는 인터페이스 전반에서 사용자를 따라간다. 에이전트는 웹페이지, OpenAPI 엔드포인트, MCP 서버, 기업 에이전트와의 대화 사이를 이동할 수 있다. 로그인 전 질문과 이후 계정 변경은 하나의 방문 과정으로 유지될 수 있다.

이러한 연속성은 양측 모두에 중요하다. 사용자는 동일한 목표를 반복해서 설명하지 않아도 된다. 기업은 세션이 채널 전반에서 어떻게 진행됐는지에 대한 더 일관된 기록을 받는다.

Poppy는 사람을 에이전트 대화에 참여시키는 방법도 정의한다. 메시지는 AI 또는 사람이 작성했는지를 명시한다. 개인 에이전트는 상담원 연결을 요청할 수 있고, 사용자는 에이전트들의 이전 대화를 읽지 않고 직접 대화에 참여할 수 있다.

취소된 항공편을 생각해 보자. 개인 에이전트는 항공사의 지원 인터페이스를 탐색하고, 세션을 시작하며, 계정 접근 없이 대체편을 검색할 수 있다. 이후 사용자는 로그인하고, 예약 접근을 승인하며, 대체 항공편을 확정할 수 있다.

소매업체는 다른 정책을 적용할 수 있다. 저장된 결제 정보 변경은 차단하면서 에이전트가 반품 절차를 시작하도록 허용할 수 있다. 각 권한이 어떤 작업을 해제하는지는 개인 에이전트가 아니라 기업이 결정한다.

이 메커니즘은 기업에 이 프로토콜이 매력적인 이유를 설명한다. Poppy는 기업에 외부 에이전트에 정책을 넘기라고 요구하지 않는다. 대신 여러 기술 채널에서 이러한 정책을 공개하고 집행하는 표준 방식을 제시한다.

개인 에이전트가 아닌 기업이 주도권을 유지한다

프로토콜은 사용자 선택권을 약속하지만, 그 아키텍처는 참여 기업에 어떤 에이전트가 들어오고 무엇을 할 수 있는지에 대한 상당한 통제권을 부여한다.

Sierra는 Poppy를 에이전트 접근과 기업 감독 사이의 타협안으로 제시한다. 사용자는 개인 에이전트를 선택하고 계정 권한을 승인한다. 기업은 지원할 인터페이스, 로그인 방식, 범위, 작업을 결정한다.

이러한 구분은 높은 수준에서는 균형 있어 보인다. 실제 결과는 기업이 구현을 어떻게 구성하느냐에 달려 있다.

기업은 웹사이트만, 일부 API만, 또는 제한된 작업 범위를 가진 기업 에이전트만 게시할 수 있다. 쓰기 접근 없이 읽기 접근만 지원할 수 있다. 민감한 작업에는 직접 로그인을 요구하고, 인식하지 못하는 에이전트는 거부할 수 있다.

따라서 이 프로토콜은 보편적 접근보다 협상을 표준화한다. Poppy 파일을 게시한다고 해서 기업이 모든 고객 작업을 공개해야 하는 것은 아니다. 이는 어떤 문이 존재하며 어떤 조건이 적용되는지를 에이전트에 알려줄 것이다.

이 모델은 현재 웹에서 비용이 큰 갈등을 직접 다룬다. 기업은 사람이 사용하는 인터페이스를 이용하는 에이전트가 악용처럼 보일 수 있기 때문에 자동화를 탐지하려는 경우가 많다. 에이전트 개발자는 그러한 통제에도 기능을 유지하도록 브라우저를 조정한다.

이 경쟁에서는 어느 쪽도 신뢰할 수 있는 정보를 얻지 못한다. 기업은 어떤 서비스가 에이전트를 운영하는지 또는 어느 사용자를 대표하는지 알지 못할 수 있다. 에이전트는 실패한 작업이 정책, 인증, 인터페이스 변경 중 무엇 때문인지 알지 못할 수 있다.

Poppy는 그 모호성 일부를 명시적인 신원과 정책으로 대체한다. 기업은 개인 에이전트의 클라이언트 신원을 인식하고, 이를 한 사용자와 연결하며, 승인된 범위로 제한된 토큰을 발급할 수 있다.

이러한 체계는 합법적 에이전트를 익명의 자동화와 더 쉽게 구분하게 해야 한다. 그렇다고 사기, 탈취된 계정, 프롬프트 인젝션, 악의적인 에이전트 개발자가 사라지는 것은 아니다. 보안 통제를 적용하기 위한 더 구조화된 증거를 만든다.

사용자는 더 명확한 선택권을 얻지만, 그 선택은 여전히 기업 정책에 의해 제한된다. 기업이 전혀 공개하지 않는 기능을 사용자가 에이전트에 부여할 수는 없다. 마찬가지로 한 참여 기업이 다른 기업에 자신이 선호하는 에이전트를 받아들이도록 강요할 수도 없다.

이것이 Sierra Personal Agent Protocol의 핵심적인 트레이드오프다. 일관된 탐색과 승인은 합법적 에이전트 접근을 확장할 수 있다. 동시에 이 설계는 각 기업이 그 접근을 제한할 권리도 공식화한다.

이러한 균형은 규제 대상 조직의 도입을 장려할 수 있다. Bank of America, BBVA, Wells Fargo, Cigna와 여러 보험사는 무제한 자동화를 비현실적으로 만드는 의무를 안고 있다. 이들은 감사 가능성과 데이터 조회 및 계정 변경 사이의 강력한 구분이 필요하다.

결제 기업도 비슷한 유인을 가진다. Mastercard, Visa, PayPal, Venmo, Adyen, Plaid, Synchrony는 어느 당사자가 작업을 시작했는지 알아야 한다. 또한 고객과 거래 사이에 AI 인터페이스가 놓일 때에도 유지되는 통제가 필요하다.

개인 에이전트 개발자에게도 이 타협안은 맞춤형 통합을 줄인다면 여전히 매력적이다. 기업마다 다른 비즈니스 작업을 공개하더라도 하나의 탐색 형식과 하나의 인증 모델은 가치가 있을 수 있다.

더 큰 위험은 표준 내부의 파편화다. 기업은 맞춤형 범위와 확장 기능을 정의할 수 있으며, 각 API는 자체 스키마를 유지한다. 두 조직이 모두 Poppy를 지원하더라도 매우 다른 구현 작업이 필요할 수 있다.

Poppy는 에이전트가 도착하고, 자신을 식별하며, 접근을 요청하는 방법을 표준화할 수 있다. 모든 모기지 신청, 보험 청구, 항공편 변경, 소매 반품을 자동으로 표준화할 수는 없다.

그 한계가 이 프로젝트를 무의미하게 만드는 것은 아니다. 오히려 어려운 작업이 어디서 시작되는지를 분명히 한다. 프로토콜은 공통된 진입점을 마련할 수 있지만, 그 안에서 무엇이 일어나는지는 여전히 산업별 주체와 개별 기업이 정의한다.

기존 에이전트 표준은 경쟁자가 아니라 입력 요소다

Poppy는 MCP, A2A, OpenAPI 또는 커머스 프로토콜을 대체하기보다 기존 표준을 활용하는 오케스트레이션 계층일 때 가장 설득력이 있다.

현재 에이전트 표준은 여러 서로 다른 경계를 다룬다. 이를 단 하나의 승자가 모든 것을 가져가는 경쟁으로 보면 각 표준이 해결하려는 문제가 가려진다.

Anthropic은 AI 애플리케이션과 외부 도구 또는 데이터를 연결하는 표준으로 Model Context Protocol을 소개했다. MCP 서버는 AI 클라이언트가 발견하고 호출할 수 있는 기능을 노출할 수 있다.

Google은 독립적인 에이전트 간의 통신과 협업을 위해 처음으로 A2A protocol을 개발했다. A2A는 공급업체 경계를 넘어 에이전트가 작업, 메시지, 아티팩트, 상태 정보를 교환하는 데 초점을 둔다.

Poppy는 더 폭넓은 사용자-기업 관계를 다룬다. 여기에는 기업 발견, 개인 에이전트 신원, 사용자 세션, 권한 부여, 웹 브라우징, API, 기업-에이전트 대화, 사람에게 이관하는 절차가 포함된다.

이 차이는 Poppy의 아키텍처에서 드러난다. 기업은 사용 가능한 API 중 하나로 MCP 서버를 등록할 수 있다. OpenAPI 설명을 등록하거나, 일반 웹사이트를 제공하거나, 기업 에이전트를 노출할 수도 있다.

따라서 MCP는 Poppy 세션 안에서 활용할 수 있는 하나의 경로다. Poppy는 도구 인터페이스만으로는 완전히 정의되지 않는 신원, 사용자 권한 부여, 채널 간 연속성을 제공한다.

A2A도 비슷한 관계에 있다. 기업 에이전트와 개인 에이전트에는 소통 수단이 필요하지만, 그 대화는 방문 경험의 한 부분일 뿐이다. 개인 에이전트는 페이지를 탐색하거나 일반적인 API를 호출할 수도 있다.

커머스 표준은 또 다른 계층을 만든다. Shopify와 Google의 Universal Commerce Protocol은 상품 발견, 결제, 주문 관리 같은 커머스 활동에 초점을 둔다.

Sierra는 UCP를 명시적으로 보완적이라고 설명한다. Poppy는 에이전트가 누구를 대표하는지와 사용자가 무엇을 승인했는지를 확립할 수 있다. 이후 커머스 프로토콜은 구매 또는 주문 관리에 수반되는 도메인별 작업을 정의할 수 있다.

이 계층형 접근 방식은 기업들이 이미 다양한 기술 스택을 사용한다는 점에서 실용적이다. 한 소매업체는 UCP 커머스 워크플로, MCP 고객 서비스 서버, 일반 웹 페이지를 함께 제공할 수 있다. Poppy는 이러한 접점을 하나의 인식된 세션으로 연결하는 것을 목표로 한다.

이 접근 방식은 모든 비즈니스 프로세스를 자연어 기반 에이전트 대화에 억지로 넣는 일도 피한다. 많은 작업에서 구조화된 API는 여전히 더 효율적이고 예측 가능하다. 웹 접근은 최신 API가 없는 오래된 시스템을 포괄할 수 있다.

Sierra는 이 프로토콜이 OAuth, HTTPS, JSON Web Tokens, OpenAPI, MCP를 기반으로 구축됐다고 말한다. 이러한 선택은 기존 웹 보안 및 API 도구에 익숙한 팀의 개념적 진입 장벽을 낮춘다.

확립된 구성 요소를 사용한다고 해서 상호운용성이 보장되는 것은 아니다. 주변 프로필은 두 독립 구현이 일관되게 동작할 수 있을 만큼 정밀해야 한다. 토큰 대상, 범위 적용, 재시도, 실패 상태를 둘러싼 모호성은 여전히 호환되지 않는 시스템을 만들 수 있다.

이 때문에 프로토콜의 참조 구현이 중요하다. 개발자에게는 문서상의 요구사항만으로는 부족하다. 에이전트 등록, 발견 검증, 토큰 교환, 브라우저 세션, 대화 이관을 위한 테스트 가능한 예제가 필요하다.

적합성 평가에도 같은 원칙이 적용된다. 각 기업이 선택적 기능을 서로 다르게 해석한다면 개인 에이전트는 여전히 조직별 로직을 필요로 하게 된다. 유용한 표준은 기본 호환성을 위해 어떤 동작이 필수인지 명시해야 한다.

Poppy의 폭넓은 파트너 그룹은 이러한 세부 사항을 해결하는 데 도움이 될 수 있다. 동시에 참여자들이 경쟁 플랫폼, 규제 환경, 고객 관계를 대표하기 때문에 합의를 늦출 수도 있다.

가장 바람직한 결과는 하나의 프로토콜이 모든 다른 프로토콜을 대체하는 것이 아니다. 각 계층이 명확한 책임을 지는 스택이다. Poppy는 그 스택 전반에서 신원, 권한, 세션 연속성을 예측 가능하게 만들 때 성공한다.

초안은 어려운 보안 질문을 남겨 둔다

Poppy는 보안 구조를 제공하지만, Draft 0.1이 소프트웨어가 고객 계정을 통해 행동할 때 발생하는 위험을 없애지는 못한다.

사양은 안정 버전이 나오기 전까지 Draft 0.1의 모든 부분이 변경될 수 있다고 경고한다. 이 계층의 권한 부여 오류는 구매, 예약, 금융 신청, 개인 데이터에 영향을 줄 수 있기 때문에 이 경고는 중요하다.

Poppy는 수명이 짧은 세션 토큰을 사용하고 요청을 에이전트 신원에 연결한다. 또한 요청자가 토큰과 연결된 키를 보유하고 있음을 증명하는 proof-of-possession 보호도 설명한다.

이러한 통제는 토큰 재사용을 줄이고 기업이 자동화된 활동의 주체를 추적하는 데 도움이 될 수 있다. 그러나 그 효과는 올바른 구현, 안전한 키 저장, 노출된 모든 인터페이스 전반의 일관된 검증에 여전히 달려 있다.

채널 간 세션은 편의성을 높이지만 적용 범위도 넓힌다. 기업은 API, 브라우저 엔드포인트, 에이전트 대화 전반에 걸쳐 동일한 계정 상태와 권한 경계를 적용해야 한다.

API에서는 적용되지만 웹 페이지에서는 무시되는 범위는 우회 경로를 만든다. 세션의 권한을 벗어난 작업을 수행하는 기업 에이전트도 또 다른 우회 경로를 만든다.

중개 로그인은 특히 면밀히 검토할 필요가 있다. 이 모델에서 개인 에이전트는 자격 증명을 기업에 전송하기 전에 이를 처리한다. 사양은 에이전트가 비밀 필드를 보호하고 이를 표시하거나 기록하지 않도록 요구한다.

이 요구사항은 유용하지만, 모든 에이전트가 자격 증명을 안전하게 처리한다는 사실을 증명할 수는 없다. 기업은 민감한 계정에서 중개 로그인이 허용할 수 없는 노출을 초래한다고 판단할 수 있다.

직접 로그인은 사용자가 기업 자체 페이지에서 인증하기 때문에 더 명확한 경계를 제공한다. 개인 에이전트가 다른 기기에서 작동할 때는 기기 로그인이 비슷한 분리를 제공할 수 있다.

권한 설계도 또 다른 문제를 제시한다. 광범위한 read 및 write 범위는 단순하지만, 실제 서비스에는 결과가 크게 다른 작업들이 존재한다.

뉴스레터 환경설정을 변경하는 것과 우편 주소를 변경하는 것은 모두 쓰기 작업이다. 재킷을 반품하는 것과 송금하는 것 역시 모두 쓰기 작업이다. 기업은 영향이 큰 작업에 대해 더 세분화된 맞춤 범위나 추가 승인을 필요로 할 것이다.

맞춤 범위는 통제력을 높이지만 상호운용성을 위협한다. 에이전트는 사용자에게 설명하기 전에 각 범위의 의미를 이해해야 한다. 유사한 작업도 기업마다 다른 이름을 가질 수 있다.

사용자 이해도 역시 중요하다. 사람들은 세부 사항을 살피지 않은 채 접근 권한 요청을 승인하는 경우가 많다. 하나의 승인이 반복적인 자율 작업을 지원할 수 있기 때문에 에이전트가 추가되면 위험은 더 커진다.

신뢰할 수 있는 인터페이스는 어떤 에이전트가 접근을 요청하는지, 어떤 계정을 사용할지, 무엇을 읽을 수 있는지, 무엇을 변경할 수 있는지를 설명해야 한다. 또한 권한 철회도 쉽게 할 수 있어야 한다.

초안은 권한 철회를 지원하며, 이후 세션을 시작하기 위한 장기 계정 토큰도 설명한다. 이러한 편의성은 사용자 계정과 개인 에이전트 간의 지속적인 관계를 만든다.

기업과 에이전트 제공업체는 이러한 관계에 대한 명확한 기록을 유지해야 한다. 사용자는 활성 연결, 부여된 범위, 최근 작업, 만료일을 확인할 수 있어야 한다.

프롬프트 인젝션은 프로토콜이 직접 통제할 수 있는 범위 밖에 남아 있다. 에이전트는 웹페이지, 메시지, 외부 문서에서 악의적인 지시를 받을 수 있다. 유효한 인증이 에이전트의 최종 결정이 사용자의 의도와 일치한다는 것을 보장하지는 않는다.

이 우려는 에이전트가 여러 출처의 정보를 결합할 때 특히 중요하다. 우수한 personal knowledge management는 맥락을 개선할 수 있지만, 더 많은 맥락은 공개와 행동을 둘러싼 더 강력한 경계를 요구한다.

사람의 확인은 구매, 예약, 계정 변경의 위험을 줄일 수 있다. 하지만 모든 작은 단계마다 확인을 요구하면 개인 에이전트가 약속하는 효율성이 훼손될 수 있다.

따라서 이 프로토콜에는 안전한 토큰 교환 이상의 것이 필요하다. 구현에는 위험 기반 승인, 거래 기록, 복구 절차, 에이전트가 비용이 큰 실수를 했을 때의 명확한 책임 소재가 필요하다.

은행, 결제, 신원, 보험, 클라우드 보안 분야의 디자인 파트너는 이러한 질문을 스트레스 테스트하는 데 도움이 될 수 있다. 하지만 그들의 이름만으로 답이 되지는 않는다.

독립적인 보안 검토도 또 다른 중요한 신호가 될 것이다. 공개 위협 모델, 상호운용성 테스트, 문서화된 실패 사례는 신뢰나 통제에 대한 선언보다 더 많은 근거를 제공한다.

Poppy는 적대적 조건에서도 통제가 일관되게 유지되는지로 평가받아야 한다. 성공적인 시연은 유용하다. 복구 가능한 실패는 종종 더 많은 정보를 제공한다.

Poppy의 미래를 결정할 세 가지 신호

작동하는 코드, 실제 기업 도입, 독립적인 보안 테스트가 Poppy가 인프라가 될지 야심 찬 초안으로 남을지를 결정할 것이다.

첫 번째 신호는 Sierra가 약속한 참조 구현이다. 회사는 다음 달에 열릴 디자인 워크숍 이후 이를 공개할 계획이라고 말한다.

유용한 릴리스에는 상호작용의 양쪽이 모두 포함돼야 한다. 개발자에게는 샘플 개인 에이전트, 참여 기업 서비스, 발견 문서, 인증 흐름, 범위 적용 테스트가 필요하다.

구현은 실패 상황도 보여줘야 한다. 만료된 토큰, 철회된 접근 권한, 불충분한 범위, 중복 메시지, 사람에게 이관하는 절차, 중단된 스트림은 운영 시스템에서 정상적으로 발생하는 조건이다.

명확한 코드와 적합성 테스트는 기업이 익숙한 도구로 프로토콜을 구현할 수 있다는 Sierra의 주장을 강화할 것이다. 지연되거나 제한적으로 각본화된 데모는 그 주장을 약화할 것이다.

두 번째 신호는 실명 파트너의 도입이다. 파트너가 관리하는 도메인에 공개된 poppy.json 파일은 또 하나의 디자인 발표보다 더 큰 무게를 지닐 것이다.

초기 배포가 모든 작업을 지원할 필요는 없다. 소매업체는 상품 문의와 반품 상태로 시작할 수 있다. 항공사는 예약 변경을 허용하기 전에 운항 일정 정보를 노출할 수 있다.

중요한 것은 독립적인 개인 에이전트가 비공개 통합 없이 이러한 기능을 발견하고 사용할 수 있는지다. 접근에 여전히 맞춤 계약과 문서화되지 않은 동작이 필요하다면, 이 표준은 이식성을 제공하지 못한 것이다.

개인 에이전트 측면에서는 OpenAI와 Meta가 특히 중요하다. 이들의 참여는 광범위한 배포 가능성을 만든다. 하지만 어느 쪽의 이름도 소비자 제품이 Poppy를 지원할 것이라고 보장하지는 않는다.

기업 측면에서는 은행, 결제 회사, 소매업체, 여행 제공업체가 중요하다. 이들의 배포 선택은 어떤 인증 및 권한 모델이 규제와 사기 검토를 통과하는지를 보여줄 것이다.

세 번째 신호는 보안 모델이 통제된 시연을 넘어 작동한다는 증거다. 공개 위협 모델, 제3자 감사, 상호운용성 행사, 테스트 이후 문서화된 수정 사항을 주시해야 한다.

계정 작업을 가능하게 하는 프로토콜은 면밀한 검토를 받게 된다. 이는 건전한 일이다. 연구자들은 발견 검증, 토큰 바인딩, 맞춤 범위, 브라우저 세션, 자격 증명 처리, 에이전트 사칭 방어를 테스트할 수 있어야 한다.

이 세 가지 신호는 서로를 강화한다. 참조 코드는 테스트를 가능하게 한다. 실제 배포는 운영 문제를 드러낸다. 독립 검토는 약점이 여러 서비스로 확산되기 전에 이를 찾아낸다.

파트너 목록은 Sierra Personal Agent Protocol에 강력한 출발점을 제공한다. 이는 개인 에이전트가 질문에 답하는 단계에서 거래를 완료하는 단계로 이동할 때 가장 큰 영향을 받는 산업을 아우른다.

그럼에도 표준의 성공은 발표의 추진력이 아니라 반복적인 구현에 달려 있습니다. 기업은 유용한 기능을 공개해야 합니다. 에이전트 제작자는 프로토콜을 일관되게 지원해야 합니다. 사용자는 자신이 부여하는 권한을 이해하고 신뢰해야 합니다.

개발자에게 당장의 과제는 초안을 검토하고 세션 모델을 기존 인증 아키텍처와 비교하는 것입니다. 가장 유용한 피드백은 구체적인 비호환성, 누락된 실패 상태 또는 불명확한 보안 요구 사항을 다루게 될 것입니다.

엔터프라이즈 구매자는 공급업체에 참여가 설계 피드백인지, 파일럿인지, 아니면 확정된 배포인지 물어야 합니다. 이 용어들은 매우 다른 수준의 지원을 의미합니다.

개인 에이전트 사용자는 실제로 어디에서 제어 기능이 나타나는지 지켜봐야 합니다. 활성 연결을 볼 수 있는지, 작업을 제한할 수 있는지, 기록을 검토할 수 있는지, 여러 제품을 오가지 않고 액세스를 취소할 수 있는지 확인해야 합니다.

Poppy는 에이전트 차단과 에이전트 위장 사이의 불안정한 경쟁을 명시적 협력으로 대체하려 하고 있습니다. 이는 가치 있는 목표입니다. 다음 한 달은 Sierra와 그 파트너들이 이 목표를 다른 이들도 안전하게 구현할 수 있는 코드로 바꿀 수 있는지 보여줄 것입니다.