AI Agent 프레임워크, 프롬프트 인젝션을 보안 실패로 전환하다

Google News는 이번 주 직설적인 보안 주장을 부각했다. 수년간 이를 중심으로 방어책이 구축됐음에도 프롬프트 인젝션은 근본적인 버그가 아니라는 것이다. 더 깊은 실패는 불확실한 모델 출력을 권한 있는 행동으로 바꾸는 AI Agent 프레임워크에 있다.

이 구분은 엔지니어링 팀이 무엇을 보호해야 하는지를 바꾼다. 조작된 챗봇은 엉뚱한 답변을 내놓을 수 있다. 조작된 에이전트는 비공개 파일을 읽고, API를 호출하고, 코드를 변경하고, 메시지를 보내거나, 공유 메모리를 오염시킬 수 있다.

The Register의 관점은 익숙한 가정에 도전한다. 개발자들은 흔히 악성 텍스트를 취약점으로, 더 강력한 프롬프팅을 해결책으로 여긴다. 더 중요한 질문은 모델이 그 텍스트를 받아들인 뒤 주변 시스템이 무엇을 허용하는가다.

이는 프롬프트 인젝션이 무해하다는 주장이 아니다. 이는 직접 요청이나 신뢰할 수 없는 외부 콘텐츠를 통해 모델에 영향을 미치는 신뢰도 높은 방식으로 남아 있다. 그러나 인젝션이 운영상 침해가 되는 것은 아키텍처가 권한, 데이터, 실행 경로를 제공할 때뿐이다.

따라서 새롭게 부상하는 대결 구도는 명확하다. 한쪽은 모호한 언어 속 위험한 지시를 모델이 알아차리도록 의존한다. 다른 한쪽은 그 인식이 결국 실패할 수 있다고 전제하고, 침해된 모델이 할 수 있는 일을 제한한다.

Google News, Agent 프레임워크를 중심에 놓다

중요한 변화는 책임의 초점이 모델의 행동에서 시스템 아키텍처로 이동하는 데 있다.

프롬프트 인젝션은 보통 모델 보안 문제로 설명돼 왔다. 공격자는 프롬프트, 문서, 웹사이트, 이메일, 이미지 또는 도구 응답 안에 지시를 삽입한다. 그러면 모델은 사용자의 실제 요청 대신 그 지시를 따른다.

이 설명은 정확하지만 불완전하다. 이는 모델에 영향을 미치는 데 사용된 방법을 식별하지만, 실제 피해를 초래하는 통제 실패까지는 식별하지 못한다. 신뢰할 수 없는 텍스트가 스스로 파일을 삭제하거나, 고객 기록을 조회하거나, 소스 코드를 게시할 수는 없다.

Agent 프레임워크는 그러한 기능을 제공한다. 모델을 도구, 자격 증명, 메모리, 데이터베이스, 브라우저, 코드 인터프리터, 다른 에이전트와 연결한다. 또한 모델이 새로운 사람의 승인 없이 행동할 수 있는지 결정할 수도 있다.

아키텍처는 하나의 잘못된 해석을 연쇄적인 부작용으로 전환할 수 있다. 오염된 웹페이지는 도구 요청이 된다. 도구 요청은 데이터베이스 쿼리가 된다. 이후 조회된 자료는 같은 에이전트가 생성한 외부 발신 메시지에 나타난다.

간접 프롬프트 인젝션은 여기서 특히 중요하다. 공격자는 채팅 인터페이스에 접근할 필요가 없다. 악성 지시는 에이전트가 일상적인 작업 중 마주치는 콘텐츠 안에 숨어 기다릴 수 있다.

리서치 에이전트는 웹페이지에서 해당 지시를 마주칠 수 있다. 코딩 어시스턴트는 이슈 설명이나 리포지토리 파일에서 이를 발견할 수 있다. 오피스 에이전트는 이메일, 캘린더 초대 또는 공유 문서에서 이를 받아들일 수 있다.

모델은 모든 경우에 어려운 분류 문제에 직면한다. 지시를 설명하는 텍스트와 따라야 하는 텍스트를 구분해야 한다. 둘 다 모델의 작업 컨텍스트 안에서 자연어 토큰으로 들어온다.

