Clawvisor, AI 에이전트 권한을 OAuth 밖에서 다시 설계하다

무슨 일이 (The News)

Clawvisor는 AI 에이전트가 이메일·드라이브·슬랙·코드 저장소 같은 업무 도구를 쓸 때 권한을 작업 단위로 좁혀 집행하려는 YC 스타트업이다. 회사 프로필은 2026년 창업, 팀 규모 1명, 분야를 AI 에이전트용 권한 레이어로 제시한다.[1]

문제의 출발점은 OAuth 동의 화면이 사람과 전통적 앱을 기준으로 설계됐다는 데 있다. 사용자는 “메일 읽기”를 승인하지만, 에이전트는 같은 권한으로 오늘 온 메일 분류도, 전체 받은편지함 복사도 시도할 수 있다.[2]

Clawvisor의 구조는 에이전트와 데이터 사이의 프록시다. 에이전트가 작업을 선언하고 사용자가 한 번 승인하면, 이후 요청마다 그 작업 목적과 맞는지 검사한다. 자격 증명 볼트(credential vault)는 토큰과 API 키를 에이전트 밖에 보관한다.[3]

이 뉴스가 작은 오픈소스 도구 이상의 의미를 갖는 이유는 에이전트 인프라 경쟁의 축이 바뀌고 있기 때문이다. 챗봇 단계에서는 모델 답변 품질이 전부처럼 보였지만, 업무 에이전트 단계에서는 권한·승인·감사 추적 기록(audit trail)이 제품 구매의 전제조건이 된다.[4]

기존 SaaS 권한 체계는 대체로 “앱이 사용자 대신 무엇을 할 수 있는가”를 묻는다. 에이전트 환경에서는 질문이 더 좁아진다. “이 사용자가 방금 승인한 이 작업을 위해, 이 API 호출이 지금 필요한가”를 매번 확인해야 한다.

그 차이는 사소해 보이지만 사고 시나리오를 완전히 바꾼다. 캘린더 조회, 문서 검색, 메일 발송은 각각 안전한 기능일 수 있다. 세 기능이 한 에이전트 계획 안에서 연결되면 고객 정보 수집과 외부 전송이라는 고위험 흐름이 된다.

Clawvisor가 겨냥하는 틈은 바로 이 연결부다. 모델이 똑똑해질수록 한 번의 사용자 지시가 여러 도구 호출로 분해된다. 권한 계층은 개별 호출이 아니라 전체 작업 맥락을 따라가야 한다.

그래서 이 발표는 모델 회사 뉴스가 아니라 제어면(control plane) 뉴스다. 에이전트가 실제 업무 시스템에 들어가려면 모델, 도구, 권한, 로그, 승인 UI가 함께 움직여야 한다. Clawvisor는 그중 권한과 승인 계층을 먼저 제품화하려는 시도다.

숫자로 보기

가장 중요한 숫자는 14개 서비스 어댑터와 249개 평가 케이스다. Clawvisor는 제품 페이지에서 “14개 서비스 어댑터”를 내세우고, README는 의도 검증(intent verification)·체인 컨텍스트 추출·작업 위험 평가 평가셋이 총 249개 케이스라고 명시한다.[3][4]

이번 건은 모델 출시가 아니어서 한국어 프롬프트 토큰 수나 벤치마크를 직접 비교할 수 없다. 실측은 하지 못했다. Clawvisor 인스턴스와 실제 Google Workspace·Slack·GitHub 자격 증명이 있어야 요청 지연시간, 오탐 차단률, 승인 피로도를 측정할 수 있기 때문이다.

한국 독자에게 가장 중요한 지표는 “허용해야 할 작업을 통과시키면서 위험한 요청을 얼마나 빨리 막는가”다. 평가셋은 한국어 업무 지시 100건, 민감 데이터 요청 50건, 정상 자동화 50건으로 나누고 허용·차단 정확도와 p95 지연시간을 같이 봐야 한다. 오늘 할 수 있는 결정은 도입이 아니라 이 평가 기준을 먼저 고정하는 것이다.

