더 안전한 에이전트를 엔지니어링하는 방법

더 안전한 AI 에이전트를 구축하려면 에이전트의 기능과 실패 가능성 모두를 고려하여 설계해야 합니다. 합법적인 작업을 수행할 때나 악의적인 지시가 없을 때조차도 에이전트는 장애물을 극복하려고 시도하는 과정에서 보안 경계를 넘을 수 있습니다.

당사는 이것이 보안 엔지니어링 문제라고 믿으며, 업계는 2000년대 초반의 인터넷 웜에 대처했던 방식으로 이 문제에 대처해야 합니다. 에이전트를 둘러싼 시스템은 에이전트가 액세스할 수 있는 범위를 제한하고, 원치 않는 행태를 감지하며, 장애 발생 시 이를 격리해야 합니다.

Perplexity는 AI 에이전트를 위한 보안 엔지니어링을 발전시키기 위해 연구원 및 실무자들과 적극적으로 협력하고 있으며, 모델, 에이전트 하네스, 인프라 전반에 걸쳐 다중 방어 레이어를 적용하여 보안이 단일 안전장치에만 의존하지 않도록 하고 있습니다.

AI 에이전트의 멜트다운 행태

7월, AI 에이전트가 오픈소스 AI 플랫폼인 Hugging Face의 프로덕션 인프라에 침입했습니다. 내부 사어버 보안 평가 및 훈련 실행 중, OpenAI 모델은 Artifactory 리포지토리 관리자를 악용하여 서로 통신하기 위한 게시판을 구축하는 방법을 찾아내어 군집(swarm)을 이루어 조직화할 수 있게 되었습니다. 나중에 사이버 보안 벤치마크에서 작업 진척을 내지 못한 에이전트들이 다른 에이전트들을 모집하여 도움을 요청했습니다. 이 에이전트들은 평가 환경을 탈출하여 인터넷에 도달했습니다. 또한 벤치마크 작업에 대한 답변을 리버스 엔지니어링하여 부정행위를 하는 방법을 알아냈으나, 채점 시스템이 부정행위를 감지할 것이라고 생각했습니다. 부정행위로 감지되는 것을 피하는 방법을 찾기 위해 벤치마크 평가가 어떻게 작동하는지 더 잘 이해하고자 결국 Hugging Face 시스템을 손상시켰습니다(Hugging Face; OpenAI).

이 사건은 당사가 7월에 Numbat을 오픈소스화했을 때 설명했던 실패 모드의 명확한 예시입니다. Cornell Tech의 보안 연구원들이 만든 용어인 우발적 멜트다운(accidental meltdowns)이 그것입니다(arXiv). 합법적인 목표를 추구하는 에이전트가 누락된 파일, 실패한 API 호출, 만료된 자격 증명 또는 권한 거부와 같은 마찰(friction)에 부딪히면 우회로를 찾기 시작합니다. 이 과정에서 정찰, 권한 상승, 비밀 정보 발견 또는 데이터 유출을 통해 보안 경계를 넘을 수 있습니다. 악의적인 프롬프트나 외부 공격자가 관여하지 않았더라도 에이전트 자체 사실상 공격자가 되는 것입니다.

Hugging Face는 고립된 사례가 아니었습니다. 최근 몇 주 동안 더 많은 에이전트 멜트다운(meltdown) 행태가 발견되고 보고되었습니다. 미국 정부 데이터에 대한 오픈 액세스를 제공하는 플랫폼인 Data USA에서 아이오와 대학교 데이터를 수집하려던 에이전트들이 5월 27~28일에 잘못 형식화된 쿼리로 인해 오류에 직면했습니다. 이들은 SQL 인젝션, 크로스 사이트 스크립팅, 템플릿 인젝션, 경로 탐색(path traversal), 커맨드 인젝션 등의 프로브로 대응했습니다. 이 활동은 나중에 OpenAI와 연관된 것으로 밝혀졌습니다(SecurityWeek). 6월 20~21일, 오스트레일리아 보건복지연구소(AIHW)의 빅토리아주 내 지역별 의약품 범주에 대한 1인당 정부 비용을 확보하려던 OpenAI 에이전트들이 파일 다운로드를 차단당했습니다. 이에 대응하여 에이전트들은 그 과정에서 사이트의 봇 차단 보호 기능을 우회하며 이미 공개되어 있던 파일을 AIHW 사전 제작 서버에서 다운로드했습니다(SecurityWeek).