OWASP risk definition은 직접 및 간접 인젝션을 모두 인정한다. 또한 영향은 비즈니스 맥락과 모델에 부여된 자율성에 크게 좌우된다고 지적한다.

마지막 조건은 처음 보이는 것보다 더 중요하다. 같은 악성 문장도 두 배포 환경에서 완전히 다른 결과를 낳을 수 있다. 읽기 전용 요약기는 오염된 문단을 생성할 수 있지만, 권한 있는 에이전트는 기밀 정보를 노출할 수 있다.

Google News는 이 논쟁을 발견하는 채널로는 유용하지만, 근본적인 권위 출처는 아니다. 헤드라인은 에이전트 하이재킹을 점점 더 아키텍처적 위협으로 다루는 더 폭넓은 보안 연구를 가리킨다.

NIST는 에이전트 하이재킹을 에이전트가 의도하지 않은 유해한 행동을 하도록 만드는 간접 프롬프트 인젝션으로 설명한다. hijacking evaluations에서는 시뮬레이션된 작업 공간, 여행 서비스, 메시징 시스템, 은행 도구를 사용한다.

이러한 환경은 에이전트 보안이 챗봇 안전성과 다른 이유를 보여준다. 모델은 단지 질문에 답하는 것이 아니다. 권한과 실제 결과를 수반하는 워크플로 안에서 행동을 선택하고 있다.

이러한 재구성은 취약점 보고도 더 정교하게 만든다. “프롬프트 인젝션”은 영향력이 시스템에 들어온 방식을 설명한다. 유용한 보안 발견은 무단 데이터 접근이나 승인되지 않은 코드 실행 같은 그 결과적 영향도 식별해야 한다.

기존 보안 팀도 이미 비슷한 구분을 한다. 사용자가 제어하는 입력이 자동으로 침해를 의미하지는 않는다. 소프트웨어가 해당 입력을 안전하지 않은 인터프리터에 전달하거나 보안 경계를 넘어 신뢰할 때 취약점이 발생한다.

언어 모델은 지시와 데이터가 유연한 표현 방식을 공유한다는 점에서 이 비유를 복잡하게 만든다. 모든 자연어 작업에 적용되는 매개변수화된 데이터베이스 쿼리의 보편적 등가물은 없다. 따라서 모델 주변의 격리가 더욱 중요하다.

핵심 사건은 개념적인 것이지만 운영상 의미가 크다. 보안 작업은 완벽한 지시 필터링이라는 약속에서 멀어지고 있다. 모델이 잘못된 결정을 내린 뒤에도 효과를 유지하는 제한으로 이동하고 있다.

프롬프트 인젝션은 방아쇠일 뿐, 피해 범위가 아니다

주입된 지시는 영향력을 만들고, 그 영향력이 사고가 되는지는 프레임워크가 결정한다.

수신 지원 티켓을 검토하도록 요청받은 에이전트를 생각해 보자. 이 에이전트는 티켓 텍스트, 고객 세부 정보, 어쩌면 내부 지식 기반에 접근해야 한다. 환불을 처리하거나 계정 메시지를 보내는 도구도 보유할 수 있다.

공격자는 티켓 안에 숨겨진 지시를 삽입한다. 이 지시는 에이전트에게 다른 고객의 기록을 조회해 응답에 포함하라고 말한다. 모델은 자신이 맡은 워크플로를 완료한다고 믿으며 그 지시를 따른다.

데이터가 회사를 떠나기 전에 여러 실패가 발생해야 한다. 에이전트는 현재 티켓이 요구하는 것보다 더 광범위한 접근 권한을 받아야 한다. 도구 계층은 모델이 생성한 매개변수를 수용해야 한다. 외부 발신 행동은 독립적인 승인 없이 진행돼야 한다.

악성 텍스트는 연쇄의 시작점이었다. 과도한 권한, 누락된 데이터 경계, 부재한 승인 게이트를 만든 것은 아니다. 그러한 결정은 애플리케이션과 프레임워크에서 비롯됐다.