가격 정보는 공개 자료에서 확인되지 않는다. 대신 운영 규모의 단서는 있다. YC 프로필은 팀 규모를 1명으로 표시하고, Launch YC 글은 창업자 Eric Levine의 이전 회사 Berbix가 2023년 Socure에 7,000만 달러에 인수됐다고 설명한다.[1][2]

오픈소스 저장소의 초기 신호도 제한적으로 읽을 수 있다. GitHub API 접근 시점 기준 clawvisor/clawvisor 저장소는 199개 스타, 24개 포크, 8개 열린 이슈를 갖고 있었다.[5] 이 숫자는 성숙도를 증명하지 않지만, 적어도 에이전트 권한 문제가 개발자 커뮤니티의 실험 주제로 떠올랐다는 신호다.

타임라인 관점에서는 기본 승인 제한 시간이 중요하다. README 설정 표는 일반 승인 기본값을 300초, MCP 승인 기본값을 240초로 제시한다.[4] 이 값은 보안 정책이라기보다 사용성 가정이다. 승인 창이 너무 길면 공격 표면이 넓어지고, 너무 짧으면 사용자가 승인 피로를 느낀다.

규모를 읽을 때 조심할 점도 있다. 14개 어댑터는 넓은 생태계 호환성을 암시하지만, 각 어댑터가 기업별 정책과 데이터 분류 체계를 얼마나 깊게 반영하는지는 별도 검증 대상이다. 연결 가능한 서비스 수와 안전한 서비스 수는 다르다.

249개 평가 케이스도 같은 방식으로 봐야 한다. 숫자가 있다는 점은 긍정적이지만, 한국어 업무 지시, 국내 기업 약어, 조직별 결재 표현이 포함됐는지는 확인되지 않았다. 한국 도입팀은 자체 평가셋을 더해 언어와 업무 문맥 차이를 검증해야 한다.

2차 효과는 비용보다 책임 소재에서 먼저 나타난다. 에이전트가 잘못된 메일을 보내거나 파일을 공유했을 때, 기업은 모델 제공사만 탓할 수 없다. 누가 승인했고, 어떤 정책이 통과시켰고, 어떤 로그가 남았는지가 내부 감사의 핵심 기록이 된다.

따라서 Clawvisor류 계층의 진짜 지표는 스타 수가 아니라 차단 사유의 설명 가능성이다. 보안팀이 “왜 막혔는가”와 “왜 통과했는가”를 사람 언어로 검토할 수 있어야 한다. 단순 403 응답만 남는 게이트웨이는 에이전트 운영 지식으로 축적되기 어렵다.

누가 말했나

공개 발언의 공통점은 “에이전트 권한은 설치 시점 동의가 아니라 실행 시점 통제 문제”라는 진단이다. Clawvisor 쪽 발언은 과장된 성능 약속보다 OAuth 스코프의 구조적 한계를 설명하는 데 집중한다.

“OAuth scopes are too coarse for nondeterministic agents. "Read access" means both "triage recently received emails" and "exfiltrate an archive of the whole inbox".”

“OAuth 스코프는 비결정적인 에이전트에게 너무 거칩니다. ‘읽기 권한’은 ‘최근 받은 이메일 분류’와 ‘전체 받은편지함 아카이브 유출’을 동시에 뜻합니다.”

이 문장의 핵심은 “권한 이름”과 “작업 목적”을 분리해 봐야 한다는 점이다. 같은 읽기 권한이라도 최근 영수증 5개를 찾는 일과 전체 메일함을 내보내는 일은 위험도가 다르다. 한국 기업의 개인정보 처리 맥락에서는 이 차이가 법무·보안·현업 승인선을 가르는 기준이 된다.