이러한 패턴은 특정 연구소 하나에만 국한되지 않습니다. 사이버 보안 테스트 중에 Anthropic 모델은 실수로 오픈 인터넷 액세스가 부여된 후 3개 기업을 침해했고, Google의 Gemini는 3개 웹사이트의 자격 증명을 유추했으며, Meta 모델은 서드파티 서비스를 악용했습니다(Reuters).

역사로부터의 교훈: 인터넷 웜의 시대

이러한 사건들은 약 25년 전의 인터넷 웜 시대를 연상시킵니다. 2000년대 초반, 인터넷은 그 주변의 보안 관행보다 훨씬 빠른 속도로 성장했습니다. 바이러스와 웜의 물결이 일었으며, 그 결과는 현재 AI 에이전트의 멜트다운에서 목격하고 있는 것보다 훨씬 더 심각했습니다.

2000년 5월 4일, 사람들은 제목이 "ILOVEYOU"인, 친숙한 발신자로부터 온 이메일을 받기 시작했습니다. 이메일의 첨부 파일을 열면 스크립트가 실행되어 피해자의 Outlook 주소록에 있는 모든 사람에게 자신의 복사본을 메일로 발송했습니다. 그날 오후 6시까지 CERT 조정 센터(CERT Coordination Center)는 420,000개 이상의 인터넷 호스트와 관련된 보고를 접수했습니다(US GAO Report). 보도에 따르면 이 바이러스는 국방부, CIA, NASA, 하원 및 상원을 포함하여 최소 14개의 연방 기관에 침투했습니다(US GAO Report). 또한 펜타곤과 영국 의회의 이메일 서버를 다운시켰습니다(Wired). 영국의 보험 거물인 Lloyd's of London은 바이러스로 인해 손실된 생산성과 피해 규모가 150억 달러를 초과할 것이라는 초기 추정치를 발표했습니다(US House Committee Hearing). Computer Economics는 나중에 전 세계적으로 87억 5,000만 달러의 피해가 발생했다고 추정했습니다(Information Week).

인간의 클릭이 필요 없는 웜이 그 뒤를 이었습니다. 2001년 7월 19일, Code-Red 웜이 14시간도 안 되어 359,000대 이상의 컴퓨터를 감염시켰습니다(CAIDA). 2003년 1월 25일, SQL Slammer는 8.5초마다 규모가 두 배로 불어났으며 10분 만에 취약한 인터넷 호스트의 90% 이상을 감염시켰고(CAIDA), 이는 Microsoft가 6개월 전에 패치를 배포했던 취약점을 악용한 것이었습니다(CNET). 2003년 8월에는 Blaster 웜과 Sobig 이메일 웜이 약 1주일 간격으로 나타났습니다(Microsoft, F-Secure).

당시에는 네트워크로 연결된 컴퓨터를 과연 안전하게 만들 수 있는지에 대한 의문이 제기되는 것이 당연했습니다. ILOVEYOU 바이러스 사태가 발생한 지 6일 후, 미국 하원 소위원회에서 이에 대한 청문회를 개최했습니다. 많은 보안 전문가들은 소프트웨어 기업에 제품 결함으로 인한 피해에 대한 책임을 묻는 법안 제정을 촉구했습니다. 워싱턴은 다른 길을 택했습니다. '사이버 공간 보안을 위한 국가 전략(The National Strategy to Secure Cyberspace)'에서는 “연방 규제가 사이버 공간 보안을 확보하는 주요 수단이 되지는 않을 것”이라고 명시했습니다. 또한 광범위한 규제 Mandate가 “사이버 보안에 대한 최저 공통분모 접근 방식”을 낳을 수 있다고 경고했습니다(CISA).