이 구분은 AI Agent 보안의 핵심이다. 시스템은 특히 모델이 공격자 제어 콘텐츠를 처리할 때 모델의 판단이 오류를 낼 수 있다고 가정해야 한다. 보안 통제는 그 판단 루프 밖에 남아 있어야 한다.

도구 스키마만으로는 문제가 해결되지 않는다. 스키마는 유효한 이메일 주소나 문서 식별자를 요구할 수 있다. 그러나 모델이 해당 주소에 연락하거나 해당 문서를 조회할 정당한 이유가 있는지는 판단할 수 없다.

형식이 올바른 악성 행동은 여전히 악성이다. 프레임워크는 사용자 신원, 데이터 소유권, 작업 범위, 출처, 현재 승인 상태와 연결된 정책 집행이 필요하다.

출처란 정보가 어디에서 왔는지 기록하고 워크플로 전반에 걸쳐 그 레이블을 보존하는 것을 의미한다. 알려지지 않은 웹페이지의 콘텐츠가 한 에이전트의 요약을 거쳤다는 이유만으로 신뢰할 수 있는 상태를 얻어서는 안 된다.

이 규칙은 멀티 에이전트 시스템에서 더 어려워진다. 한 모델은 주제를 조사하고, 다른 모델은 응답을 계획하며, 세 번째 모델은 도구를 실행할 수 있다. 악성 지시는 에이전트 간에 출력이 전달되며 변형될 수 있다.

수신 에이전트는 자신에게 영향을 준 신뢰할 수 없는 출처를 보지 못한 채 다듬어진 문장만 볼 수 있다. 프레임워크가 출처 정보를 버리면, 다른 에이전트를 통한 지시 세탁은 사실상 그 권한을 높일 수 있다.

영구 메모리는 또 다른 경로를 만든다. 공격자는 에이전트가 유해한 규칙, 거짓 사실 또는 변경된 선호를 저장하도록 설득할 수 있다. 이후 세션은 원래의 악성 콘텐츠가 사라진 뒤에도 해당 항목을 조회할 수 있다.

personal knowledge base를 구축하는 팀도 관련된 신뢰 문제에 직면한다. 특히 에이전트가 그 정보에 따라 행동할 수 있다면, 검색된 정보는 출처와 접근 맥락을 유지해야 한다.

메모리가 보이지 않는 제어 평면이 되어서는 안 된다. 쓰기 작업에는 제약, 감사 기록, 사용자 승인 선호와 모델 생성 관찰 결과 간의 명확한 분리가 필요하다.

브라우징은 고유한 위험을 더한다. 페이지에는 사람이 아닌 모델을 위해 설계된 가시적 지시, 숨겨진 텍스트, 메타데이터, 이미지 콘텐츠 또는 적대적 자료가 포함될 수 있다. 에이전트는 브라우징이 본래 기능이므로 해당 콘텐츠를 처리한다.

Google은 알려진 간접 인젝션 패턴을 찾기 위해 공개 웹을 모니터링한다고 보고했다. web threat research는 브라우징 에이전트가 공격자 제어 페이지를 일상적으로 소비하기 때문에 이러한 패턴을 우선순위로 다뤘다.

이는 구조적인 트레이드오프를 만든다. 에이전트의 정보 접근 범위가 넓어질수록 신뢰할 수 없는 콘텐츠를 더 많이 마주한다. 더 큰 권한을 받을수록 한 번의 잘못된 해석이 초래할 수 있는 영향도 커진다.

모든 외부 콘텐츠를 제거하면 많은 에이전트는 쓸모없어진다. 모든 외부 콘텐츠에 동등한 영향력을 부여하면 안전하지 않다. 프레임워크는 언어만으로 보장할 수 없는 경계를 집행하면서 유용성을 유지해야 한다.

이는 계획과 승인을 분리한다는 뜻이다. 모델은 행동을 제안하고, 이유를 설명하며, 매개변수를 준비할 수 있다. 결정론적 정책 서비스가 그 행동이 허용되는지 결정해야 한다.

그 결정은 현재 사용자, 요청된 작업, 대상 리소스, 데이터 민감도, 콘텐츠 출처를 고려해야 한다. 영향이 큰 행동에는 무엇이 일어날지를 명확히 보여주는 확인 절차가 필요하다.