이 비판은 OAuth가 실패한 기술이라는 뜻이 아니다. OAuth는 사용자가 특정 앱에 접근권을 위임하는 표준으로 널리 쓰인다. 문제는 에이전트가 그 앱처럼 고정된 기능만 수행하지 않는다는 데 있다.

에이전트는 사용자의 자연어 지시를 해석하고, 필요한 도구를 고르고, 중간 결과에 따라 다음 호출을 바꾼다. 그 변동성이 커질수록 토큰 발급 시점의 동의만으로는 실제 행동의 위험을 설명하기 어렵다.

“AI agents are not traditional applications. OAuth authorizes access at token-issuance time, but agents need authorization at action-execution time, on every API call, against a semantic policy the user controls.”

“AI 에이전트는 전통적 애플리케이션이 아닙니다. OAuth는 토큰 발급 시점에 접근을 승인하지만, 에이전트에는 사용자가 통제하는 의미 기반 정책에 따라 모든 API 호출의 실행 시점 승인 체계가 필요합니다.”

여기서 의미 기반 정책은 단순한 엔드포인트 허용 목록보다 어렵다. “고객 A에게 회의록을 보내라”는 작업은 캘린더 조회, 문서 읽기, 메일 발송을 모두 포함할 수 있다. 따라서 정책은 API 이름이 아니라 사용자 목적, 데이터 범위, 수신자, 시간 제한을 함께 봐야 한다.

한국어 업무 환경에서는 이 난도가 더 높아진다. “지난번 건 정리해서 팀에 돌려줘” 같은 지시는 구체적 데이터 범위가 생략돼 있다. 사람 동료라면 맥락을 묻거나 조직 관행을 따른다. 에이전트는 이 생략을 정책으로 해석해야 한다.

그래서 권한 계층은 모델 밖에 있어야 한다는 주장이 힘을 얻는다. 모델에게 “조심해”라고 지시하는 것만으로는 충분하지 않다. 에이전트가 잘못 판단해도 자격 증명과 외부 전송 권한은 별도 계층에서 막아야 한다.

“Clawvisor is experimental software under active development. It has not been audited for security.”

“Clawvisor는 활발히 개발 중인 실험적 소프트웨어이며, 보안 감사를 받은 상태가 아닙니다.”

가장 중요한 안전 문구는 제품이 아니라 README에 있다. 이 문장은 구매자에게도, 개발자에게도 같은 메시지를 준다. 지금 Clawvisor를 평가한다면 “보안 제품을 샀다”가 아니라 “에이전트 권한 설계 패턴을 검증한다”로 범위를 좁혀야 한다.

독립 분석가의 신선한 반응은 이번 조사 범위에서 확인되지 않았다. 그래서 이 글은 과장된 찬반 구도로 만들지 않는다. 확인된 발언만 놓고 보면, 창업자는 OAuth 한계를 비판하고, 프로젝트 문서는 아직 보안 감사를 받지 않았다고 스스로 선을 긋는다.

이 균형은 오히려 제품을 더 현실적으로 보게 한다. 에이전트 보안 도구가 완성됐다고 선언하기보다, 어떤 실패 모드를 줄이려는지 명확히 밝히는 편이 낫다. 한국 기업도 같은 기준으로 벤더를 평가해야 한다.

한국 시장 관점

한국 기업에는 Clawvisor 자체보다 “에이전트가 어떤 업무 시스템을 어느 목적까지 만질 수 있는가”를 문서화하는 방식이 더 중요하다. 학생이나 개인 개발자에게는 편의 기능처럼 보이지만, 스타트업·대기업·공공기관에는 개인정보, 내부통제, 전자금융, 감사 대응의 문제로 바뀐다.

국내 SaaS 팀이 먼저 볼 지점은 Google Workspace, Slack, GitHub, Notion 같은 외부 업무 도구와 사내 API 사이의 경계다. 에이전트가 캘린더를 읽고 메일을 보내며 저장소 이슈를 수정하려면, OAuth 동의 화면 하나로는 충분하지 않다. 작업명, 데이터 범위, 수신자, 만료 시간, 재승인 조건이 별도 정책으로 남아야 한다.