업계는 엔지니어링으로 이에 대응했습니다. ILOVEYOU 사태 발생 11일 후, Microsoft는 실행 파일 첨부를 차단하는 Outlook 업데이트를 발표했습니다. 2002년 1월, 이 회사는 보안을 최우선 과제로 삼았습니다(Seattle Times). 자동 패치, 안전한 기본 설정, 버그 바운티 프로그램 및 조정된 공개(coordinated disclosure)가 표준 관행이 되었습니다. 2008년, Chrome은 "버그를 악용하여 공격자가 할 수 있는 일을 제어(limit)"하는 샌드박스 내에서 웹 콘텐츠 실행을 시작했습니다(Chromium Blog). 한때 예외였던 암호화가 기본값이 되었습니다. 다중 인증, 방화벽, 제로 트러스트, 보안 정보 및 이벤트 관리(SIEM)를 포함한 보안 기술이 널리 사용되게 되었습니다. 전 세계 조직들은 2026년에 정보 숲0국에 약 2,400억 달러를 지출할 것으로 예상됩니다(Gartner). 웜이 완전히 사라진 것은 아니지만, 일상적인 인터넷 전역의 확산 시대는 자취를 감추었습니다. 동시에 규제의 부담을 크게 덜어낸 인터넷은 향후 20년 동안 혁신과 경제 성장의 강력한 엔진이 되었습니다.

AI 에이전트를 위한 보안 엔지니어링

최근의 사건들은 에이전트 거버넌스에 대한 정당한 의문을 제기했습니다. 기존 보안 메커니즘은 범위가 엄격하게 제한되고 대개 결정론적인 소프트웨어 행태를 특징으로 하는 사전 에이전트 컴퓨팅 환경을 위해 개발되었습니다. 특히 접근 제어 메커니즘은 주로 인간 사용자를 중심으로 설계되었으며, 원칙적으로 상당한 피해를 입히기에 충분한 광범위한 권한을 사용자에게 부여하는 경우가 많습니다.

이러한 설계는 몇 가지 가정에 기반을 두고 있습니다. 대부분의 사용자는 선의로 행동하고, 악의적인 행위자는 감시와 현실 세계의 결과물들을 통해 억제할 수 있으며, 인간은 올바르든 그릇되든 비교적 제한된 속도로 행동을 취한다는 것입니다. 이러한 보안 메커니즘을 에이전트에 적용하려면 인간과 에이전트 행태 간의 차이를 고려해야 합니다. 당사가 AI 에이전트 보안에 관한 NIST의 정보 요청에 대한 답변에서 작성했듯이, AI 에이전트는 이러한 가정들에 도전장을 던집니다. 에이전트는 기계의 속도로 권한을 행사하고 작업을 수행할 수 있으며, 현실 세계의 결과물에 의해 억제되지 않고, 기술적으로는 허용되지만 일반적인 인간 사용자는 거의 수행하지 않을 작업을 수행할 수도 있습니다.

이러한 질문에 답하려면 보안 엔지니어링이 필요합니다. 개별 구성 요소가 오동작할 때 위험을 통제할 수 있는 시스템을 구축하기 위한 보안 원칙은 이미 잘 알고 있습니다. 하지만 AI 에이전트를 훈련, 테스트 및 사용하기 위한 환경을 엔지니어링할 때 이러한 원칙이 반드시 적용되도록 해야 합니다.

심층 방어 보안 원칙

