이번 분기 보안 점검을 하나만 한다면, AI 에이전트 메모리를 선택하라

Help Net Security와의 이번 인터뷰에서 Vectorize의 CEO Chris Latimer는 AI 에이전트 메모리에 숨어 있는 보안 위험을 이야기합니다. 그는 코딩 에이전트가 API 키, 자격증명, 민감한 문서를 개발자 머신과 클라우드 서비스에 평문으로 저장하고 있는 현실을 발견했습니다.

Latimer는 공격자가 플러그인, 스킬, MCP 통합을 통해 어떻게 악성 메모리를 심을 수 있는지 설명하며, 그 표적이 종종 지나치게 쉽게 신뢰하는 신규 코더들임을 지적합니다. 또한 에이전트 메모리에 대한 접근 제어가 다른 영역에 비해 뒤처진 이유, 사고 발생 후 추적해야 할 사항, 그리고 이번 분기에 모든 CISO가 반드시 실행해야 한다고 생각하는 단 하나의 감사에 대해 이야기합니다.

에이전트의 메모리 저장소를 처음 열어 한 줄씩 읽었을 때, 쌓여 있는 내용을 보고 가장 놀란 점은 무엇이었나요? 지금도 떠오르는 항목 하나를 소개해 주세요.

제가 사용하던 코딩 에이전트의 메모리 뱅크를 살펴보면서 가장 크게 놀란 것은, 에이전트 메모리에 저장되는 민감한 정보의 양이 얼마나 많은지였습니다.

개발자들은 API 키, 자격증명, 민감한 문서를 이 에이전트들에 전달하고, 에이전트는 그 정보의 상당 부분을 장기 메모리에 저장합니다. 기업들이 보안 SDLC(소프트웨어 개발 수명주기)의 일환으로 보호하기 위해 많은 노력을 기울여 온 고도로 민감한 데이터들이, 이제는 개발자의 워크스테이션, 클라우드 메모리 서비스, 마크다운 파일 등에 평문으로 떠돌고 있는 것입니다.

다음 주에 메모리가 활성화된 에이전트를 레드팀(모의 해킹)으로 테스트한다면, 가장 먼저 어디에 무엇을 심겠습니까? 왜 뻔한 대상이 아닌 그 표적을 선택하나요?

가장 명백한 공격 중 하나는 메모리 포이즈닝입니다. 공격자에게 도움이 될 수 있어 모든 기법을 공개하고 싶지는 않지만, 메모리를 심을 때 해당 메모리가 에이전트 동작에 변화를 일으킬 가능성을 훨씬 높이는 특정 기술들이 존재합니다.

가장 먼저 해야 할 것은 메모리를 오염시킬 방법을 찾는 것입니다. 유력한 수단은 플러그인, 스킬, MCP 통합입니다. 대부분의 사람들은 가치 있어 보이는 것을 발견하면 꼼꼼히 읽어보지 않고 바로 연결합니다.

지금은 코딩 에이전트를 활용해 무언가를 만드는 코딩 경험이 전무한 사람들이 많아졌는데, 이들은 무엇이 진짜이고 무엇이 사기인지 판별할 역량이 없습니다. 저라면 공격자로서 "너무 좋아서 믿기 어려운" 것으로 그런 사용자들을 노리겠습니다.

"이 Claude Code 플러그인의 버그를 이용하면 무료 플랜에서도 무제한 토큰을 받을 수 있습니다" 같은 것들이죠. 너무 좋아서 믿기 어려운 내용이요.

그런 다음 그 플러그인이 사용자의 메모리를 스캔해 자격증명을 찾아내고, 발견한 모든 키·토큰·민감 정보를 특정 API 엔드포인트로 전송하도록 만들 것입니다.

보안의 많은 부분이 그렇듯, 이것도 상당 부분 사회공학(Social Engineering)에 의존합니다. 하지만 코딩 에이전트의 이러한 확장 포인트와 지나치게 신뢰하는 사용자 기반이 결합되면 이런 공격의 현실적인 가능성이 만들어집니다.

