AI 에이전트/워크플로우가 실제 운영에 붙는 순간부터 보안 사고는 ‘기술 이슈’가 아니라 그로스 지표를 직접 때립니다. 한 번의 침해는 브랜드 신뢰 하락→세일즈 사이클 연장→전환율 하락으로 CAC를 올리고, 보안 심사 재개·도입 중단·계약 축소로 D30과 churn을 동시에 악화시킵니다. 이제 “안전하면 좋고”가 아니라 “안전하지 않으면 성장 못 한다” 국면입니다.
이 전환을 가장 잔혹하게 보여준 사례가 geeknews가 요약한 ‘GitHub 이슈 제목 프롬프트 인젝션→4,000대 개발자 머신 감염’ 사건입니다. 공격은 코드 베이스가 아니라 자연어 입력(이슈 제목)에서 시작했고, AI 이슈 트리아지 봇(Cline 워크플로우)이 그 텍스트를 사실상 실행 지시로 받아들이면서 공급망을 관통했습니다. 결과적으로 npm 토큰이 탈취되고, postinstall 한 줄로 또 다른 에이전트(OpenClaw)가 무단 설치되는 “AI가 AI를 설치”하는 재귀적 신뢰 붕괴가 발생했죠.
핵심은 취약점이 ‘프롬프트’가 아니라 ‘권한 결합’이라는 점입니다. 누구나 이슈를 열어 워크플로우를 트리거할 수 있었고, LLM이 Bash/파일 접근 같은 강한 툴 권한을 가진 채 CI 캐시·릴리스 토큰과 맞물렸습니다. 기존 통제(npm audit, 코드리뷰, provenance)가 못 막은 이유도 여기 있습니다. 바이너리는 동일하고 설정 한 줄만 바뀌었으며, “정상 패키지의 정상 기능(postinstall)”로 위장되면 시그니처 기반 방어는 무력화됩니다. 성장팀 관점에서는 이걸 “예외적 해킹”이 아니라, 온보딩 자동화·지원 자동화·릴리스 자동화에 에이전트가 들어갈수록 반복될 구조적 실패 모드로 봐야 합니다.
그럼 대응은 어디에 두어야 할까요? dev.to의 AgentShield 글이 힌트를 줍니다. 에이전트가 내보내는 출력(할인 약속, 컴플라이언스 위반, 데이터 유출, 드리프트)을 실시간으로 감시하고 차단하는 “에이전트 앞단 프록시/가드” 접근입니다. 개발 워크플로우로 확장하면, 프롬프트 인젝션을 완벽히 정제하려는 시도보다 실행 직전의 정책 평가(allow/deny) + 이벤트 로깅이 훨씬 ROI가 큽니다. 한마디로 “에이전트를 믿지 말고, 에이전트의 행동을 감시”하는 쪽이 스케일합니다.
지금 바로 적용 가능한 ‘성장 방어 체크리스트’는 다음처럼 정리됩니다. (1) 비신뢰 입력의 실행 경로 차단: issues, 외부 폼, 이메일 등 외부 입력이 CI/에이전트를 트리거하면 기본적으로 격리. (2) 툴 권한 최소화: Bash/Write 권한은 기본 OFF, 승인된 작업 단위로만 ON. (3) 비밀(토큰)과 캐시의 결별: 릴리스/배포 워크플로에서 캐시 사용을 재검토하고, 토큰은 단기·범위 최소화. (4) OIDC 기반 provenance로 “토큰 탈취=배포” 연결고리 끊기(geeknews 사례의 사후 조치가 여기로 수렴). (5) postinstall/preinstall 스크립트 가시화/차단: org 정책으로 ignore-scripts 또는 설치 단계 샌드박싱. (6) 실시간 모니터링 레이어: 에이전트의 syscalls/툴 호출/네트워크 egress/비밀 접근을 이벤트로 남기고, high-risk 패턴을 차단.
여기서 그로스 실험으로 연결해야 합니다. 보안은 “완벽”이 아니라 “사고 확률×사고 비용”을 줄이는 최적화 문제니까요. 추천 실험 설계는 2개입니다. 실험 A(전환 방어): 엔터프라이즈 POC 구간에 ‘에이전트 감사 로그/실시간 가드’ 화면을 노출한 그룹 vs 미노출 그룹으로 보안 설문 통과율, 보안 Q&A 소요시간, POC→유료 전환율을 비교합니다(CAC의 간접 절감). 실험 B(리텐션 방어): 위험 이벤트(비밀 접근, 외부 도메인 호출, 정책 위반 응답) 발생 시 차단+리뷰 플로우를 적용한 그룹에서 incident rate, 재발률, churn(또는 좌절 티켓)을 추적합니다. “리스크 이벤트/1,000세션”을 새로운 North Star 보조지표로 두면, 성능/편의 개선과 동일한 리듬으로 보안도 최적화할 수 있습니다.
전망은 명확합니다. 에이전트가 더 많은 컨텍스트(코드, 파일, 고객 데이터)와 더 강한 실행 권한(터미널, 배포, 결제)을 얻을수록, 공격은 프롬프트 인젝션→공급망→권한 위임(Confused Deputy) 형태로 반복될 겁니다. 동시에 시장은 ‘기능 좋은 에이전트’보다 감사추적·정책집행·실시간 모니터링이 내장된 에이전트를 더 빨리 채택할 겁니다. 결국 에이전트 보안은 보안팀만의 과제가 아니라, CAC를 방어하고 LTV를 지키는 제품/그로스의 핵심 레버로 자리 잡습니다.