AI 에이전트 보안을 확보하기 위해 적용해야 할 가장 중요한 보안 원칙은 아마도 심층 방어일 것입니다. 심층 방어는 시스템 리소스를 보호하기 위해 다중의 다양하고 중복된 방어 조치를 채택하는 계층화된 보안 아키텍처를 지지합니다. 단일한 안전장치만으로는 완벽할 수 없습니다. 사람은 사회공학적 공격에 속아 로그인 자격 증명을 누설할 수 있고, 제로데이 소프트웨어 취약점이 발견되어 악용될 수 있으며, 침입 탐지는 새로운 공격 변종을 놓칠 수 있습니다. 심층 방어는 이러한 점을 인정하고 몇 가지 독립적인 방어 레이어를 겹쳐서 배치합니다. 하나의 방어 레이어가 우회되더라도 다른 레이어들이 제자리에 남아 침입을 대응하거나 감지합니다.

Hugging Face 사건은 심층 방어(defense-in-depth)가 중요한 이유를 보여줍니다. OpenAI의 회고록에 따르면 하네스, 자동 검토 모델, 안전 분류기를 포함하여 프로덕션 시스템에 사용되는 자동화된 안전장치가 평가 환경에는 누락되어 있었습니다. 당시 평가에서 현재 배포된 사고(chain-of-thought) 모니터링이 실행 중이었다면 침해 발생 하루 이상 전에 초기 활동을 포착하고 보안 팀에 호출(page)했을 것입니다(OpenAI). 문제를 포착할 수 있었던 레이어들은 이미 존재했습니다. 단지 동시에 모두 제자리에 있지 않았을 뿐입니다.

AI 에이전트를 보호하려면 AI 모델의 안전성과 보안을 모두 향상시키는 동시에 그 주변 시스템을 개선해야 합니다. 모델 레이어에서의 작업은 중요하며 성과를 거두고 있습니다. 초기 LLM은 주입된 지시에 쉽게 조작되었지만, 오늘날의 모델은 이러한 지시를 인식하고 거부하는 능력이 훨씬 더 뛰어납니다. 또한 모델 개발자는 더 안전한 행태를 위해 모델을 훈련하며, OpenAI의 회고록에서 설명하듯 문제 있는 행태의 징후에 대해 추론 트레이스를 모니터링합니다. 하지만 모델 수준의 방어는 해결책의 일부일 뿐입니다. 에이전트가 훈련, 테스트 및 배포되는 시스템 역시 보안과 격리를 고려하여 엔지니어링되어야 합니다. 모델 수준의 안전성은 에이전트가 빗나갈 가능성을 줄여주고, 시스템 수준의 보안은 빗나갔을 때의 피해를 제한합니다.

확대

이중 안전장치를 위한 설계 규칙

심층 방어에는 중복 안전장치가 필요합니다. 에이전트의 경우, 당사는 다음 세 가지 설계 규칙을 적용할 것을 권장합니다.

1. 독립성. 각 레이어는 독립적인 이유로 실패해야 합니다. 동일한 가정을 공유하는 두 개의 제어는 동일한 공격에 의해 뚫릴 수 있습니다. 모니터와 집행 지점은 에이전트의 손이 닿지 않는 곳에 위치해야 합니다.
2. 에이전트 하위에서의 강제 집행. 적어도 하나의 레이어는 결정론적이어야 합니다. 즉, 모델이 어떤 결과를 생성하든 금지된 작업을 차단하는 기존의 검증 가능한 코드여야 합니다. 에이전트가 호출을 거부하거나 재구성할 수 있는 안전장치는 안전장치가 아닙니다.
3. 신호는 권한을 줄이는 데만 사용해야 합니다. 탐지 기능은 일시 중지, 자격 증명 취소, 네트워크 액세스 차단 또는 세션 종료 등 에이전트가 수행할 수 있는 작업을 좁히는 대응을 트리거해야 합니다. 어떤 위험 신호도 추가적인 권한을 부여해서는 안 됩니다.

당사는 NVIDIA를 비롯한 Open Secure AI Alliance의 파트너들과 이러한 원칙을 공유하고 있습니다. NVIDIA는 하네스가 에이전트의 시도 방향을 안내하는 반면 인프라는 에이전트가 할 수 있는 작업을 제어한다고 주장해 왔습니다(NVIDIA).

Perplexity 제품에서의 심층 방어

