Endor AURI, 코딩 에이전트에 보안 관제탑을 붙였다

AI 요약

• 무슨 일: Endor Labs가 AURI에 Agent Governance와 Package Firewall을 추가했습니다.
  • Agent Governance는 private preview, Package Firewall은 AURI 플랫폼 일부로 즉시 제공된다고 발표됐습니다.
• 의미: 보안의 초점이 AI가 만든 코드 검사에서 AI가 실행하는 개발 환경 통제로 옮겨갑니다.
  • 프롬프트, 명령, 파일 접근, 도구 사용, 패키지 설치가 모두 감사와 정책 적용의 대상이 됩니다.
• 실무 영향: 코딩 에이전트를 도입한 팀은 IDE 확장보다 hook, MCP, registry proxy, CI 정책을 함께 봐야 합니다.
• 주의점: 공개 문서의 Package Firewall 예시는 아직 JFrog Artifactory 기반 npm, pip 흐름이 중심입니다.

Endor Labs가 AURI 플랫폼을 한 단계 넓혔습니다. 2026년 5월 12일 발표된 새 기능은 두 가지입니다. 하나는 코딩 에이전트가 실제로 무엇을 하는지 관찰하고 정책을 적용하는 Agent Governance입니다. 다른 하나는 개발자나 에이전트가 외부 패키지를 설치하기 전에 악성 패키지를 막는 Package Firewall입니다.

처음 들으면 애플리케이션 보안 제품의 평범한 라인업 확장처럼 보일 수 있습니다. 하지만 이번 발표에서 흥미로운 지점은 기능 이름보다 경계의 이동입니다. 지금까지 AI 코딩 보안의 중심 질문은 대체로 "AI가 작성한 코드가 안전한가"였습니다. 이번 발표는 질문을 바꿉니다. "코드를 작성하는 에이전트는 어떤 권한으로 무엇을 실행하고 있으며, 그 실행 환경은 통제되고 있는가"입니다.

이 변화는 작지 않습니다. 코딩 에이전트는 더 이상 자동완성 도구가 아닙니다. 셸 명령을 실행하고, 패키지를 설치하고, 파일을 읽고 쓰며, MCP 서버와 외부 도구를 연결합니다. 클라우드 에이전트라면 개발자 워크스테이션을 넘어 CI, 임시 실행 환경, 원격 브랜치, 이슈 트래커까지 닿습니다. 이런 상황에서 보안은 pull request 마지막에 붙는 스캐너만으로 끝나기 어렵습니다. 에이전트가 코드를 생산하는 과정 자체가 새로운 운영면이 됐기 때문입니다.

AURI의 출발점은 코드 보안이었습니다

AURI는 2026년 3월 Endor Labs가 공개한 AI 네이티브 애플리케이션 보안 플랫폼입니다. 당시 발표의 핵심 문장은 분명했습니다. 코딩 에이전트는 코드를 쓸 수 있지만 전체 애플리케이션 컨텍스트는 충분히 보지 못한다는 것입니다. 애플리케이션은 단일 파일이 아니라 서비스, 함수, 의존성, 컨테이너, 데이터 흐름, 변경 이력의 집합입니다. 보안 리뷰도 결국 이 관계망을 이해해야 의미가 있습니다.

Endor Labs는 이를 위해 코드 컨텍스트 그래프라는 개념을 앞세웠습니다. 공식 AURI 페이지는 이 그래프가 first-party code, open-source dependencies, container images, data flow를 연결하고, 취약점의 reachable 여부와 exploitability를 판단하는 기반이라고 설명합니다. 전통적인 SAST나 SCA가 많은 alert를 만들지만 실제 코드 경로에서 호출되지 않는 취약점까지 똑같이 올려 문제를 만든다는 비판도 이 맥락입니다.

