Shufti Know Your Agent, AI 작업을 검증된 소유자 및 권한과 연결

Shufti는 10월 28일 Know Your Agent를 출시하며 신원 확인 범위를 AI 에이전트로 확장하는 한편, 검증된 소유권과 작업 권한을 분리했다. Shufti Know Your Agent는 고객이나 직원을 대신해 작동하는 소프트웨어의 자동화 요청을 받는 기업을 대상으로 한다. 핵심 주장은 명확하다. 계정 소유자를 식별했다고 해서 그 사람의 이름으로 수행된 모든 작업이 승인된 것은 아니다.

이번 발표는 에이전트를 거래 및 민감한 정보와 연결하는 기업에 압박을 가한다. 목표를 향해 작업을 선택하고 실행하는 소프트웨어인 AI 에이전트에는 활용 가능한 권한이 필요하다. 그러나 권한이 지나치게 광범위하게 부여되면 정당한 보조자가 무단 변경의 원인이 될 수 있다. 요청을 받는 기업은 승인된 요청과 유효한 자격 증명을 갖춘 채 도착했을 뿐인 작업을 구분해야 한다.

Microsoft Entra Agent ID는 에이전트 신원, 소유권, 액세스 관리를 통해 유용한 비교 대상이 된다. Shufti는 외부 에이전트, 검증된 소유자, 그리고 그 소유자의 위임 범위, 즉 위임된 권한의 경계 사이의 연결을 강조한다. 두 접근 방식은 서로 다른 출발점에서 겹치는 문제를 다룬다. 중요한 질문은 에이전트가 지시에서 실제 거래로 이동할 때에도 권한 부여가 계속 강제될 수 있는지다.

Shufti Know Your Agent, 에이전트 검증에 소유권과 위임 범위 추가

Shufti의 에이전트 검증 출시 발표는 에이전트 신원, 인간의 승인, 권한 검사를 결합한 서비스를 설명한다. 회사는 기존 고객 및 기업 검증 절차를 통해 에이전트를 개인 또는 기업과 연결한다고 밝혔다. 소유자는 허용 작업, 한도, 만료, 철회를 정의하며, 철회는 이전에 부여한 권한을 거두는 것을 뜻한다. Shufti는 이러한 위임 범위가 각 요청에 적용된다고 말한다.

이번에 발표된 변화는 신원 확인만이 아니라, 식별된 소유자와 범위가 제한된 작업을 연결하는 데 있다.

이 구분이 중요한 이유는 기업이 요청을 받을 뿐, 그 요청을 만들어 낸 전체 대화를 받지는 않기 때문이다. 고객은 보조자에게 금융 서류를 정리해 달라고 요청할 수 있다. 그렇다고 해서 송금, 계좌 정보 변경, 다른 서비스와의 문서 공유까지 반드시 허용한 것은 아니다. 요청을 받는 시스템에는 고객이 실제로 위임한 내용을 강제 가능한 방식으로 해석할 수단이 필요하다.

Shufti는 에이전트가 기업에서 철회할 수 있는 만료형 자격 증명을 받는다고 말한다. 10월 30일자 에이전트 권한 부여 보도 역시 요청, 결정, 철회된 권한을 에이전트 및 소유자와 연결하는 기록을 설명한다. 이는 여전히 보도된 제품 기능이다. 해당 보도는 사기 감소, 운영 신뢰성, 고객 도입에 관한 독립적인 결과를 입증하지는 않는다.

따라서 이번 출시는 그 효과를 확정하지 않은 채 이용 가능한 제품 제안을 변화시킨다. 기업은 위임된 에이전트 권한을 중심으로 명시적으로 구성된 서비스를 평가할 수 있다. 그러나 그 결정이 자체 거래 규칙과 일치한다는 증거는 여전히 필요하다. 검증 결과는 이를 받는 애플리케이션이 해당 결과가 정확히 무엇을 허용하는지 이해할 때에만 유용하다.

소프트웨어를 인식하는 것과 현재 권한을 인식하는 것 사이에도 중요한 차이가 있다. 하나의 보조자는 서로 다른 고객을 위해 작업하면서도 동일하게 인식 가능한 제품으로 남을 수 있다. 동일한 고객도 서로 다른 제한이 적용되는 별도 작업을 맡길 수 있다. 기업은 보조자의 브랜드, 이전 행동, 또는 성공적으로 인증했다는 사실만으로 권한을 추정할 수 없다.