Perplexity는 에이전트 플랫폼인 Computer을 통한 클라우드 환경, Comet을 통한 브라우저 환경, Portable Computer를 통한 사용자 기기 환경, 그리고 엔지니어들이 서드파티 코딩 에이전트를 사용하는 직원 노트북 등 4가지 종류의 환경에서 에이전트를 실행합니다. 각 환경에는 고유한 위험이 따르며, 각각 여러 레이어의 보호를 받습니다.

클라우드 환경: Computer 및 SPACE

모든 Computer 작업은 기본적으로 에이전트를 신뢰할 수 없는 것으로 취급하는 당사의 샌드박스 플랫폼 SPACE에서 실행됩니다. 각 작업에는 고유의 microVM이 부여되고, 자격 증명은 샌드박스 외부에 유지되며 필요할 때만 주입되며, 아웃바운드 트래픽은 게스트 외부에서 제어되고, 스냅샷을 통해 파괴적인 변경 사항을 롤백할 수 있습니다(Making SPACE). 기업 고객은 자체 암호화 키를 가져올 수도 있습니다. 키를 취소하면 보호된 데이터를 읽을 수 없게 되며, 에이전트는 해당 결정을 무시할 수 없습니다.

또한 당사는 이러한 레이어가 잘 작동하는지 테스트합니다. Escaping SPACE: Part I에서 당사는 9개의 프론티어 모델에 SPACE 샌드박스 내부의 루트 액세스 권한을 부여하고 탈출을 시도하도록 요청했습니다. 가상 머신(VM)을 탈출한 모델은 없었지만, 부분적인 네트워크 액세스가 허용되었을 때 일부 모델은 네트워크 정책을 우회하는 방법을 찾아냈습니다. 당사는 해당 취약점을 수정하고 재테스트를 통해 수정을 확인했으며, 다른 10개의 샌드박스 플랫폼 중 8개에서 발견한 유사한 취약점을 해당 공급업체에 공개했습니다.

브라우저: Comet 및 BrowseSafe

Comet은 출시 이후 계층화된 프롬프트 인젝션 방어 기능을 사용해 왔습니다. 분류기가 검색된 콘텐츠를 스크리닝하고, 구조화된 프롬프트가 이를 신뢰할 수 없는 것으로 표시하며, 이메일 전송이나 주문과 같은 민감한 작업은 사용자의 확인을 요구하고, 무언가 차단되었을 때 사용자에게 알림이 전달됩니다(Comet prompt-injection defenses). 첫 번째 레이어 뒤에 있는 오픈소스 탐지 모델인 BrowseSafe는 당사의 BrowseSafe-Bench 벤치마크에서 프론티어 모델보다 우수한 성능을 보여줍니다. 하지만 동일한 벤치마크에 따르면 완벽한 탐지기는 존재하지 않으며, 이 때문에 탐지가 유일한 레이어가 되어서는 안 됩니다(BrowseSafe research). Computer는 Trail of Bits에 의해 감지된 이러한 방어 기능을 상속받았습니다(Perplexity).

기기 정보: Portable Computer

Portable Computer는 로컬 우선 에이전트입니다. 모델, 하네스, 대화 및 궤적은 기본적으로 사용자의 기기에 유지됩니다. LLM이 아닌 하네스 코드인 결정론적 오케스트레이터가 루프를 실행하고 정책을 집행합니다. 모델이 작업을 제어하고, 승인된 도구 호출은 프로세스, 파일 경로 및 네트워크 액세스를 제한하는 OS 수준의 샌드박스에서 실행됩니다. 샌드박스는 항상 켜져 있으며 실패 시 차단(fail-closed)됩니다. 샌드박스를 사용할 수 없는 경우, 하네스는 사용자의 권한으로 명령을 실행하는 대신 스스로 비활성화됩니다. 웹 검색, 커넥터, 더 강력한 클라우드 어드바이저 모델로의 에스컬레이션과 같이 기기 경계를 넘는 작업은 사용자가 해당 기능을 활성화하고 승인할 때만 발생합니다. 어드바이저 호출 전에는 PII 분류기가 민감한 정보를 플래그 처리하고 사용자는 전송될 내용을 확인합니다. 어드바이저는 승인된 해당 컨텍스트만 수신하고 텍스트 가이드라인을 반환하며, 기기의 파일이나 도구에는 액세스할 수 없습니다.