확인 내용 전체를 잠재적으로 침해된 모델이 작성해서는 안 된다. 그렇지 않으면 공격자는 제안된 행동과 사용자에게 표시되는 설명 모두에 영향을 줄 수 있다.

신뢰할 수 있는 인터페이스는 검증된 도구 매개변수로부터 핵심 세부 정보를 구성해야 한다. 대상 위치, 영향을 받는 기록, 요청된 권한, 시스템 밖으로 나갈 예정인 모든 데이터를 식별해야 한다.

이것이 피해 범위를 측정 가능하게 만드는 방식이다. 프롬프트 인젝션이 언어 계층에서 성공하더라도, 공격자는 결과가 중대한 각 경계에서 별도의 통제를 마주하게 된다.

그 결과는 영리한 프롬프트 엔지니어링보다 성숙한 애플리케이션 보안에 더 가깝다. 최소 권한, 격리, 명시적 승인, 출력 검증, 로깅, 사고 대응은 여전히 필수적이다.

더 강력한 시스템 프롬프트가 보안 경계를 맡을 수 없는 이유

프롬프트 강화는 성공적인 공격을 줄이지만, 잔여 실패 가능성 때문에 최종 승인 계층으로는 적합하지 않다.

시스템 프롬프트는 에이전트에게 외부 콘텐츠에서 발견한 지시를 무시하라고 지시할 수 있다. 소스 자료에 신뢰할 수 없다는 레이블을 붙이고, 사용자 목표만 따르도록 모델에 상기시킬 수도 있다.

이러한 조치는 사용할 가치가 있다. 단순한 공격을 차단하고, 우발적인 이탈을 줄이며, 공격자가 더 많은 노력을 들이게 할 수 있다. 또한 모델이 의심스러운 콘텐츠를 즉시 실행하는 대신 설명하도록 돕는다.

Google 연구진은 멀티에이전트 코딩 프레임워크 전반에서 보안 프롬프팅을 테스트했다. 이들의 멀티에이전트 연구는 150개 이상의 단일 턴 및 32개의 멀티 턴 공격 시나리오를 다뤘다.

약 500토큰 분량의 보안 하드너는 단일 턴 실패율을 19.48%에서 2.60%로 낮췄다. 멀티 턴 실패율은 75%에서 46.88%로 감소했다.

이 결과는 프롬프트 하드닝의 가치를 뒷받침하는 동시에 그 한계도 드러낸다. 에이전트가 코드를 실행하고, 자격 증명에 접근하거나, 프로덕션 리소스를 수정할 수 있다면 46.88%의 멀티 턴 실패율은 여전히 용납할 수 없다.

더 낮은 단일 턴 비율조차 대규모 환경에서는 실질적인 위험을 만든다. 반복 상호작용은 공격자에게 추가 기회를 제공하며, 공격자는 모델의 동작을 관찰한 뒤 표현을 조정할 수 있다.

이 연구는 성공한 공격이 기능적 래퍼로 이동하는 경향도 발견했다. 이러한 공격은 일반적인 에이전트 기능처럼 보이는 작업 안에 악의적 의도를 숨긴다. 정적인 지침은 정당한 업무까지 막지 않고는 이를 거부하기 어렵다.

이것이 보안 경계를 모델 내부에 두는 방식의 핵심 문제다. 모델은 개방형 요청을 해석하는 동시에, 그 요청이 또 다른 개방형 지침을 위반하는지 예측해야 한다.

운영체제가 파일 접근을 확인하듯 안정적인 권한 규칙을 평가하는 것이 아니다. 대신 문맥에 포함된 모든 관련 토큰의 영향을 받는 확률적 응답을 생성한다.

프롬프트 인젝션을 단지 “이전 지침 무시”로 설명하면 이러한 모호성을 놓치게 된다. 효과적인 공격은 항상 충돌을 드러내지 않는다. 거짓 맥락을 제시하거나, 신뢰할 만한 워크플로 언어를 모방하거나, 의도를 여러 단계에 나눠 숨길 수 있다.