대기업과 SI 관점에서는 Clawvisor가 완제품이라기보다 설계 참조에 가깝다. Naver HyperCLOVA, Kakao Kanana, SKT A.X, LG EXAONE, Upstage Solar 같은 국내 모델·플랫폼은 한국어 성능과 기업 배포 채널을 놓고 경쟁한다. 하지만 모델이 국내산인지 여부와 별개로, 에이전트가 업무 시스템을 호출하는 순간 권한 계층은 별도 문제가 된다.

국내 보안 기업과 클라우드 운영사는 여기서 기회를 볼 수 있다. 에이전트용 CASB, API 게이트웨이, 비밀 관리, 감사 로그, DLP가 한 제품군으로 묶일 수 있기 때문이다. 특히 금융·공공 고객은 “모델이 잘 답했다”보다 “누가 어떤 근거로 어떤 액션을 승인했는가”를 먼저 요구한다.

한국 named individual의 공개 발언은 확인하지 못했다. 따라서 특정 인물의 평가를 빌리지 않고 시장 구조만 보자. 국내 도입의 첫 구매자는 모델팀이 아니라 보안팀·인프라팀·컴플라이언스 담당자일 가능성이 크다. 이들은 에이전트의 창의성보다 실패 시 복구 가능성, 요청 차단 근거, 로그 보존 기간을 묻는다.

스타트업에는 더 현실적인 함의가 있다. 작은 팀이 AI 에이전트로 CS, 영업, 회계 보조를 자동화하려면 초기에는 편의성 때문에 넓은 권한을 주기 쉽다. Clawvisor류 계층은 그 유혹을 줄이는 장치다. 최소 권한을 코드와 정책으로 남겨야 투자자·고객 보안 심사에서 설명할 수 있다.

한국 시장에서 특히 까다로운 지점은 조직별 결재 문화다. 미국식 SaaS에서는 사용자 개인의 승인과 관리자 정책이 중심이다. 한국 대기업은 팀장, 정보보호, 법무, 시스템 오너가 각기 다른 기준으로 같은 작업을 본다.

예를 들어 영업 에이전트가 고객 미팅 자료를 만들기 위해 CRM, 캘린더, 드라이브를 조회한다고 하자. 현업은 속도를 원하고, 보안팀은 외부 공유를 걱정하며, 법무는 개인정보 처리 근거를 본다. 권한 계층은 이 세 질문을 하나의 승인 화면에 눌러 담아야 한다.

공공기관과 금융사는 더 보수적이다. 망분리, 접근기록, 계정권한 정기점검, 위탁사 관리가 이미 복잡하다. 에이전트가 사람 계정을 대신 쓰면 책임 소재가 흐려지고, 별도 서비스 계정을 쓰면 권한이 과도하게 넓어질 수 있다.

이 때문에 국내 도입은 “에이전트별 권한”보다 “업무별 권한”으로 가야 한다. 고객 응대, 비용 정산, 개발 이슈 정리, 보안 이벤트 분류처럼 반복 업무 단위를 먼저 정하고, 각 업무에 필요한 최소 API 호출만 허용해야 한다.

국내 모델 사업자에게도 메시지가 있다. HyperCLOVA, EXAONE, Solar가 한국어 추론을 잘해도 기업 고객의 마지막 질문은 “우리 데이터에 무엇을 할 수 있나”다. 모델 성능표만으로는 이 질문에 답할 수 없다.

따라서 한국형 에이전트 플랫폼은 모델 라우팅, RAG, 도구 호출 SDK만으로 끝나지 않는다. 목적 기반 권한 부여, 자격 증명 볼트, 감사 추적 기록, 승인 UX가 한 묶음으로 제공돼야 한다. 이 묶음이 없으면 PoC는 쉬워도 운영 전환에서 멈춘다.

