Cursor hooks 보안 제휴, AI 에이전트 설치 권한의 검문소
Cursor와 Endor Labs가 hooks 기반 보안 제휴를 공식화했습니다. 패키지 설치, MCP, 명령 실행을 IDE agent loop 안에서 차단합니다.
- 무슨 일: Endor Labs와 Cursor가 2026년 5월 28일 agentic coding 보안 제휴를 공식화했습니다.
- 초점은 모델 답변 검열이 아니라
Cursor hooks가 tool call, dependency install, commit 전 지점에서 정책을 집행하는 구조입니다.
- 초점은 모델 답변 검열이 아니라
- 차단 지점: 악성 패키지, 승인되지 않은 MCP 서버, 위험 명령을 IDE agent loop 안에서 막는다는 설명입니다.
- 주의점: hook 정책은 필요조건일 뿐이며, CI 권한, secret scope, 설정 파일 review를 함께 묶어야 합니다.
- CSA는 AI coding agent가 untrusted input, shell, repository write 권한을 함께 가질 때 prompt injection to RCE 위험이 커진다고 경고했습니다.
Endor Labs가 2026년 5월 28일 Cursor와의 agentic coding 보안 파트너십을 공식화했습니다. 발표 문장은 "Cursor를 쓰는 엔지니어링 팀이 더 많은 코드를 ship한다"로 시작하지만, 실제 뉴스의 중심은 생산성보다 통제 지점입니다. Endor Labs는 Cursor hooks를 통해 agent가 tool call을 실행하기 전, dependency를 설치하기 전, code를 commit하기 전 정책을 적용한다고 설명합니다.
이번 발표가 눈에 띄는 이유는 보안 수단을 LLM 판단에만 맡기지 않는다는 점입니다. Endor Labs는 hooks를 "deterministic policy enforcement"라고 부릅니다. 모델이 위험하다고 추론하면 막는 방식이 아니라, 조직 정책에 걸리면 차단하는 방식입니다. 악성 패키지를 가져오거나, 승인되지 않은 MCP 서버를 쓰거나, 안전하지 않은 명령을 실행하려는 행동은 agent의 설명 품질과 무관하게 막힙니다.