코드를 검토하는 에이전트는 필수 테스트를 설명하는 듯한 텍스트를 마주할 수 있다. 그 테스트는 외부 구성요소를 조용히 다운로드하거나 실행한다. 각각의 단계는 개발 워크플로 안에서는 그럴듯해 보일 수 있다.

브라우징 에이전트는 요청한 페이지에 접근하려면 특정 작업이 필요하다는 안내를 받을 수 있다. 오피스 어시스턴트는 회사 정책상 컴플라이언스 검토를 위해 내용을 전달해야 한다고 주장하는 문서를 읽을 수도 있다.

모델은 모든 조직의 실제 정책을 독립적으로 알지 못한다. 프레임워크가 모델이 생성한 주장이 모델이 생성한 행동을 승인하도록 허용한다면, 시스템은 순환 구조에 빠진다.

필터도 유사한 한계에 부딪힌다. 탐지기는 알려진 문구를 찾거나 텍스트가 적대적으로 보이는지 추정할 수 있다. 공격자는 지침을 바꿔 말하고, 페이로드를 나누고, 여러 형식에 숨기거나, 정상 데이터처럼 보이게 만들 수 있다.

모든 명령문을 차단하면 일반적인 워크플로가 무너진다. 문서, 이메일, 코드 주석, 지원 티켓에는 정당하게 지침이 포함된다. 에이전트는 종종 그러한 지침을 자신의 목표로 채택하지 않으면서도 이해해야 한다.

파인튜닝은 저항성을 높일 수 있지만, 아키텍처적 충돌을 제거하지는 못한다. 모델은 여전히 신뢰할 수 없는 언어를 해석해야 하며, 새로운 공격 패턴은 학습 분포 밖에 있을 수 있다.

검색 증강 생성도 이 충돌을 없애지 못한다. RAG는 외부 자료를 검색해 모델의 문맥에 추가한다. 출처가 오염됐다면 검색은 공격자의 지침이 관련 있어 보이는 바로 그 순간 이를 전달할 수 있다.

모델 업그레이드는 예기치 않게 위험을 바꿀 수도 있다. 더 뛰어난 모델은 공격을 더 잘 탐지할 수 있지만, 공격이 성공한 뒤에는 도구도 더 효과적으로 사용할 수 있다.

이 때문에 벤치마크 점수에는 맥락이 필요하다. 고정된 테스트 스위트에서 대부분의 인젝션을 거부하는 모델이 배포된 에이전트의 안전성을 입증한 것은 아니다. 실제 시스템에는 맞춤형 도구, 권한, 메모리, 통합이 존재한다.

방어의 목표는 우아한 실패여야 한다. 모델이 콘텐츠를 잘못 분류하더라도, 주변 시스템은 결과를 제한하고 시도를 드러내며 검토를 위한 증거를 보존해야 한다.

읽기 전용 에이전트도 사용자를 오도할 수 있으므로 출력 품질은 중요하다. 그러나 가장 심각한 결과는 대개 프레임워크가 불확실한 추론과 제한 없는 권한을 결합할 때 발생한다.

따라서 보안 프롬프트는 계층형 설계에 포함돼야 한다. 이는 하나의 통제 수단일 뿐, 비공개 데이터가 경계를 넘는지 또는 실행 가능한 코드가 워크스테이션에 도달하는지를 결정하는 통제 수단은 아니다.

AI 에이전트 보안은 역량, 맥락, 동의에 달려 있다

프레임워크는 모델을 집행 가능한 검사가 필요한 제안을 내놓는 신뢰할 수 없는 플래너로 다뤄야 한다.

첫 번째 아키텍처적 통제는 역량 최소화다. 에이전트에는 사용자나 조직이 사용할 수 있는 모든 통합이 아니라, 현재 작업에 필요한 도구만 제공해야 한다.

캘린더 요약기는 메일 발송 권한이 거의 필요 없다. 리서치 어시스턴트에 셸 접근 권한이 자동으로 필요한 것도 아니다. 코드 리뷰어는 변경사항 병합 권한 없이 저장소 읽기 권한만 필요할 수 있다.

정적인 최소 권한도 유용하지만, 작업별 권한 부여가 더 낫다. 도구는 하나의 제한된 작업에만 사용할 수 있게 하고, 그 작업이 끝나면 사라지게 할 수 있다.