3월 발표는 그래서 "코딩 에이전트에게 보안 컨텍스트를 공급한다"에 가까웠습니다. MCP, Skills, CLI 같은 연결 방식으로 에이전트와 개발자 도구 안에 보안 지능을 넣고, 에이전트가 만든 코드나 의존성 변경을 더 빨리 점검하게 하겠다는 방향이었습니다. 이번 5월 발표는 그 다음 단계입니다. 이제 Endor Labs는 에이전트가 만든 결과물뿐 아니라 에이전트의 행동 자체를 보안 대상으로 삼겠다고 말합니다.

Agent Governance는 에이전트 행동의 장부입니다

Agent Governance가 겨냥하는 문제는 visibility입니다. 코딩 에이전트를 조직적으로 쓰기 시작하면 보안팀과 플랫폼팀은 단순한 질문에도 답하기 어려워집니다. 누가 어떤 에이전트를 쓰는지, 어떤 모델을 붙였는지, 어떤 MCP 서버를 연결했는지, 어떤 명령이 실행됐는지, 어떤 파일을 읽었는지, 어떤 패키지를 설치했는지 한눈에 보이지 않습니다.

Endor Labs의 발표문은 Agent Governance가 AI activity를 developer workstation과 cloud environment 전반에서 기록하는 system of record 역할을 한다고 설명합니다. 정책 적용 범위도 코드 결과물에 국한되지 않습니다. 프롬프트, 명령, 파일 접근, 도구 사용 같은 에이전트 행동이 실시간 탐지와 차단 대상입니다.

흥미로운 점은 통합 지점입니다. 발표문은 Cursor, Claude Code, Gemini CLI 같은 코딩 에이전트의 hook 시스템에 직접 통합된다고 말합니다. 이것이 사실상 핵심입니다. 에이전트 보안을 별도 게이트웨이로만 두면 개발자 경험과 충돌하기 쉽습니다. 반대로 에이전트가 이미 제공하는 hook, policy, permission 지점에 붙으면 개발 흐름 안에서 정책을 적용할 수 있습니다.

이 모델은 기존 보안 제품 분류로 딱 떨어지지 않습니다. EDR처럼 워크스테이션 행동을 봅니다. DLP처럼 파일 접근과 외부 전송을 의식합니다. CI 보안처럼 자동화된 실행 경로를 통제합니다. 하지만 트리거는 사람이 직접 누른 명령만이 아니라 모델이 계획하고 에이전트가 실행한 작업입니다. 그래서 Agent Governance라는 이름이 붙은 듯합니다. 제품명보다 중요한 것은 "에이전트 행동 로그"가 앞으로 엔터프라이즈 AI 개발의 기본 인프라가 될 가능성입니다.

Package Firewall은 공급망 공격의 타이밍을 앞당깁니다

Package Firewall은 더 구체적입니다. 개발자나 AI 에이전트가 패키지를 설치할 때, 요청이 public registry에 닿기 전에 악성 패키지를 검사하고 막습니다. 발표문은 npm, PyPI, NuGet, Maven 등 주요 생태계를 언급합니다. 현재 공개 문서의 설정 예시는 JFrog Artifactory를 앞단 registry proxy로 두고 npm과 pip 요청을 Package Firewall로 라우팅하는 흐름이 중심입니다.

공식 문서의 작동 방식은 간단합니다. Artifactory가 패키지 요청을 Endor Labs Package Firewall로 전달합니다. Package Firewall은 ecosystem, package name, version을 파싱하고 Endor Labs의 malware database와 대조합니다. 악성으로 판단되면 요청을 차단하고 클라이언트에는 404 계열 실패가 보입니다. 정상 패키지라면 307 redirect를 통해 upstream registry에서 다운로드가 이어집니다.

이 방식이 중요한 이유는 설치 시점이 공격자에게도 가장 좋은 타이밍이기 때문입니다. supply chain 공격은 코드 리뷰 단계보다 앞서 개발자 환경에 들어올 수 있습니다. 특히 코딩 에이전트는 문제 해결 과정에서 새 패키지를 제안하거나 설치할 수 있습니다. 사람이라면 낯선 패키지 이름을 한 번 더 살필 수도 있지만, 에이전트가 긴 작업을 수행하는 동안 패키지 설치는 부수 효과처럼 지나갈 수 있습니다.

