Anthropic은 2026년 4월 Project Glasswing을 발표하며 AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks 등이 참여하는 중요 소프트웨어 보안 이니셔티브라고 설명했습니다. 세부 기술이 모두 공개된 것은 아니지만, 방향은 분명합니다. AI가 코드를 더 많이 만들고, 에이전트가 더 많은 시스템에 접속하는 시대에는 애플리케이션 코드 한 줄보다 소프트웨어 공급망 전체가 더 큰 공격면이 됩니다.
개발자 입장에서 이 이슈를 “대기업 보안 캠페인” 정도로 넘기면 안 됩니다. 지금 팀에서 쓰는 AI coding assistant, MCP 서버, 사내 도구 토큰, CI/CD secret, 패키지 의존성, 브라우저 자동화 계정이 모두 공급망의 일부입니다. 에이전트는 사람이 귀찮아서 건너뛰던 일을 빠르게 해주지만, 동시에 사람이 실수로 열어둔 권한도 빠르게 사용합니다.
전통적인 공급망 보안은 패키지 의존성, 빌드 파이프라인, 배포 서명, secret 관리에 집중했습니다. AI 에이전트가 들어오면 여기에 새로운 층이 생깁니다. 에이전트는 문서를 읽고, 코드를 수정하고, CLI를 실행하고, 외부 API를 호출하고, 때로는 브라우저를 조작합니다. 즉 개발자의 손과 눈 일부를 대신합니다.
문제는 이 권한이 종종 너무 넓게 주어진다는 점입니다. “개발 편의”를 이유로 repo 전체 write 권한, cloud admin 권한, production secret 접근권을 한 번에 열어주면 에이전트가 실수했을 때 피해 범위가 커집니다. 더 위험한 경우는 프롬프트 인젝션입니다. 에이전트가 외부 문서나 이슈, 웹페이지를 읽는다면 그 안의 악성 지시문을 작업 지시로 오해할 수 있습니다. 공급망 보안은 더 이상 package-lock만 보는 일이 아닙니다. 에이전트가 읽는 정보와 실행하는 도구까지 포함해야 합니다.
AI 에이전트 보안의 첫 단계는 권한을 세 단계로 나누는 것입니다. 읽기 권한은 문서, 코드, 로그, 이슈를 조회하는 권한입니다. 제안 권한은 patch, PR, plan을 생성하지만 직접 반영하지 않는 권한입니다. 쓰기 권한은 실제 파일 수정, 배포, 외부 API 호출, 데이터 변경을 수행하는 권한입니다.
많은 팀이 이 세 단계를 섞습니다. 예를 들어 에이전트에게 “버그 고쳐줘”라고 했는데 동시에 production database credential과 배포 토큰이 열려 있다면, 단순 수정 작업이 운영 사고로 이어질 수 있습니다. 기본값은 읽기와 제안까지 자동화하고, 쓰기는 승인제로 두는 편이 안전합니다. 특히 삭제, 결제, 이메일 발송, 사용자 데이터 변경, 인프라 생성, 권한 변경은 사람 확인을 거쳐야 합니다.
최근 에이전트 환경에서는 MCP 서버나 custom tool을 통해 여러 시스템을 붙입니다. 편리하지만, 이 연결이 공급망의 새 입구가 됩니다. 각 도구에 대해 최소한 네 가지를 확인해야 합니다. 어떤 입력을 받는가, 어떤 외부 시스템에 접근하는가, 어떤 side effect가 있는가, 실패했을 때 재시도되는가입니다.
예를 들어 GitHub tool은 repo 읽기만 하는지, PR 생성까지 하는지, main branch push가 가능한지 구분해야 합니다. Slack tool은 메시지 초안만 만드는지 실제 전송까지 하는지 분리해야 합니다. 브라우저 자동화 tool은 로그인 세션을 공유하는지, 결제나 설정 변경 페이지에 접근 가능한지 제한해야 합니다. 이런 경계가 없으면 에이전트 보안은 프롬프트 문구에만 의존하게 됩니다. 프롬프트는 보안 경계가 아닙니다.
에이전트가 만든 코드 자체보다 package 추가가 더 위험할 수 있습니다. 사람이 직접 개발할 때도 낯선 패키지를 대충 추가하는 경우가 있지만, 에이전트는 더 쉽게 “필요한 라이브러리”를 설치하려고 합니다. 이때 typosquatting, abandoned package, postinstall script, transitive dependency 문제가 생깁니다.
따라서 에이전트가 package.json, requirements.txt, Dockerfile, GitHub Actions, Terraform, Kubernetes manifest를 바꾸는 PR은 자동 고위험으로 분류해야 합니다. 단순 기능 코드와 같은 리뷰 기준으로 보면 안 됩니다. 의존성 변경에는 라이선스, maintenance 상태, 다운로드 수, 최근 릴리스, known vulnerability, install script 여부를 확인하는 절차가 필요합니다.
에이전트가 실행한 작업은 나중에 사람이 설명할 수 있어야 합니다. 어떤 입력을 받았고, 어떤 문서를 읽었고, 어떤 tool call을 했고, 어떤 파일을 바꿨고, 어떤 외부 API에 요청했는지가 남아야 합니다. 단, 민감 정보를 그대로 로그에 남기면 또 다른 문제가 됩니다. 따라서 prompt 전문 저장보다 event 중심 로그가 낫습니다.
예를 들어 agent_id, task_id, tool_name, resource, action, approval_id, result, timestamp 정도를 남기고, 토큰이나 개인정보는 redaction해야 합니다. 이렇게 해야 사고가 났을 때 재현과 책임 추적이 가능합니다. 보안팀이 싫어하는 것은 AI 자체가 아니라 설명 불가능한 자동화입니다.
Project Glasswing이 던지는 메시지는 AI 시대에도 보안 기본기가 중요하다는 말로 끝나지 않습니다. 기본기의 범위가 넓어졌다는 뜻입니다. 이제 공급망 보안은 패키지와 빌드만 보지 않습니다. 에이전트가 읽는 문서, 호출하는 도구, 가진 토큰, 만드는 PR, 실행하는 CLI까지 모두 포함합니다. AI 에이전트를 팀에 넣는다면 생산성 지표와 함께 권한 경계, 승인 흐름, 감사 로그부터 다시 설계해야 합니다.