중소기업에는 부담도 있다. 보안 전담 인력이 없는 팀은 정책을 세밀하게 만들 시간이 부족하다. 그래서 기본 템플릿, 위험 등급, 자동 로그 요약, 관리자 알림이 제품 경쟁력이 된다. 개발자 도구가 아니라 운영 도구로 설계해야 한국 시장에서 쓰인다.

반대 의견 (Room for Disagreement)

가장 강한 반론은 “작업 단위 권한 부여가 실제 업무의 애매함을 충분히 이해하지 못하면 보안도, 생산성도 모두 놓칠 수 있다”는 것이다. 에이전트의 요청은 자연어 목적, 도구 호출, 중간 추론, 외부 API 응답이 얽히기 때문에 정책 엔진이 항상 명확한 판단을 내린다고 가정하면 위험하다.

현재까지 본 발표를 공개적으로 반박한 named individual을 확인하지 못함. 남는 위험은 오탐과 미탐이다. 오탐이 많으면 사용자는 승인 피로를 느껴 정책을 느슨하게 바꾸고, 미탐이 있으면 민감 데이터가 정상 작업처럼 빠져나간다. 이를 검증하려면 한국어 업무 지시, 애매한 대명사, 내부 약어, 고객명 마스킹을 포함한 평가셋이 필요하다. 오늘 한국 운영자가 정해야 할 것은 “쓸지 말지”가 아니라 차단 실패를 어느 수준까지 허용할지다.

또 하나의 반론은 중앙 프록시가 새 병목이 된다는 점이다. 모든 요청이 Clawvisor 같은 계층을 지나면 지연시간과 장애 영향이 커진다. 특히 콜센터, 주문 처리, 장애 대응처럼 초 단위 응답이 중요한 업무에서는 승인 단계가 사용자 경험을 해칠 수 있다.

그럼에도 반론이 Clawvisor류 접근 전체를 무너뜨리지는 않는다. 에이전트에게 넓은 OAuth 권한을 준 뒤 사후 로그만 보는 방식은 위험을 너무 늦게 발견한다. 한국 시장에서는 고위험 작업은 실행 전 승인, 저위험 작업은 사후 샘플링, 반복 업무는 시간 제한 정책으로 나누는 혼합형이 더 현실적이다.

더 근본적인 의문은 정책 판단 자체를 누가 신뢰하느냐이다. Clawvisor류 도구가 LLM으로 의도를 판별한다면, 그 LLM도 오류를 낼 수 있다. 규칙 기반으로만 막으면 유연성이 떨어지고, LLM 판단을 섞으면 설명 가능성과 재현성이 어려워진다.

한국 기업은 이 지점에서 이중 장치를 둬야 한다. 첫째, 민감 액션은 LLM 판단만으로 통과시키지 않는다. 둘째, LLM이 낮은 위험으로 분류한 요청도 표본 감사와 사후 재평가 대상에 넣는다. 셋째, 정책 변경은 코드 리뷰처럼 이력과 승인자를 남긴다.

또 다른 위험은 사용자가 보안 문구를 학습해 승인한다는 점이다. 승인 화면이 잦아지면 사람은 내용을 읽지 않고 통과시킨다. 그러면 권한 레이어는 형식적 절차가 된다. 제품은 승인 횟수를 늘리는 것이 아니라 승인할 만한 순간만 골라내야 한다.

무엇이 내 판단을 바꿀까. 한국어 업무 지시에서 높은 차단 정확도와 낮은 지연시간을 동시에 보이는 공개 평가가 나오면 긍정 신호다. 반대로 정상 업무 오탐이 높거나, 차단 사유가 사람이 검토하기 어려운 로그로만 남으면 운영 도입은 늦춰야 한다.

즉시 결정해야 할 것

오늘은 도입이 아니라 에이전트 권한 평가셋과 금지 행동 목록을 정하는 단계다. Clawvisor를 바로 핵심 업무에 붙이면 도구 검증과 보안 검증을 동시에 하게 되어 실패 원인을 분리하기 어렵다.