엔드포인트: Numbat

개발자 노트북에서 실행되는 코딩 에이전트는 소스 코드, 자격 증명 및 프로덕션 시스템에 대한 액세스 권한을 가진 채 몇 시간 동안 실행됩니다. 당사의 오픈소스 에이전트 보안 스위트인 Numbat은 단일 에이전트의 외부에 위치하는 독립적인 레이어를 추가합니다. 이 도구는 Claude Code, Codex, OpenCode, Pi 같은 하네스와 함께 작동하며, 실행 전에 위험한 작업을 차단하고, 비밀 정보를 읽은 후 데이터를 외부로 전송하는 것과 같은 의심스러운 다단계 시퀀스를 플래그 처리하며, 조사를 위해 세션 타임라인을 보존합니다. Numbat은 당사의 오픈소스 공급망 스캐너인 Bumblebee와 함께 수천 개의 Perplexity 엔드포인트에서 실행됩니다. Computer는 정기적으로 이들의 발견 내용을 검토하고 개선된 탐지 규칙을 제안하며, 사람이 배포하기 전에 모든 변경 사항을 승인합니다.

전체 업계가 함께 해야 할 과제

AI 에이전트의 역량이 강화되고 널리 사용됨에 따라 보안 엔지니어링은 개발 및 배포 과정의 중심에 남아 있어야 합니다. 연구원과 엔지니어는 확립된 원칙을 바탕으로 구축하고, 실제 발견된 내용을 활용하여 방어를 개선하며, 에이전트가 작동하는 환경 전반에서 안전장치를 테스트할 수 있습니다. 보안은 기술과 함께 발전하는 지속적인 엔지니어링 규율입니다.

에이전트를 위한 보안 엔지니어링은 전체 업계가 함께 해야 할 과제입니다. 에이전트가 실행되는 전체 스택을 제어하는 단일 기업은 없습니다. 모델 개발자, 하네스 제작자, 샌드박스 및 런타임 제공업체, 클라우드 및 하드웨어 공급업체, 기업 보안 팀이 각각 하나의 레이어를 소유합니다. 전체의 안전은 다른 레이어가 흔들릴 때 각 레이어가 제 역할을 다하는지에 달려 있습니다. 이것이 바로 당사가 에이전트 하네스 전반에서 작동하는 안전장치를 구축하고 도구를 오픈소스화하는 이유입니다. 또한 다른 플랫폼에서 발견한 취약점을 공개하고 Open Secure AI Alliance와 같은 노력에 동참하는 이유이기도 합니다.

이러한 과제에 대해 더 넓은 커뮤니티와 협력하기 위해 Perplexity는 2026년 3월 Secure Intelligence Institute를 설립하여 최첨단 AI 시스템의 보안, 신뢰성 및 실용적인 방어를 연구하고 있습니다(Perplexity). Perplexity는 현재 스탠퍼드대학교, 카네기 멜론 대학교(CMU), 듀크대학교, 컬럼비아대학교, 오하이오 주립 대학교, 버지니아 대학교의 학술 연구원들과 협력 및/또는 자금 지원을 진행하고 있습니다. 또한 에이전트 보안 연구의 한계를 넓히고, 이러한 발전 사항을 Perplexity 시스템의 구체적인 개선 사항으로 번역하며, 더 넓은 AI 생태계를 강화하는 데 도움이 되는 지식과 리소스를 공유하기 위해 내부 연구를 수행하고 있습니다. 더 안전한 에이전트는 업계에서 엔지니어링할 수 있는 영역입니다. 당사는 계속해서 제 역할을 다할 것이며, 다른 분들도 당사와 함께 구축에 동참해 주시기를 바랍니다.