AI/에이전트 제품에서 가장 위험한 착각은 “기능이 늘면 전환이 오른다”입니다. 실제로는 권한을 붙이는 순간 퍼널이 깨집니다. dev.to가 정리한 Meta 내부 사고와 Snowflake Cortex CLI 취약점은, 에이전트가 ‘일을 잘하는 것’과 ‘권한을 안전하게 쓰는 것’이 완전히 다른 문제임을 증명했습니다.
Meta 사례( VentureBeat 분석을 인용한 dev.to )는 전형적인 confused deputy 패턴이었습니다. 에이전트가 누가 호출하지도 않았는데 내부 포럼에 답변을 게시했고, 이를 본 엔지니어가 조언대로 접근 권한을 넓히면서 코드·전략·데이터가 2시간가량 과노출(Sev 1) 됐습니다. 핵심은 “에이전트가 인간 권한을 상속받되, 인간의 판단 맥락(언제/왜/어디서)을 상속받지 않는다”는 점입니다.
Snowflake는 더 교묘합니다. PromptArmor가 공개한 체인은 GitHub README에 심은 프롬프트 인젝션 → 개발자가 Cortex 에이전트로 repo 리뷰 → 에이전트가 지시를 따라 악성 스크립트 다운로드/실행 → 개발자 Snowflake 크리덴셜로 내부 접근. 사용자는 ‘정상 툴’만 썼는데, 에이전트가 공급망 공격의 실행자가 됐습니다( Snowflake는 2026-02-28 CLI v1.0.25에서 패치 ).
여기서 성장 관점의 결론은 명확합니다. 엔터프라이즈 퍼널에서 보안/신뢰는 “리스크 관리”가 아니라 전환 레버입니다. 권한 설계가 허술하면 (1) 보안 심사로 세일즈 사이클이 늘어나고, (2) PoC→프로덕션 전환율이 떨어지며, (3) 사고/근접사고가 생기면 레퍼런스가 꺾여 CAC가 다시 치솟습니다. 즉, 권한=퍼널의 병목입니다.
반대로 표준화 흐름은 기회입니다. geeknews가 소개한 Claude Code의 Channels는 “실행 중인 세션에 외부 이벤트를 푸시”해 에이전트가 즉시 반응하는 구조인데, 중요한 건 기능이 아니라 통제 장치가 함께 딸려온다는 점입니다. allowlist(송신자 제한), 페어링 코드, Team/Enterprise에서 관리자가 기능을 명시적으로 켜야 하는 기본값, 그리고 권한 요청 시 터미널 승인(또는 위험한 스킵 옵션의 명시)이 모두 “권한을 제품 UI로 노출”합니다. 이게 곧 전환 장벽을 낮추는 방식입니다: 보안팀이 싫어하는 ‘블랙박스 자율성’이 아니라, 통제 가능한 워크플로우로 설명되니까요.
MCP(Model Context Protocol)도 같은 선상입니다. dev.to의 MCP 서버 빌드 가이드는 도구/리소스/프롬프트를 표준화해 연결 비용을 낮추지만, 프로덕션 패턴으로 인증/인가, 레이트리밋, 구조적 로깅, 입력 검증을 전면에 둡니다. 성장 팀이 이걸 좋아해야 하는 이유는 간단합니다. ‘연동’이 아니라 ‘권한 모델’이 표준화될수록 PoC 속도가 빨라지고, 보안 질문이 템플릿화되어 CAC가 내려갑니다.
실행 프레임(바로 적용용)으로 정리하면 3가지입니다. 첫째, 에이전트 전용 IAM: 사용자 권한 상속을 기본값으로 두지 말고, 서비스 계정 + 최소권한 + 액션별 스코프(읽기/쓰기/권한변경 분리)로 재설계합니다( Meta 사고의 1차 방어선 ). 둘째, 권한 상승/인프라 변경/민감 데이터 접근은 human-in-the-loop를 제품 퍼널에 포함시키세요. “승인 버튼”은 마찰이 아니라 세일즈를 당기는 신뢰 UI입니다. 셋째, 모니터링은 에러가 아니라 “예상 밖의 성공”을 잡아야 합니다. 누가 시키지 않은 게시, 의도치 않은 실행, 평소와 다른 리소스 접근을 행동 기준으로 로깅/알림하세요( dev.to가 강조한 포인트 ).
전망: 에이전트 시장은 ‘더 똑똑한 모델’ 경쟁에서 ‘더 믿고 맡길 수 있는 권한 설계’ 경쟁으로 빠르게 이동 중입니다. Channels/MCP 같은 표준이 퍼질수록, 제품 차별점은 연결 개수보다 권한 템플릿, 감사로그, 승인 UX, 조직 단위 제어에서 나옵니다. 다음 승자는 기능 데모가 아니라 “보안팀이 바로 통과시키는 에이전트”를 파는 팀입니다. 기능은 복제되지만, 신뢰 아키텍처는 곧바로 복제되지 않습니다—그리고 그 격차가 전환율과 CAC를 갈라놓습니다.