1. Today (오늘): 에이전트가 접근할 수 있는 시스템을 3단계로 나눈다. 읽기 전용, 제한적 쓰기, 외부 전송으로 구분하고 각 단계마다 반드시 차단할 행동을 10개씩 적는다. 예를 들어 “최근 7일 메일 검색”과 “전체 메일함 내보내기”를 같은 읽기 권한으로 묶지 않는다.

오늘 작업의 산출물은 긴 정책 문서가 아니다. 한 장짜리 표면 충분하다. 시스템명, 허용 작업, 금지 작업, 민감 데이터, 승인자, 만료 시간을 적는다. 이 표가 없으면 어떤 게이트웨이를 붙여도 정책이 흔들린다.

2. This week (이번 주): 더미 계정으로 50개 한국어 업무 지시를 만든다. 정상 작업 30개, 경계 사례 10개, 명백한 유출 시도 10개로 나누고 허용·차단 결과를 표로 기록한다. 목표 지표는 차단해야 할 10개를 모두 막고, 정상 작업 오탐을 3개 이하로 줄이는 것이다.

이번 주 실험에서는 실제 고객 데이터 대신 합성 데이터를 쓴다. 파일명, 고객명, 계약 금액, 이메일 주소를 가짜로 만들되 형식은 현실과 비슷하게 둔다. 그래야 차단 정책이 데모 문장이 아니라 업무 문서에서 작동하는지 볼 수 있다.

3. This month (이번 달): 승인 UX를 별도 실험한다. 승인 제한 시간을 240초와 300초로 나눠 p95 처리시간, 승인 포기율, 재시도율을 측정한다. 보안팀은 로그 필드에 사용자, 작업 목적, 호출 API, 데이터 범위, 승인자, 거절 사유가 모두 남는지 확인한다.

이번 달 말에는 도입 판정을 숫자로 낸다. 차단 실패 0건, 정상 작업 성공률 90% 이상, p95 지연시간 허용 범위, 감사 로그 필수 필드 100% 충족을 기준으로 둔다. 하나라도 빠지면 운영 연결을 미룬다.

4. This quarter (이번 분기): 내부 API 게이트웨이와 비밀 관리 체계를 에이전트용으로 확장할지 결정한다. 외부 오픈소스를 그대로 쓰는 결정이 아니라, 목적 기반 권한 부여(purpose-based authorization)를 사내 표준 패턴으로 채택할지 판단한다. 금융·공공 고객을 상대한다면 이 결정은 기능 로드맵보다 먼저 온다.

분기 단위로는 구매보다 아키텍처 결정이 중요하다. 에이전트별로 자격 증명을 흩뿌리는 구조를 금지하고, 모든 도구 호출이 한 계층을 지나도록 정한다. 예외가 필요하면 만료일과 책임자를 붙인다.

마지막으로 책임자를 정한다. 에이전트 권한은 모델팀 혼자 맡을 일이 아니다. 보안, 인프라, 법무, 현업 오너가 함께 승인 기준을 정해야 한다. 권한 레이어는 기술 도구이지만 실패 비용은 조직 전체에 돌아간다.

출처 (References)

1. Y Combinator — "Clawvisor: The Authorization Layer for AI Agents" (2026-05-24). https://www.ycombinator.com/companies/clawvisor
2. Y Combinator — "Launch YC: Clawvisor — The Authorization Layer for AI Agents" (2026-05-24). https://www.ycombinator.com/launches/QFP-clawvisor-the-authorization-layer-for-ai-agents
3. Clawvisor — "Clawvisor | AI Agent Gatekeeper" (2026-05-24). https://clawvisor.com
4. GitHub — "Clawvisor README" (2026-05-24). https://raw.githubusercontent.com/clawvisor/clawvisor/main/README.md
5. GitHub REST API — "clawvisor/clawvisor repository metadata" (2026-05-24). https://api.github.com/repos/clawvisor/clawvisor