액세스 토큰, 즉 접근을 얻기 위해 제시되는 자격 증명은 올바르게 구현될 경우 제한된 권한을 담을 수 있다. 따라서 Shufti의 주장은 토큰에 본질적으로 경계가 없다는 증거가 아니라, 불충분한 권한 부여 설계에 대한 문제 제기로 이해해야 한다. 실질적인 쟁점은 자격 증명이 나타내는 권한이 특정 비즈니스 작업과 일치하는지다.

이러한 틀은 발표를 현실에 맞게 유지한다. Shufti는 신원과 위임된 권한을 연결하는 또 다른 방식을 제공하고 있다. 구매자는 원래는 정당한 에이전트가 소유자가 전혀 승인하지 않은 작업을 요청할 때를 포함해, 요청을 받는 시스템이 무엇을 강제하는지로 그 연결을 판단해야 한다.

요청을 받는 기업이 권한 문제를 떠안는다

직접적인 압박은 고객이 제어하는 에이전트의 요청을 수용하는 조직에 가해진다. 은행, 마켓플레이스, 기업용 소프트웨어 제공업체는 어떤 자동화 작업을 일반 워크플로에 포함할지 결정해야 한다. 고객이 작업에 이의를 제기할 경우를 위한 방어 가능한 대응도 필요하다. 자동화를 수용하면 기존 계정 통제가 처리해야 하는 행위자의 범위가 넓어진다.

에이전트 활동을 수용하는 기업에는 고객 의도와 소프트웨어 재량 사이의 명확한 경계가 필요하다.

특정 사무 기기를 교체하라는 지시를 받은 가상의 쇼핑 보조자를 생각해 보자. 고객은 특정 제품 범주와 배송지를 허용한다. 결제 과정에서 보조자는 재고가 없는 상품을 발견하고 대체 상품을 선택한다. 이제 판매자는 비즈니스 판단에 직면한다. 그 대체 선택은 여전히 고객의 권한 범위 안에 있는가?

“적합한 것을 찾아라”와 같은 지시는 판단의 여지를 남긴다. 거래 시스템에는 더 명시적인 조건이 필요하다. 제품 제한, 수령인 정보, 구매 한도, 승인 요건은 작업을 진행해야 하는지를 결정한다. 이러한 조건이 에이전트 대화 속에 묻혀 있다면 판매자는 이를 신뢰성 있게 적용할 수 없다.

이로 인해 여러 팀에 걸친 업무가 생긴다. 제품 관리자는 에이전트가 중단 없이 완료할 수 있는 작업을 정의해야 한다. 보안 팀은 애플리케이션이 그러한 정의를 강제하도록 해야 한다. 고객 지원 팀은 일상적인 언어로 발생한 일을 설명하는 기록이 필요하다. 비즈니스 책임자는 어떤 예외에 재승인이 필요한지 결정해야 한다.

개발자는 관련된 통합 문제에 직면한다. 요청을 교환하는 데 쓰이는 소프트웨어 인터페이스인 애플리케이션 프로그래밍 인터페이스는 흔히 작업을 분리해 제공한다. 기록 조회, 편집, 내보내기, 삭제에는 서로 다른 권한이 필요할 수 있다. “계정 사용”에 대한 일반적 권한만으로는 고객이 어떤 조합을 의도했는지 설명할 수 없다.

에이전트가 작업 도중 방향을 바꿀 때 어려움은 더 분명해진다. 고객은 공급업체 조사를 승인했지만 주문 전에 별도의 결정을 기대할 수 있다. 작업 완료를 추구하는 보조자는 주문을 자연스러운 다음 단계로 간주할 수 있다. 요청을 받는 기업에는 이 전환을 인식하는 통제가 필요하다.

이 통제는 고객 경험에도 영향을 미친다. 무해한 모든 작업에 승인을 요구하면 위임이 불편해진다. 광범위한 권한을 허용하면 중요한 실수를 포착할 기회가 사라진다. 기업은 중단이 주의력과 완료 시간이라는 비용을 정당화할 만큼 충분한 보호를 제공하는 지점을 선택해야 한다.

이것이 Shufti의 발표가 신원 팀을 넘어서는 이유다. 이 제품 제안은 실제 비즈니스 결정을 반영하는 규칙에 의존한다. 검증은 관련 당사자를 식별할 수 있지만, 조직은 여전히 어떤 작업에 권한이 필요한지 정의해야 한다. 이 작업이 없다면 검증된 소유자는 지나치게 광범위한 권한 부여에 연결될 뿐이다.