Package Firewall은 이 경계를 registry 앞단으로 끌어옵니다. 나중에 SBOM을 보고 "이미 들어온 악성 패키지"를 찾는 것이 아니라, 설치 요청 자체를 정책 지점으로 삼습니다. 에이전트가 자동으로 실행하는 npm install이나 pip install도 결국 네트워크 요청이고, 그 요청은 통제할 수 있다는 접근입니다.

코딩 에이전트 보안은 권한 모델의 문제입니다

이번 발표를 제품 소식으로만 읽으면 놓치는 부분이 있습니다. 코딩 에이전트 보안은 모델 성능 문제가 아니라 권한 모델의 문제이기도 합니다. 에이전트가 더 똑똑해질수록 위험이 줄어드는 면도 있지만, 동시에 더 많은 일을 위임받기 때문에 실패의 반경은 커집니다.

예를 들어 에이전트가 테스트를 고치기 위해 새 패키지를 설치한다고 합시다. 이 행동은 개발자 생산성 관점에서는 자연스럽습니다. 하지만 보안 관점에서는 외부 코드가 워크스테이션이나 CI에 들어오는 순간입니다. 패키지가 정상이어도 라이선스, 유지보수 상태, 취약점, transitive dependency가 문제가 될 수 있습니다. 패키지가 악성이라면 설치 스크립트가 비밀 값을 훔치거나 원격 코드를 실행할 수 있습니다. 에이전트가 이 과정을 자동화하면 속도는 올라가지만 승인과 감시의 빈틈도 같이 커집니다.

Agent Governance는 이 문제를 "누가 무엇을 실행했는가"라는 감사 가능성으로 다룹니다. Package Firewall은 "무엇이 환경에 들어왔는가"라는 공급망 경계로 다룹니다. 두 기능이 함께 발표된 이유도 여기에 있습니다. 하나는 행동의 로그와 정책이고, 다른 하나는 의존성 유입 지점의 차단입니다.

이 조합은 코딩 에이전트 운영의 현실적인 최소 단위를 보여줍니다. 첫째, 에이전트가 쓰는 도구와 권한을 알아야 합니다. 둘째, 에이전트의 행동을 기록해야 합니다. 셋째, 위험한 행동을 실행 중에 막을 수 있어야 합니다. 넷째, 외부 패키지 유입은 별도 정책 지점으로 다뤄야 합니다. 이 네 가지가 없으면 에이전트 도입은 생산성 실험으로는 가능해도 조직 표준 운영으로 가기는 어렵습니다.

공식 문서가 말하는 제약도 중요합니다

Package Firewall 문서를 보면 기대와 제약이 같이 보입니다. 문서는 악성 패키지를 차단할 때 404 응답을 돌려 설치가 실패하게 만든다고 설명합니다. 정상 패키지는 307 redirect로 public registry 다운로드를 이어갑니다. 이 설계는 개발자 도구와 CI가 이미 이해하는 실패 형태를 활용한다는 장점이 있습니다. 별도 클라이언트를 강제하기보다 registry 경로에 들어가는 방식입니다.

다만 공개 문서 기준으로는 JFrog Artifactory 설정이 전제입니다. npm과 PyPI 예시가 가장 구체적이며, Package Firewall API key에는 SYSTEM_ROLE_PACKAGE_FIREWALL role이 필요합니다. 또한 문서는 이미 Artifactory에 캐시된 패키지가 나중에 악성으로 판정되면 캐시 만료 전까지 계속 제공될 수 있다고 설명합니다. 이 부분은 실무적으로 중요합니다. registry proxy를 둔다고 모든 위험이 즉시 사라지는 것은 아닙니다. 캐시 TTL, upstream routing, 로그 조회 권한, 예외 정책까지 운영 설계가 필요합니다.