자격 증명도 모델의 문맥 밖에 남아 있어야 한다. 모델은 재사용 가능한 시크릿을 직접 다루기보다 브로커를 통해 작업을 요청해야 한다. 로그는 프롬프트와 도구 응답에서 민감한 토큰을 마스킹해야 한다.

두 번째 통제는 맥락적 권한 부여다. 기존 접근 검사는 흔히 사용자가 리소스에 접근할 수 있는지를 묻는다. 에이전트 시스템은 그 접근이 사용자의 현재 요청을 뒷받침하는지도 물어야 한다.

두 고객 계정을 읽을 수 있는 사용자가 에이전트에게 이를 결합하도록 승인한 것은 아니다. 배포 접근 권한이 있는 개발자가 모든 코드 리뷰 에이전트의 배포를 승인한 것도 아니다.

의도는 언어만으로 완벽하게 추론할 수 없지만, 프레임워크는 명시적인 작업 선언을 통해 이를 좁힐 수 있다. 도구를 선언된 목표, 리소스 집합, 시간 범위, 허용된 데이터 흐름에 바인딩할 수 있다.

세 번째 통제는 결과가 중대한 행동에 대한 동의다. 특히 정보를 외부로 전송하거나, 돈을 지출하거나, 접근 권한을 변경하거나, 데이터를 삭제하거나, 신뢰할 수 없는 코드를 실행하기 전에는 사람의 승인이 중요하다.

동의는 실질적이어야 한다. 반복되는 모호한 팝업은 사용자가 확인 없이 승인하도록 훈련한다. 인터페이스는 정확한 행동을 식별하고 원래 작업에서 벗어난 부분을 강조해야 한다.

위험이 낮고 되돌릴 수 있는 행동에는 더 가벼운 통제를 사용할 수 있다. 고위험 또는 되돌릴 수 없는 행동에는 더 강한 확인이 필요하며, 기업 환경에서는 두 번째 승인자가 필요할 수도 있다.

네 번째 통제는 격리다. 코드 실행은 네트워크, 파일 시스템, 자격 증명 접근이 제한된 샌드박스 안에서 이뤄져야 한다. 브라우저 세션은 신뢰할 수 없는 페이지와 민감한 애플리케이션 상태를 분리해야 한다.

도구 출력은 자동으로 신뢰하는 지침이 아니라 데이터로 취급해야 한다. 프레임워크는 도구 출력을 모델에 반환하기 전에 크기, 형식, 대상, 허용된 콘텐츠를 검증해야 한다.

다섯 번째 통제는 출처 보존이다. 각 문서, 메시지, 웹페이지, 메모리 항목, 에이전트 응답에는 출처와 신뢰도 분류가 담겨야 한다.

한 에이전트가 신뢰할 수 없는 페이지를 요약했다면, 그 요약도 신뢰할 수 없는 상태로 남아야 한다. 변환 과정에서 계보가 사라져서는 안 된다. 그러면 다운스트림 정책 엔진은 낮은 신뢰도의 자료가 고영향 행동을 승인하지 못하게 막을 수 있다.

여섯 번째 통제는 제안과 실행의 분리다. 플래너는 이메일을 보내야 한다고 판단할 수 있지만, 별도의 구성요소가 수신자와 첨부파일을 검증해야 한다.

이 분리는 혼동된 대리인 공격을 제한한다. 혼동된 대리인은 정당한 권한을 가진 시스템이 다른 사람의 목적을 위해 그 권한을 사용하도록 조작될 때 발생한다.

일곱 번째 통제는 관측 가능성이다. 팀에는 어떤 출처가 의사결정에 영향을 미쳤는지, 어떤 모델이 행동을 제안했는지, 어떤 정책이 이를 허용했는지, 어떤 도구가 수행했는지를 보여주는 기록이 필요하다.

이런 기록이 없다면 조직은 에이전트 사고를 재구성할 수 없다. 일반적인 애플리케이션 로그는 API 호출을 포착할 수 있지만, 프롬프트, 검색된 콘텐츠, 메모리 상태, 에이전트 간 메시지를 놓칠 수 있다.