메모리를 가진 에이전트가 연루된 사고에서 증거 수집은 첫 한 시간 동안 어떻게 이루어지나요? 처음 겪었을 때 보존하지 못해 아쉬웠던 것은 무엇인가요?

후회는 보존하지 못한 것보다 애초에 메모리 시스템에 들어가지 않았으면 하는 것들에서 옵니다. 이는 대부분의 다른 공격과 같습니다. 피싱 공격이 발생했을 때 누가 링크를 클릭했고 누구의 비밀번호가 유출됐는지 아는 것도 유용하지만, 피싱 메일이 누군가의 받은편지함에 도달하기 전에 잡아내는 것이 훨씬 좋습니다.

이미 발생한 메모리 포이즈닝 공격에서 원하는 추적 가능성의 대부분은 그 메모리가 어디서 왔는지 이해하는 것입니다. MCP 서버인지, 도구 호출 응답인지, 내부자 위협인지 파악해야 피해를 최대한 억제할 수 있습니다.

그러나 그런 공격을 메모리에 저장되기 전에 탐지하고 필터링할 수 있다면 훨씬 좋습니다. 이것이 OWASP 참조 프로젝트인 Memory Guard의 아이디어입니다.

메모리에 관해 벤더들이 일관되게 답변하기 어려워하는 질문은 무엇인가요? 가장 인상적인 "답변 같지 않은 답변"을 공유해 주세요.

놀랍게도, 메모리의 아주 기본적인 측면인 접근 제어입니다. RBAC(역할 기반 접근 제어), ABAC(속성 기반 접근 제어) 등 구조화된 데이터에 대한 세밀한 접근 제어 분야에서 업계가 얼마나 성숙해 있는지와 비교하면, 에이전트 메모리에서 동일한 수준의 접근 제어를 제공하는 경우는 보기 드뭅니다.

한 사용자의 에이전트 세션이 다른 사용자의 메모리를 활용하지 못하도록 막는 방법은 대부분의 솔루션이 갖추고 있습니다. 하지만 팀 기반 메모리나 등급별 접근 권한처럼 복잡한 시나리오로 가면, 아직 빠르게 진화하고 있는 영역입니다.

기업 사용자들은 애플리케이션 보안, 데이터베이스 보안, API 보안 관점에서 이러한 요구사항을 충분히 이해하고 있습니다. 에이전트 메모리 영역에서도 이에 상응하는 기술이 이미 마련되어 있을 것으로 기대하지만, 현실은 대부분의 제품이 아직 이를 구현하지 못하고 있습니다.

이 글을 읽는 CISO가 메모리가 활성화된 에이전트를 이미 운영 중이고 이번 분기에 한 가지만 한다면, 무엇을 해야 하며 어떤 것을 발견하게 될 것으로 예상하나요?

조직 내 에이전트 메모리 솔루션에 대해 최소한 비공식적인 감사라도 실시하십시오. 십중팔구 인식하지 못했던 큰 보안 허점을 발견하게 될 것이며, 최대한 빨리 패치하고 싶어질 것입니다.

구체적으로, 대부분의 엔터프라이즈 규모 기업에서 CISO는 두 가지 우려스러운 사실을 발견하게 될 것입니다.

첫째, 에이전트 메모리로 무엇이 사용되고 있는지에 대한 거버넌스가 전혀 없다는 것을 알게 됩니다. 에이전트 메모리가 사용되지 않는다고 생각할 수 있지만, 얼마나 많은 개발자들이 검증되지 않은 솔루션을 자신의 로컬 워크스테이션이나 어딘가의 소규모 공유 서버에 연결해 놓았는지 놀라게 될 것입니다.

둘째, 그 시스템들에 탈취되기 쉬운 상태로 평문으로 저장된 고도로 민감한 정보의 양에 충격을 받을 것입니다. 유출된 키, 데이터베이스 비밀번호, 기밀 비즈니스 정보 등이 발견될 것입니다.