Cursor 쪽에서도 이 구조는 갑자기 나온 기능이 아닙니다. Cursor는 2025년 12월 hooks partner 글에서 hooks가 agent loop의 정해진 단계 전후로 실행되며, 조직이 agent behavior를 observe, block, modify할 수 있다고 설명했습니다. 같은 글은 hooks 파트너를 MCP governance, code security, dependency security, agent safety, secrets management로 나눴습니다. Endor Labs는 dependency security 항목에서 package installation을 가로채 typosquatting과 dependency confusion을 막는 파트너로 소개됐습니다.
왜 보안은 agent loop 안으로 들어가나
AI 코딩 도구는 더 이상 autocomplete만 하지 않습니다. Cursor Agents, Claude Code, OpenAI Codex, Gemini CLI 같은 도구는 repository를 읽고, shell command를 실행하고, package를 설치하고, test를 돌리고, diff를 만든 뒤 PR이나 commit 단위로 작업을 마칩니다. 이 과정에서 보안 도구가 PR 끝에서만 scan하면 늦습니다. 악성 package lifecycle script는 install 순간 실행될 수 있고, secret은 commit 전에도 노출될 수 있으며, MCP server는 tool call 응답으로 모델 context에 민감 정보를 섞을 수 있습니다.
Endor Labs 발표는 이 시간 순서를 정면으로 다룹니다. 회사는 Cursor hooks가 "before a tool call executes, a dependency is installed, or code is committed" 위치에 선다고 설명했습니다. 이 세 지점은 agentic coding에서 권한이 실제 행동으로 바뀌는 순간입니다. tool call은 외부 시스템 접근으로 이어지고, dependency install은 supply chain risk를 workstation으로 들이며, commit은 생성된 코드가 팀의 review pipeline으로 넘어가는 경계입니다.
기존 application security 도구는 주로 PR, CI, release 단계에서 작동했습니다. 그 방식은 사람이 코드를 쓰고 보안팀이 뒤에서 검사하던 workflow에는 맞았습니다. 하지만 agent가 package를 설치하고 바로 test failure를 고치며 여러 파일을 수정하는 session에서는 feedback이 늦을수록 비용이 커집니다. Endor Labs는 "대부분의 보안 이슈가 coding session이 끝난 뒤가 아니라 editor 안에서 잡히고 고쳐진다"고 주장합니다. 이 문장의 실무적 의미는 scanner가 IDE에 들어간다는 것보다, agent의 다음 행동을 막거나 바꾸는 권한이 IDE에 생긴다는 데 있습니다.
Cursor가 말한 hooks의 범위
Cursor의 2025년 12월 공식 글은 hooks를 단일 vendor integration이 아니라 partner ecosystem으로 제시했습니다. MintMCP는 MCP server inventory와 tool usage monitoring을, Oasis Security는 least-privilege policy와 audit trail을, Runlayer는 MCP broker 기반 중앙 통제를 맡는 식입니다. Code security 영역에서는 Corridor와 Semgrep이 agent가 코드를 쓰는 중 실시간 feedback을 주고, agent safety 영역에서는 Snyk가 prompt injection과 dangerous tool call을 감지한다고 설명했습니다. Secrets management에는 1Password가 shell command 실행 전 환경 파일 mount 상태를 검증하는 사례가 들어갑니다.
이 목록은 Cursor가 hooks를 "agent를 더 똑똑하게 만드는 plugin"보다 "agent에게 허용되는 행동을 조직 정책으로 좁히는 interface"로 보고 있음을 보여줍니다. 개발자가 agent에게 "이 library로 기능을 붙여줘"라고 지시해도, agent가 실제로 npm install을 실행하는 순간은 별도 정책 지점입니다. 개발자가 MCP server를 추가해도, 그 server가 어떤 tool을 호출하고 어떤 응답을 모델에 돌려주는지는 별도 audit 대상입니다. 사람이 의도한 개발 요청과 agent가 수행하는 시스템 행동 사이에 보안 계층이 들어갑니다.
Endor Labs가 이번 발표에서 강조한 세부 항목도 이 구분과 맞닿아 있습니다. AURI는 agent activity visibility, policy-as-code enforcement, secure code generation guidance, vulnerable and malicious dependency 차단을 제공한다고 설명됩니다. Cursor Security의 Travis McPeak는 이전 도구가 표시한 vulnerability 중 97% 초과가 실제 application에서 reachable하지 않았고, AURI가 영향 있는 vulnerability를 보게 했다고 말했습니다. 이 수치는 agent 보안에서도 noise reduction이 중요한 이유를 보여줍니다. agent에게 너무 많은 경고를 던지면 사람도 agent도 우선순위를 잃습니다.
LLM guardrail과 deterministic hook은 다른 문제다
AI 보안 논의는 자주 prompt injection과 refusal policy로 좁아집니다. 물론 모델이 악성 지시를 따르지 않는 것은 필요합니다. 하지만 coding agent의 위험은 모델 출력보다 실행 환경에서 커집니다. agent가 dependency를 설치하면 package manager가 script를 실행하고, agent가 shell을 호출하면 host credential이 노출될 수 있으며, agent가 MCP server를 쓰면 내부 API와 repository 정보가 tool response로 이동할 수 있습니다.
Endor Labs가 "policy enforcement isn't a probability"라고 말한 부분은 이 차이를 겨냥합니다. LLM guardrail은 확률적입니다. 모델이 위험을 인식하지 못하거나, 공격자가 prompt를 우회하거나, context가 길어져 지시 우선순위가 흐려질 수 있습니다. 반면 hook은 특정 event를 보고 allow/block 결정을 내립니다. package install 이벤트, beforeMCPExecution 이벤트, shell command 실행 전 이벤트처럼 구조화된 지점에서 정책을 평가하면 모델의 언어적 판단과 분리됩니다.
그렇다고 hooks가 모든 위험을 없애지는 않습니다. hook이 보는 것은 등록된 event와 연결된 정보입니다. 정책이 없는 행동은 통과할 수 있고, agent가 생성한 code의 논리적 취약점은 별도 SAST나 review가 필요합니다. 또 hooks 자체의 설정 파일, 정책 repository, MCP allowlist가 공격자에게 바뀌면 방어선이 무력화됩니다. 그래서 hook은 "AI 보안의 끝"이 아니라 "agent 행동을 조직 정책에 연결하는 실행 지점"으로 봐야 합니다.
| 지점 | agent 행동 | 대표 위험 | hook 정책의 역할 |
|---|---|---|---|
| Tool call 전 | MCP server, internal API, shell tool 호출 | 승인되지 않은 tool 사용, 민감 데이터 노출 | server allowlist, command denylist, audit log 생성 |
| Dependency install 전 | npm, pnpm, pip, cargo package 설치 | typosquatting, dependency confusion, malicious lifecycle script | package reputation, CVE, malicious package DB 기반 차단 |
| Commit 전 | agent-generated diff를 저장소 이력으로 이동 | hardcoded secret, 취약 pattern, 규정 위반 코드 | secrets detection, SAST, policy-as-code gate |
CSA 경고가 이 발표의 배경을 만든다
CSA의 2026년 4월 연구 노트는 AI coding tool을 CI/CD와 함께 볼 때 위험이 어떻게 커지는지 설명합니다. 보고서는 agent가 repository file을 읽고 command를 실행하며 outbound network request를 만들 수 있으면, 공격자가 control하는 content가 agent behavior에 영향을 주는 순간 credential 접근 경로가 생긴다고 정리합니다. 특히 issue title, PR body, comment처럼 외부 사용자가 쓸 수 있는 입력을 agent가 처리하면서 shell access와 repository write 권한을 같이 갖는 구성이 위험합니다.
보고서는 이 패턴을 prompt injection to RCE로 부릅니다. injection은 입구이고, 실제 목표는 실행 환경입니다. GitHub Actions runner나 개발자 workstation에는 repository write token, cloud credential, container registry credential, package signing key, deployment key가 있을 수 있습니다. AI coding agent가 그 환경 안에서 동작하면 "모델이 속았다"는 문제가 "runner 권한으로 명령이 실행됐다"는 문제로 바뀝니다.
같은 연구 노트는 slopsquatting도 별도 위험으로 다룹니다. AI code generation tool이 존재하지 않는 package name을 추천하고, 공격자가 그 이름을 registry에 미리 등록하면 agent가 악성 package를 설치할 수 있다는 시나리오입니다. 보고서는 특정 조건에서 AI code generation tool이 추천한 package 중 약 20%가 fictitious였고, hallucinated package name의 58%가 여러 실행에서 반복됐다는 연구를 인용합니다. 이 수치는 model output의 오류가 package registry 공격면과 만날 때 어떻게 예측 가능한 target이 되는지 보여줍니다.
Cursor hooks와 Endor Labs package firewall은 바로 이 구간을 겨냥합니다. agent가 package name을 만들어냈는지, 사람이 package를 요청했는지와 무관하게 install event가 발생하면 package reputation과 vulnerability intelligence를 검사할 수 있습니다. 개발자가 눈으로 package 이름을 검토하지 않는 cloud agent session에서는 이런 install 전 검사가 더 중요해집니다.
AURI가 Cursor 밖까지 보려는 이유
Endor Labs의 AURI for Developers 페이지는 이번 발표보다 넓은 제품 방향을 보여줍니다. AURI Developer Edition은 MCP server와 CLI를 통해 SAST, SCA, secrets detection, malicious open source package detection을 제공한다고 설명합니다. 문서에는 Cursor, VS Code, Windsurf, Claude Code, MCP-compatible client가 지원 대상으로 나오고, GitHub Copilot과 OpenAI Codex 같은 asynchronous AI tools도 agent-driven workflow에서 연동된다고 되어 있습니다.
이 범위는 보안 업체가 특정 IDE plugin 하나를 파는 문제가 아님을 보여줍니다. 기업 개발 조직은 Cursor만 쓰지 않습니다. 일부 팀은 Copilot을 쓰고, 일부는 Claude Code를 쓰며, platform team은 CI agent나 자체 MCP server를 붙입니다. 보안팀 입장에서는 editor별 설정 화면보다 policy, evidence, audit trail이 일관돼야 합니다. Endor Labs가 AURI를 "security harness for agentic coding"이라고 부르는 이유도 여기에 있습니다.
제품 페이지는 MCP server가 AURI의 security intelligence를 AI coding assistant에 연결하고, code가 local machine을 떠나지 않는다고 설명합니다. 이 주장은 regulated industry에서 중요합니다. agent 보안을 하겠다며 source code 전체를 외부 scanner로 보내면 privacy와 compliance 검토가 다시 생깁니다. local scan과 read-only vulnerability database 조회를 결합하면 도입 문턱이 낮아질 수 있습니다. 다만 local 실행은 host credential과 network policy를 더 중요하게 만듭니다. scanner도 agent와 같은 workspace 안에서 움직이기 때문입니다.
경쟁은 scanner가 아니라 control plane이다
Cursor hooks partner 목록을 보면 경쟁 구도가 선명합니다. Semgrep은 generated code vulnerability feedback을, Snyk는 dangerous tool call과 prompt injection 감지를 다룹니다. 1Password는 shell command 실행 전 secret mount 검증을 맡고, Oasis Security와 Runlayer는 MCP와 enterprise access control에 붙습니다. Endor Labs는 dependency install과 supply chain 쪽에 강점을 둡니다. 이들은 모두 "agent가 쓴 코드를 나중에 scan한다"보다 "agent가 행동하는 중간에 끼어든다"는 방향을 향합니다.
이 변화는 security tooling의 판매 단위도 바꿉니다. 예전에는 repository scanner, CI scanner, SCA dashboard가 중심이었습니다. agentic coding 환경에서는 IDE, local agent runtime, cloud workspace, CI runner, MCP broker가 연결됩니다. 보안 제품은 어느 지점에서 block할 수 있는지, block evidence를 어디에 남기는지, 사람 승인 workflow와 어떻게 이어지는지를 설명해야 합니다. Cursor hooks는 그 block point 중 하나입니다.
Cursor 입장에서도 보안 파트너십은 enterprise adoption의 조건입니다. Endor Labs 발표에서 Cursor의 Brian McCarthy는 enterprise engineering/security leader가 agentic coding 채택 여부보다 scale과 trust를 묻는다고 말했습니다. 은행, 보험, healthcare 같은 regulated industry는 생산성보다 audit-ready evidence와 policy enforcement를 먼저 요구합니다. 개발자가 빠르게 코드를 만들 수 있다는 사실만으로는 budget과 security approval을 통과하기 어렵습니다.
개발팀이 지금 확인할 체크리스트
첫째, agent가 package를 설치할 수 있는 모든 위치를 inventory해야 합니다. Cursor desktop, cloud agent, Claude Code session, Codex task, Gemini CLI, CI workflow가 각각 어떤 package manager를 실행할 수 있는지 봐야 합니다. package install은 단순 dependency update가 아니라 lifecycle script 실행, native binary 다운로드, postinstall network access로 이어질 수 있습니다.
둘째, MCP server allowlist를 별도 정책으로 관리해야 합니다. MCP는 agent에게 내부 시스템 접근을 주는 편리한 표준이지만, tool response가 모델 context에 들어가는 경로이기도 합니다. 승인된 MCP server, 허용 tool, 민감 데이터 redaction, audit log retention을 정하지 않으면 editor별 plugin 설치가 곧 data boundary 변경이 됩니다.
셋째, hooks와 rules file을 executable configuration으로 다뤄야 합니다. CSA 연구 노트는 .cursor/ configuration, MCP server definition, rules file 같은 AI coding assistant 설정을 review와 integrity verification 대상으로 보라고 권합니다. 공격자가 agent policy 파일을 바꾸면 agent의 다음 행동이 달라집니다. 이 파일들은 README나 formatter 설정이 아니라 deployment script에 가까운 권한을 갖습니다.
넷째, CI에서 agent를 돌릴 때는 세 질문을 먼저 던져야 합니다. agent가 untrusted user input을 읽는가. secret, cloud credential, package signing key에 접근하는가. shell command 실행이나 repository write 권한이 있는가. 세 질문에 모두 "예"라면 도구 이름과 무관하게 high-risk configuration입니다. 이때는 short-lived credential, 최소 repository permission, egress 제한, artifact review, privileged workflow 분리가 필요합니다.
남은 질문
이번 Cursor-Endor Labs 발표는 방향은 분명하지만, 공개 정보만으로는 몇 가지를 확인하기 어렵습니다. enterprise policy가 organization, repository, workspace, user group 중 어느 단위까지 내려가는지는 세부 문서가 더 필요합니다. block된 agent action의 evidence format, cloud agent와 local desktop agent의 hook coverage, private registry 환경의 malicious package database 동기화 방식도 아직 확인해야 합니다.
또 하나의 질문은 developer experience입니다. 보안 정책이 너무 거칠면 agent가 매번 멈추고, 개발자는 예외 요청을 반복합니다. 너무 느슨하면 hooks는 audit log만 남기고 실제 사고를 막지 못합니다. Cursor와 Endor Labs가 성공하려면 "위험하면 막는다"보다 "왜 막혔고, 어떤 안전한 대안으로 고칠 수 있는가"를 agent workflow 안에서 자연스럽게 제공해야 합니다. agent가 package를 설치하지 못했다면 승인된 package, pinned version, internal registry mirror, patch option을 같이 제시해야 합니다.
그래도 이번 발표가 보여주는 방향은 명확합니다. AI 코딩 보안은 모델의 윤리 문구나 PR 끝의 scanner만으로 닫히지 않습니다. agent가 실제 행동으로 넘어가는 지점, 즉 tool call, dependency install, commit, MCP execution, shell command 앞에 정책이 필요합니다. Cursor hooks와 Endor Labs의 제휴는 그 정책 지점이 IDE와 agent runtime 안으로 들어오고 있음을 보여주는 사례입니다.