그 결과 발생하는 압박은 기술적인 만큼 조직적이기도 하다. 기업은 누가 권한 규칙을 작성하고, 누가 변경을 승인하며, 누가 예외를 처리할지에 대한 합의가 필요하다. 에이전트 보안 제품은 편의성, 고객 통제, 운영 위험 사이에서 충돌하는 기대를 독립적으로 해결할 수 없다.

경쟁의 핵심은 권한이 어디에서 강제되는가다

Microsoft 문서는 소유권, 후원, 권한, 활동 기록을 포함한 에이전트 신원 관리를 설명한다. 이는 관리자가 에이전트를 검사하고 해당 액세스를 관리할 방법을 제공한다. Shufti의 발표는 개인이나 조직을 대신해 행동하는 에이전트를 기업이 검증하는 데 초점을 둔다. 비교의 핵심은 각 시스템이 어디에서 신뢰를 확립하고 통제를 적용하는가에 있다.

핵심적인 구분은 정당한 에이전트를 인식하는 것과 특정 임무의 경계를 강제하는 것 사이에 있다.

이 기능들은 서로 보완될 수 있다. 조직은 직원의 에이전트 신원을 중앙에서 관리하는 한편, 다른 기업은 그 에이전트의 구매 요청을 평가할 수 있다. 내부 시스템은 조직적 책임을 확립한다. 그러나 요청을 받는 시스템은 여전히 요청된 구매가 제시된 권한에 부합하는지 판단해야 한다.

어느 쪽도 상대방이 모든 질문에 답했다고 가정해서는 안 된다. 에이전트 운영에 대한 내부 승인이 모든 외부 거래를 자동으로 승인하지는 않는다. 직원에 대한 외부 검증도 해당 직원이 조직을 구속할 수 있음을 확립하지는 않는다. 각 요청 수신 시스템에는 자체 결정과 관련된 증거가 필요하다.

이 구분은 단순한 공급업체 비교를 피하게 한다. 디렉터리 중심 제품과 고객 검증 서비스는 서로를 대체할 필요가 없다. 그 가치는 환경, 관련된 신원 관계, 이미 배포된 통제에 따라 달라진다. 제품명만으로 동등한 적용 범위를 확립할 수는 없다.

Shufti Know Your Agent는 위임된 고객 작업을 강조하며 이 시장에 진입한다. 차별화는 기업이 이러한 위임 범위를 얼마나 효과적으로 강제 가능한 애플리케이션 동작으로 전환할 수 있는지에 달려 있다. 실행과 분리된 권한 결정은 제한적인 보호만 제공한다. 애플리케이션은 승인된 범위를 벗어난 작업을 실제로 거부해야 한다.

더 광범위한 보안 원칙은 이번 발표보다 앞선다. OWASP의 과도한 자율성 지침은 과도한 기능, 권한, 자율성에서 비롯되는 위험을 지적한다. 이 지침은 언어 모델의 판단에 의존하는 대신 하위 시스템에서 권한 부여를 강제할 것을 권고한다. 언어 모델은 학습된 패턴과 맥락을 바탕으로 응답을 생성하므로, 그 출력은 유일한 권한 경계로 적합하지 않다.

이 이야기에서 해당 지침은 Shufti에 대한 지지가 아니라 독립적인 기준을 제공한다. 관련 질문은 에이전트가 작업을 완료하려는 의지에도 불구하고 별도의 통제가 무단 작업을 막을 수 있는지다. 에이전트가 자신의 작업을 오해할 때에도 신원과 정책은 계속 유효해야 한다.

공급업체 메시지를 초안으로 작성할 수는 있지만 전송할 수는 없는 가상의 비즈니스 보조자를 상상해 보자. 이 구분은 메시징 서비스가 이를 강제할 때에만 유지된다. 보조자에게 제한을 기억하라고 요청하면 최종 결정을 실수를 저지르는 바로 그 시스템 안에 남겨 둔다. 전송을 거부하는 수신 서비스는 더 강한 경계를 설정한다.

이것이 이번 발표의 배후에 있는 경쟁 기준이다. 공급업체는 에이전트, 소유자, 승인 흐름을 서로 다르게 설명할 수 있다. 구매자는 결정적인 권한 검사가 어디에서 이뤄지는지 확인해야 한다. 가장 중요한 역량은 유효한 신원이 유효하지 않은 요청을 제시할 때 실행을 통제하는 능력이다.