Agent Governance도 private preview입니다. 즉, 발표문이 제시하는 방향은 분명하지만 실제 조직에서 어떤 에이전트와 어떤 hook 범위를 얼마나 안정적으로 커버하는지는 도입 단계에서 검증해야 합니다. Cursor, Claude Code, Gemini CLI 등 에이전트별 hook 모델은 서로 다릅니다. MCP 서버 호출, shell command, file access, network access, browser automation까지 모두 같은 방식으로 통제된다고 가정하면 안 됩니다.

그래서 이 발표는 "이 제품을 켜면 끝"이라는 메시지보다 "코딩 에이전트 보안 아키텍처가 어디로 가는가"라는 신호로 읽는 편이 낫습니다. 통제 지점은 IDE 확장 하나가 아니라 hook, MCP, CLI, registry, CI, cloud runtime으로 흩어집니다. 보안팀은 스캐너 목록보다 에이전트 실행 경로 지도를 먼저 그려야 합니다.

공급망 공격은 에이전트 시대에 더 날카로워집니다

Endor Labs는 발표문에서 오픈소스 malware advisory 증가와 npm maintainer account takeover 문제를 함께 언급했습니다. 이 수치는 업체 발표문에 포함된 자체 맥락이므로 그대로 과장해 받아쓰기보다 방향성을 보는 것이 좋습니다. 그래도 큰 흐름은 분명합니다. 공격자는 패키지 생태계를 오래전부터 노려 왔고, AI 코딩 에이전트는 패키지 선택과 설치를 더 빠르게 만들고 있습니다.

에이전트 시대의 공급망 공격은 두 가지 면에서 더 까다롭습니다. 첫째, 설치 결정이 사람의 명시적 선택이 아니라 에이전트의 중간 계획으로 들어갈 수 있습니다. 둘째, 에이전트가 가진 권한이 개발자의 권한과 거의 같거나 더 넓을 수 있습니다. 개발자의 로컬 토큰, repo write 권한, cloud credential, CI secret에 접근 가능한 환경에서 악성 패키지가 실행되면 피해는 코드베이스를 넘어섭니다.

이 때문에 Package Firewall 같은 설치 시점 방어는 단순한 SCA 보완재가 아닙니다. 코딩 에이전트가 외부 코드를 끌어오는 행동을 통제하는 런타임 정책에 가깝습니다. 물론 이것만으로 충분하지는 않습니다. lockfile review, provenance, package signing, sandboxed execution, least privilege, secret isolation이 같이 필요합니다. 하지만 설치 요청 자체를 보안 이벤트로 본다는 관점은 앞으로 더 중요해질 가능성이 큽니다.

개발팀이 지금 확인할 것들

코딩 에이전트를 이미 쓰고 있다면 이번 발표에서 바로 가져갈 질문이 있습니다. 우리 팀의 에이전트는 어떤 명령을 자동으로 실행할 수 있습니까. 파일 읽기와 쓰기 범위는 어디까지입니까. 네트워크 접근은 제한돼 있습니까. 새 패키지 설치는 사람 승인 없이 가능한가요. MCP 서버는 누가 등록하고 검토합니까. 에이전트가 남긴 로그는 보안 사고 조사에 쓸 만큼 충분합니까.

이 질문들은 특정 벤더를 쓰느냐와 무관합니다. Codex, Claude Code, Cursor, Gemini CLI, OpenHands, 사내 에이전트 모두 같은 문제를 만납니다. 생산성을 높이기 위해 에이전트에게 넓은 권한을 주고 싶지만, 넓은 권한은 감사와 정책 없이는 운영 리스크가 됩니다. 특히 기업 환경에서는 "개발자가 편하게 쓰는 도구"가 곧 "조직의 코드 생산 인프라"가 됩니다.

Endor Labs의 AURI 확장은 이 지점을 정확히 겨냥합니다. 에이전트를 막자는 이야기가 아닙니다. 에이전트를 엔터프라이즈 개발 인프라로 받아들이려면, 그 인프라에 맞는 로그, 정책, 차단 지점, 공급망 방어가 필요하다는 이야기입니다.