모니터링은 행동에도 초점을 맞춰야 한다. 경고 신호에는 비정상적인 리소스 조합, 반복적인 권한 부여 실패, 새로운 외부 전송 대상, 예상치 못한 메모리 쓰기, 또는 일반적인 순서 밖에서 사용된 도구가 포함된다.

여덟 번째 통제는 전체 워크플로 전반의 적대적 테스트다. 기본 모델만 테스트하면 권한과 부작용이 존재하는 프레임워크를 놓치게 된다.

NIST의 접근법은 에이전트 보안이 맥락에 따라 달라지기 때문에 현실적인 도구와 작업을 사용한다. 모델은 평범한 채팅에서는 공격을 견딜 수 있지만, 동일한 지침이 신뢰할 만해 보이는 비즈니스 객체 안에 나타나면 실패할 수 있다.

레드팀은 에이전트가 소비하는 모든 출처에 악성 콘텐츠를 심어야 한다. 여기에는 웹사이트, 이메일, 문서, 코드 저장소, 이슈 트래커, 도구 메타데이터, 검색 결과, 공유 메모리가 포함된다.

멀티 턴 및 멀티에이전트 경로도 테스트해야 한다. 직접 명령이 차단되더라도 중개 에이전트가 이를 재구성하거나 나중에 검색되도록 저장한 뒤 성공할 수 있다.

목표는 단일 프롬프트 인젝션 성공률을 발표하는 것이 아니다. 어떤 성공한 인젝션이 민감한 데이터, 권한이 높은 도구, 또는 되돌릴 수 없는 작업에 도달하는지 식별하는 것이다.

이는 더 나은 우선순위 설정을 뒷받침한다. 임시 초안을 오염시키는 데 그치는 빈번한 인젝션도 주의가 필요하다. 프로덕션 자격 증명에 도달하는 더 드문 인젝션에는 우선 더 강력한 통제가 필요하다.

OWASP는 최소 권한, 외부 콘텐츠 분리, 사람의 승인, 출력 검증, 적대적 테스트를 권고한다. 이러한 조치는 하나의 탐지기에 대한 신뢰가 아니라 심층 방어 모델을 반영한다.

NIST의 더 넓은 공격 분류 체계 역시 공격 식별과 함께 결과를 관리하는 일을 강조한다. 완전한 예방은 여전히 불확실하기 때문에 이 접근법은 에이전트 시스템에 적합하다.

이러한 통제 중 어느 것도 모델을 신뢰할 수 있게 만들지는 않는다. 대신 시스템이 모델의 신뢰성에 덜 의존하게 만든다. 그것이 더 방어 가능한 엔지니어링 목표다.

Google News 독자가 다음으로 주목해야 할 점

결정적인 근거는 프레임워크 기본값, 측정 가능한 격리, 투명한 사고 보고에서 나올 것이다.

첫 번째 신호는 주요 프레임워크가 제한된 실행을 기본값으로 만드는지 여부다. 선택형 샌드박싱과 권한 통제는 숙련된 팀에 도움이 되지만, 기본값은 수천 건의 일반적인 배포를 좌우한다.

에이전트 플랫폼이 도구 권한 부여, 네트워크 접근, 파일 시스템 쓰기, 재사용 가능한 자격 증명을 어떻게 다루는지 살펴봐야 한다. 폭넓은 역량을 먼저 노출하고 나중에 하드닝을 문서화하는 프레임워크는 근본적인 위험을 그대로 유지한다.

가장 강력한 기본값은 민감한 도구를 자동으로 전혀 부여하지 않는 것이다. 개발자는 각 권한의 결과를 확인하면서 범위가 좁은 역량을 추가하게 된다.

두 번째 신호는 평가가 엔드투엔드 영향을 측정하는지 여부다. 공격 거부율은 유용하지만, 성공한 공격이 기밀 데이터에 도달했는지 또는 위험한 행동을 완료했는지는 보여주지 않는다.

더 나은 평가는 모델 침해와 시스템 침해를 모두 보고할 것이다. 조작된 답변과 무단 읽기, 외부 전송, 코드 실행, 지속적인 메모리 변경을 구분할 것이다.