인간 검토는 중단 없는 자동화와 추가 통제를 맞바꾼다

Shufti는 요청이 위임 범위를 초과하거나 위험 임계값을 넘을 때 추가적인 인간 확인을 제공한다고 설명합니다. 회사에 따르면 이 과정에는 실제 사람이 있는지를 평가하는 셀피 라이브니스 확인이 포함될 수 있습니다. 이는 그 밖에는 자동화된 워크플로에 인간의 판단 지점을 추가합니다. 그 유용성은 실제로 그 사람에게 무엇을 승인하도록 요청하는지에 달려 있습니다.

사람의 존재를 확인하는 것과 충분한 정보를 바탕으로 한 승인을 확인하는 것은 서로 다른 문제를 해결합니다.

사람은 제안된 거래를 이해하지 못한 채 신원 확인을 완료할 수 있습니다. 단지 “계속”이라고만 표시하는 승인 화면은 수신자, 작업 및 결과를 명시하는 화면보다 전달하는 정보가 적습니다. 보안 가치는 부분적으로 인터페이스가 결정을 이해할 수 있게 하는지에 달려 있습니다. 존재 확인만으로는 누락된 맥락을 제공할 수 없습니다.

이는 분석상의 한계이며, Shufti의 구현이 실패한다는 증거는 아닙니다. 발표에서는 에스컬레이션 메커니즘을 설명하지만, 고객이 승인 화면을 어떻게 해석하는지는 독립적으로 입증하지 않습니다. 구매자는 실제 경험을 살펴봐야 합니다. 성공적인 신원 확인과 명확하게 전달된 권한 부여 결정을 구분해야 합니다.

가상의 결제 사례는 그 차이를 보여 줍니다. 에이전트는 기존 공급업체에 결제할 권한으로 시작하지만, 이후 다른 수취인을 사용하라는 지시를 받습니다. 추가 확인은 이 변경을 중단할 기회를 만듭니다. 하지만 그 사람은 단지 신원을 다시 확인하라는 요청을 받는 것이 아니라 수취인이 변경되었음을 확인할 수 있어야 합니다.

승인은 최종 작업과도 계속 연결되어 있어야 합니다. 이후 중요한 거래 세부사항이 변경되면 이전 결정은 더 이상 실제로 일어날 일을 설명하지 못할 수 있습니다. 이는 수신 애플리케이션과 그 검증 통합을 위한 설계 문제입니다. 승인된 요청과 실행된 요청의 경계는 일치해야 합니다.

중단은 운영상의 선택지도 만듭니다. 에이전트는 소유자가 이용할 수 없는 동안 작업할 수 있습니다. 승인이 필요해지면 시스템에는 일시 중지, 거부 또는 초안 보존이라는 명확한 결과가 필요합니다. 작업을 계속 진행하기 위해 조용히 권한을 확대하면 확인 절차의 목적을 훼손하게 됩니다.

접근성과 복구에도 주의를 기울일 필요가 있습니다. 정당한 고객이 예상된 검증 방법을 완료하지 못할 수 있습니다. 기업에는 필요한 보증 수준을 유지하는 대안이 필요합니다. 그렇지 않으면 승인된 자동화를 지원하도록 설계된 통제가 유효한 권한을 가진 고객에게 장애물이 될 수 있습니다.

같은 긴장은 일반적인 지식 업무에서도 나타납니다. 정보를 찾고, 답변을 작성하고, 전송하고, 공유 기록을 변경하는 일은 각기 다른 수준의 결과를 수반합니다. 검색 가능한 지식 기반을 구축하는 팀은 자료를 검색하는 것과 후속 작업을 승인하는 것 사이에서 비슷한 경계에 직면합니다. 유용한 맥락에 접근할 수 있다고 해서 이를 게시하거나 수정할 권한이 자동으로 부여되는 것은 아닙니다.

따라서 이 절충점은 구체적입니다. 추가 검증은 중요한 순간에 인간의 통제권을 회복하는 동시에 위임을 중단시킬 수 있습니다. 기업은 거래 위험과 사용자 기대를 반영하는 임계값을 마련해야 합니다. 모든 중단을 보안상의 성공으로 간주하면, 그 사람이 의미 있는 결정을 내릴 만큼 충분한 정보를 받았는지를 놓치게 됩니다.

출시 발표의 주장은 효과성과 책임 소재를 여전히 열어 둡니다