경쟁은 보안 도구 사이가 아니라 control plane 사이에서 벌어집니다

최근 AI 개발 도구 시장을 보면 코딩 에이전트 자체보다 그 에이전트를 운영하는 control plane이 중요해지고 있습니다. UiPath는 코딩 에이전트를 엔터프라이즈 자동화와 오케스트레이션의 일부로 보려 합니다. Coder는 self-hosted 환경에서 에이전트 실행을 통제하려 합니다. Cloudflare는 agent infrastructure를 런타임 관점에서 다룹니다. Endor Labs는 여기에 보안 지능과 정책 집행을 붙이는 쪽입니다.

이 경쟁은 "어떤 모델이 코드를 더 잘 쓰는가"와 다른 층위입니다. 기업은 이미 여러 모델과 여러 에이전트를 동시에 씁니다. 모델은 바뀌고, 에디터도 바뀌고, 에이전트 런타임도 바뀝니다. 오래 남는 것은 권한, 감사, 정책, 네트워크, 패키지 경계입니다. 그래서 에이전트 control plane 위에 security layer를 붙이려는 제품들이 늘어나는 것은 자연스럽습니다.

다만 시장이 아직 정리된 것은 아닙니다. 에이전트 hook 표준은 성숙하지 않았고, MCP는 빠르게 확산되지만 보안 운영 모델은 각 조직이 직접 설계해야 하는 부분이 많습니다. registry 방화벽도 package manager, private registry, cache, mirror, CI 환경마다 연결 방식이 달라집니다. 따라서 지금 필요한 것은 단일 제품 선택보다 에이전트 실행 경로와 보안 경계를 명확히 그리는 일입니다.

이번 발표의 핵심 신호

Endor Labs의 이번 발표는 AURI라는 제품의 기능 추가이면서 동시에 AI 개발 환경의 다음 보안 경계를 보여줍니다. AI가 만든 코드를 검사하는 것은 계속 필요합니다. 하지만 그것만으로는 부족합니다. 코딩 에이전트는 코드를 작성하는 동안 이미 많은 시스템 행위를 수행합니다. 그 행위가 보안팀의 관찰 범위 밖에 있으면, 조직은 생산성 향상과 함께 새로운 blind spot도 받아들이게 됩니다.

Agent Governance는 그 blind spot을 로그와 정책으로 좁히려는 시도입니다. Package Firewall은 외부 패키지 유입이라는 오래된 공급망 경계를 에이전트 시대에 맞춰 앞당기려는 시도입니다. 둘 다 완성된 표준이라기보다는 시장이 어디에 비용을 쓰기 시작했는지 보여주는 신호에 가깝습니다.

개발팀 입장에서는 이번 발표를 구매 검토 자료로만 볼 필요는 없습니다. 더 중요한 질문은 내부 운영 체크리스트입니다. 에이전트가 실행하는 명령과 설치하는 패키지를 보안 이벤트로 보고 있는가. MCP와 hook 설정을 검토 대상으로 관리하고 있는가. 에이전트 로그가 사고 조사에 충분한가. 패키지 설치 경로에 차단 지점이 있는가. 이 질문에 답하지 못한다면, 코딩 에이전트 도입은 아직 실험 단계에 머물러 있을 가능성이 큽니다.

AI 코딩의 다음 국면은 더 똑똑한 모델만으로 설명되지 않습니다. 더 많은 권한을 가진 에이전트를 어떻게 운영하고, 감시하고, 제한할지의 문제입니다. Endor Labs가 AURI에 붙인 두 기능은 바로 그 방향을 가리킵니다. 코딩 에이전트가 개발 속도를 올리는 만큼, 개발 환경 자체도 생산 인프라처럼 다뤄져야 합니다.

출처

• Endor Labs Expands AURI from Securing Code to Securing Agents that Produce Code
• AURI AI-Native Application Security Platform
• Endor Labs Package Firewall Documentation
• Introducing AURI: Security Intelligence for AI Coding Agents and Developers
• The agent control plane needs a security layer