AI 에이전트를 B2B에 실제로 붙여보면, 전환율을 깎는 건 종종 모델의 정답률이 아닙니다. 보안 사고 가능성, 권한 오남용, 운영 거버넌스 부재가 PoC를 묶어두고 세일즈 사이클을 늘립니다. “일단 써보자”가 “감사/컴플라이언스 통과부터”로 바뀌는 순간, 성장은 기능 로드맵이 아니라 신뢰 설계 경쟁이 됩니다.
dev.to의 「Agents Don't Just Do Unauthorized Things…」는 이 병목을 ‘측정 단위’부터 다시 잡자고 제안합니다. 액션 로그가 아니라 state delta(상태 변화량)—에이전트가 연쇄 행동을 통해 “시스템이 영향을 줄 수 있는 범위”를 얼마나 넓혔는지를 봐야 한다는 주장입니다. 여기서 핵심은 capability graph입니다. 리소스/권한을 노드로, 실제로 실행된 접근 경로를 엣지로 두고, “선언된 권한 그래프 vs 실제 행사된 그래프”의 델타를 노출도로 정의합니다.
문제는 엣지가 두 종류라는 점입니다. 직접 엣지(에이전트가 DB를 읽고 API를 호출한 것)는 로깅과 수명(미사용 시 가지치기)이 가능합니다. 반면 induced edge(유도 엣지)—에이전트의 출력이 사람을 설득해 권한을 넓히거나 설정을 바꾸게 만든 경우—는 로그에 잘 안 남고, 한번 생기면 오래 갑니다. 즉, “에이전트는 아무것도 안 했는데 시스템 권한은 확장된” 상태가 생깁니다. 이건 보안 이슈이면서 동시에 제품 성장 이슈입니다. 엔터프라이즈는 이 지점을 발견하는 즉시 구매를 보류하거나, 제한된 파일럿에서 더 이상 확장하지 않습니다.
또 하나의 함정은 임계치 드리프트(threshold drift) 입니다. 배포 시점엔 괜찮았던 허용 범위가 사용이 누적되며 사실상 확장됩니다. 계속 재보정하면 좋아 보이지만, 그 재보정 메커니즘 자체가 공격면이 될 수 있습니다(의도적이든 구조적이든). 그래서 글은 “재보정 권한을 실행 컨텍스트와 분리”하고, 특히 유도 엣지는 기본값을 ‘비가역(irreversible)’로 두고 과잉 리컨실(over-reconcile) 하자고 말합니다. 비용이 들지만, 나중에 자동 분류기를 만들 라벨 데이터를 확보하는 유일한 길이라는 금융 컴플라이언스(13F) 비유가 설득력을 줍니다.
여기에 MCP 생태계 현실이 겹치면, ‘신뢰점수’는 더 이상 선택이 아닙니다. dev.to의 「what if MCP servers had a Lighthouse-style security score?」는 194개 MCP 패키지를 스캔했더니 60.8%에서 보안 이슈가 나왔다고 말합니다. 지금은 npm install 순간에 입력 검증/셸 인젝션/환경변수 노출/의존성 CVE/출력 살균에 대한 신호가 거의 없습니다. 결과적으로 에이전트는 “안전한 툴”과 “호스트를 날릴 툴”을 구분하지 못한 채 실행합니다.
성장 관점에서 정리하면, 우리는 ‘모델 성능→전환’이 아니라 보안(노출도 통제)→신뢰(감사 가능성)→전환/확장 퍼널을 설계해야 합니다. 그래서 필요한 게 에이전트 신뢰점수(Agent Trust Score) 입니다. 저는 이 점수를 두 축으로 쪼개길 권합니다. (1) 행동 노출 점수(Exposure Score): capability graph의 state delta, 직접/유도 엣지의 발생량과 반감기, 중앙 정책 게이트(Write checkpoint) 통과율, 리컨실 주기 준수율. (2) 공급망 보안 점수(Tool/MCP Score): 입력 검증, 실행 안전성, 환경 격리, 의존성 위생, 출력 살균(기사의 Lighthouse식 0-100 점수 제안). 이 두 점수의 곱이 “실제로 운영 가능한 에이전트”의 최소조건이 됩니다.
실행 플랜은 명확합니다. 첫째, 모든 state-changing call을 결정론적 정책 게이트로 모으세요(토큰 모니터링이나 사후 감사보다 먼저). 둘째, capability graph를 이벤트로 남기고 “선언 vs 실제” 델타를 주기적으로 리컨실하세요. 셋째, induced edge는 기본 ‘비가역’ 처리하고 리뷰 큐로 올리되, 리뷰 피로를 리뷰어 일관성 지표로 측정해 자동 스로틀링/로테이션을 거세요(원문이 지적한 fatigue problem). 넷째, MCP/툴은 점수 배지를 UI와 정책에 박아 “일정 점수 미만 로드 금지”로 제품 기본값을 바꾸세요.
전망은 간단합니다. 에이전트 시장이 커질수록, 기능 데모가 아니라 신뢰점수 스펙이 구매 체크리스트가 됩니다. Lighthouse가 웹 성능의 공용어를 만들었듯, capability graph와 MCP 보안 점수는 에이전트 운영의 공용어가 될 가능성이 큽니다. 누가 더 똑똑한 모델을 붙였는지가 아니라, 누가 더 빨리 “보안 신호를 제품화”해서 PoC 전환율과 장기 리텐션을 지키는지가 다음 라운드의 성장 레버입니다.