11월 2일 기준으로 검토한 출처는 발표와 그에 명시된 설계를 뒷받침합니다. 그러나 완전한 서비스에 대한 독립적 평가는 제공하지 않습니다. 제품이 신원 확인, 권한 규칙, 거래 통제를 결합할 때 이 구분은 중요합니다. 한 구성 요소가 성공적으로 작동한다고 해서 전체 워크플로의 효과성이 입증되는 것은 아닙니다.

검증 격차는 완전한 시스템이 현실적인 실패 조건에서 올바른 결정을 강제하는지에 관한 문제입니다.

유용한 평가는 무단 요청과 정당한 활동을 모두 검토해야 합니다. 공격자를 차단하는 일은 중요하지만, 고객에게 허용된 작업이 완료되도록 하는 일도 중요합니다. 시스템이 일상적인 업무를 너무 자주 거부하면 기업은 규칙을 완화해야 한다는 압박을 받게 됩니다. 보안과 사용성은 함께 측정되어야 합니다.

공개 발표는 연결된 애플리케이션 전반에서 취소된 권한이 얼마나 신속히 활동을 멈추게 하는지 입증하지 않습니다. 이는 중요한 구현 문제입니다. 소유자가 권한을 취소할 때 에이전트에는 실행 대기 중인 요청이 있을 수 있습니다. 구매자는 그러한 요청이 완료 전에 다시 확인을 받는지 이해해야 합니다.

작업 체인은 또 다른 미해결 문제를 만듭니다. 보조자는 할당된 업무의 일부를 수행하도록 다른 서비스나 에이전트에 요청할 수 있습니다. 그러면 수신 기업은 원래 권한이 그러한 위임까지 포함하는지 이해해야 합니다. 명시적인 한계가 없다면, 명확했던 초기 위임 범위도 워크플로가 진행될수록 모호해질 수 있습니다.

행동 인식은 평가에 관한 별도의 질문을 제기합니다. 소프트웨어는 업데이트 후 행동을 바꾸거나 익숙하지 않은 작업을 마주할 수 있습니다. 구매자는 시스템이 정당한 변동과 의심스러운 활동을 어떻게 구분하는지 물어야 합니다. 검토한 출시 자료는 그러한 조건 전반의 독립적으로 측정된 정확도를 입증하지 않습니다.

이러한 질문을 발견된 취약점으로 제시해서는 안 됩니다. 이는 회사의 주장을 평가하는 데 필요한 증거를 가리킵니다. 검토한 어떤 출처도 Shufti의 서비스가 이 테스트에 실패한다는 점을 보여 주지 않습니다. 마찬가지로 발표만으로는 실제 운영 환경에서 이를 통과한다는 점도 입증되지 않습니다.

책임성 역시 비슷한 주의가 필요합니다. 에이전트와 소유자를 연결하는 기록은 조사관이 일련의 과정을 재구성하는 데 도움이 될 수 있습니다. 하지만 소유자가 요청을 이해했는지, 자격 증명이 탈취되었는지, 또는 애플리케이션이 올바르게 실행했는지까지 자동으로 해결하지는 않습니다. 이는 여전히 별개의 사실관계 질문입니다.

기록은 결정의 맥락을 보존할 때 더 유용해집니다. 조사관은 요청이 도착했을 때 어떤 권한이 적용됐는지와 최종적으로 어떤 작업이 발생했는지를 알아야 합니다. 현재 계정 설정이 과거 거래를 반드시 설명할 수 있는 것은 아닙니다. 증거는 검토자가 이후의 구성 변경과 이전에 존재했던 권한을 구분할 수 있게 해야 합니다.

국가 표준 노력은 이러한 미해결 질문의 중요성을 강화합니다. 9월 NIST의 에이전트 신원 프로젝트는 이해관계자 피드백 이후 소프트웨어 개발을 첫 번째 구현 사용 사례로 설명했습니다. 이 작업은 신원 및 권한 부여를 평가하기 위한 더 넓은 맥락을 제공합니다. 이는 Shufti의 제품을 인증하거나 상업적 접근 방식의 효과성을 확정하지는 않습니다.

구매자에게 시사점은 간단합니다. 이 출시를 검증 가능한 주장을 담은 구체적 제품 제안으로 다루어야 합니다. 의도한 배포와 관련된 경계에 대한 증거를 요구해야 합니다. 신뢰할 수 있는 에이전트에 관한 포괄적 보장은 허용되는 작업, 거부 조건, 사고 재구성에 관한 구체적 답변으로 대체되어야 합니다.