반복 시도 전반의 결과도 공개해야 한다. 한 번은 성공하지만 여러 변형 뒤에는 실패하는 방어는 인터넷에 노출된 서비스에서 제한적인 보호만 제공한다.

Google 연구 결과는 이러한 필요를 보여준다. 프롬프트 하드닝은 저항성을 크게 개선했지만, 멀티 턴 공격은 높은 실패율을 유지했다. 아키텍처적 통제가 이러한 잔여 실패가 무엇을 의미하는지 결정한다.

세 번째 신호는 공개 품질이다. AI 특화 사고에는 기존 취약점 관리에서 활용하던 익숙한 산출물이 없는 경우가 많다. 팀은 표준 식별자, 영향받는 버전 범위, 명확한 완화 경로 없이 벤더 블로그 게시물만 받게 될 수 있다.

프레임워크 제공업체는 전체 공격 체인을 설명하는 보안 권고문을 공개해야 한다. 사용자는 필요한 콘텐츠 출처, 모델 동작, 권한, 도구, 영향받는 버전, 이용 가능한 완화 조치를 알아야 한다.

모델에 “추가 보호 조치”가 적용됐다는 모호한 설명만으로는 충분하지 않다. 고객은 벤더가 모델, 프레임워크 정책, 권한 시스템, 샌드박스, 사용자 승인 흐름 중 무엇을 변경했는지 이해해야 한다.

동일한 기준은 버그 바운티 판단에도 적용돼야 한다. 보고서가 프롬프트 인젝션을 입증했지만 실질적인 영향이 없다면 낮은 심각도 평가는 합리적일 수 있다. 그러나 인젝션이 권한 있는 작업에 도달한다면, 이를 예상된 모델 동작이라며 기각하는 것은 실제 문제를 회피하는 일이다.

Google News는 생생하고 재현하기 쉬운 프롬프트 인젝션 시연 사례를 계속 노출할 것이다. 일부는 경미한 탈옥에 그치겠지만, 다른 일부는 심각한 프레임워크 실패를 드러낼 것이다.

독자는 세 가지 질문을 구분해야 한다. 공격자가 모델에 영향을 미쳤는가? 그 영향 이후 어떤 기능을 사용할 수 있게 됐는가? 그 결과로 발생한 작업을 어떤 독립적인 통제가 막았어야 하는가?

이 순서는 프롬프트 인젝션이 마침내 해결됐는지를 묻는 것보다 더 유용한 위험 평가를 제공한다. 현재의 증거로는 보편적인 해결책이 있다고 가정할 근거가 없다.

개발자는 신뢰할 수 없는 콘텐츠와 민감한 도구 사이의 모든 경로를 점검해야 한다. 엔터프라이즈 구매자는 작업 범위에 제한된 권한, 출처 추적, 샌드박싱, 승인 통제, 감사 가능한 실행 기록을 요구해야 한다.

지식 근로자는 이메일, 파일, 캘린더, 업무 시스템을 연결하기 전에 에이전트가 무엇에 접근할 수 있는지 확인해야 한다. 이러한 소스를 결합하면 편의성은 빠르게 높아지지만, 잠재적 피해 범위도 함께 커진다.

핵심적인 관점 전환은 여전히 단순하다. 프롬프트 인젝션은 촉발 요인이고, 프레임워크는 도달 범위, 권한, 지속성을 제공한다. 촉발 요인만 다루면 위험한 장치는 그대로 남는다.

다음에 Google News 헤드라인이 또 다른 에이전트 하이재킹을 알릴 때는 악의적인 문구 너머를 살펴보라. 어떤 도구가 이를 실행했는지, 어떤 권한이 이를 허용했는지, 왜 별도의 통제가 개입하지 않았는지 물어야 한다.

이것이 이제 에이전트 개발자가 통과해야 할 시험이다. 모델이 설득당하거나 혼란에 빠지거나 단순히 틀렸더라도 시스템은 안전하게 유지될 수 있는가? 답이 더 나은 프롬프팅에만 달려 있다면, 프레임워크에는 여전히 버그가 남아 있다.