통합 증거, 독립 테스트, 권한 이식성을 지켜보세요

다음으로 유용한 신호는 이 제안이 출시 자료를 넘어 어떻게 작동하는지 보여 주어야 합니다. 앞으로 몇 달 동안은 통합 증거, 독립 테스트, 권한 이식성을 그 순서대로 주목할 가치가 있습니다. 권한 이식성이란 서로 다른 서비스 전반에서 이해 가능한 권한 경계를 보존하는 것을 뜻합니다. 각 신호는 발표된 접근 방식의 서로 다른 부분을 검증합니다.

진전은 발표된 기능의 수가 아니라 에이전트 작업에 대한 관측 가능한 통제로 판단해야 합니다.

첫째, 수신 애플리케이션이 위임 범위를 어떻게 강제하는지 설명하는 문서화된 배포 사례를 살펴보세요. 유용한 설명은 허용된 작업, 금지된 전환, 그리고 에이전트가 그 경계를 넘을 때의 대응을 명시해야 합니다. 운영 세부사항 없는 고객 이름은 그보다 적은 것을 입증합니다. 구체적인 통합 증거는 실질적 도입의 근거를 강화할 것입니다.

그러한 증거에는 성공적인 거래뿐 아니라 예외 상황도 포함되어야 합니다. 취소, 검증 실패 또는 소유자 부재 시 무엇이 일어나는지 설명할 때 배포 사례는 더 많은 정보를 제공합니다. 이런 상황은 압박 속에서도 워크플로가 권한 모델을 보존하는지 드러냅니다. 성공적인 완료에만 한정된 설명은 이 질문들에 답하지 못합니다.

둘째, 완전한 권한 부여 흐름에 대한 독립 테스트를 지켜보세요. 가장 유용한 결과는 사칭, 탈취된 자격 증명, 변경된 거래 세부사항 및 취소된 권한을 검토할 것입니다. 테스트에는 시스템이 잘못 중단시키는 정당한 활동도 포함되어야 합니다. 두 범주에 걸친 증거가 있다면 효과성을 더 쉽게 평가할 수 있습니다.

독립 테스트는 현실적인 애플리케이션 경계 전반에서 통제가 유지됨을 보여 줄 경우 신뢰를 강화할 것입니다. 범위가 좁은 시연은 그에 상응해 제한적인 결론만 뒷받침합니다. 결과는 무엇을 테스트했으며 무엇이 범위 밖에 남았는지 명시해야 합니다. 구매자는 신원 확인에 관한 증거를 모든 후속 거래에 대한 뒷받침되지 않은 주장으로 확대해서는 안 됩니다.

셋째, Shufti와 다른 신원 제공업체가 조직 경계를 넘어 권한을 어떻게 처리하는지 살펴보세요. 소유자의 권한 부여는 수신 기업이 해석할 수 있는 의미를 가져야 합니다. 각 통합에 서로 무관한 정의가 필요하다면 도입을 유지하기가 더 어려워집니다. 권한 간 명확한 매핑은 더 일관된 강제를 뒷받침할 것입니다.

이식성에도 한계가 필요합니다. 판매자가 수락한 권한이 무관한 기업 시스템에 대한 권한으로 조용히 바뀌어서는 안 됩니다. 상호운용성은 신원과 함께 제한도 보존할 때 가치가 있습니다. 인계 과정 전반에서 권한이 제한된 상태로 유지된다는 증거는 발표의 핵심 제안을 강화할 것입니다.

Shufti Know Your Agent는 구매자가 평가할 수 있는 구체적 제안을 제공합니다. 에이전트, 그 소유자, 그리고 허용된 작업을 연결하는 것입니다. 다음 판단은 이 연결이 실제 워크플로에서도 유지되는지입니다. 조직이 실제로 위임하는 작업을 사용한 시연을 요청하세요. 여기에는 권한을 초과하는 요청과 실행 중 취소가 포함되어야 합니다. 애플리케이션이 무엇을 차단하는지, 사람이 무엇을 보는지, 이후 기록이 무엇을 설명하는지 살펴보세요. 평가를 작성과 전송, 또는 조사와 구매처럼 구체적인 비즈니스 경계에 연결해 두세요. 에이전트 접근을 확대하기 전에 팀은 그 경계가 정확히 어디에서 강제되는지 식별하고, 작업이 바뀌어도 그것이 유지됨을 보여 줄 수 있습니까?