프롬프트 인젝션(Prompt Injection)을 막을 수는 없습니다. 그렇다면 실제로 무엇을 해야 할까요?

많은 에이전트 보안 작업에는 조용한 가정이 깔려 있습니다. 즉, 충분한 프롬프트 엔지니어링 (Prompt Engineering), 적절한 시스템 메시지 (System Message), 또는 다음 모델 버전이 나오면 모델이 악의적인 지시를 따르는 것을 멈출 것이라는 가정입니다. 하지만 그런 일은 일어나지 않았으며, 마치 그런 일이 일어나지 않을 것처럼 설계하는 것이 가치가 있습니다. 현재 어떤 모델도 입력값이 지시 사항(Instructions)의 형식으로 구성되었을 때 적대적 입력 (Adversarial Input)을 안정적으로 거부하지 못합니다. 정교하게 제작된 단 하나의 프롬프트가 당신이 위에 쌓아 올린 세심한 정렬 (Alignment)을 제거할 수 있습니다.

따라서 유용한 질문은 "어떻게 인젝션을 방지할 것인가?"가 아닙니다. "인젝션은 때때로 성공할 것이다 — 그 이후에 내 에이전트의 상태는 어떠하며, 그 시점에서 에이전트가 실제로 무엇을 할 수 있는가?"가 되어야 합니다.

이러한 관점의 전환이 런타임 보안 (Run-time Security)의 핵심입니다. 즉, 설계 시점에 고민하는 보호책이 아니라, 모든 실행 시점에 실시간으로 작동하는 보호책을 의미합니다. 다음은 실제 상황에서 효과가 있었던 부분들입니다.

모델은 보안 경계(Security Boundary)가 아닙니다

단 하나의 입력으로 모델의 동작을 뒤집을 수 있다면, 모델은 공격자와 당신의 시스템 사이를 가로막는 장치가 될 수 없습니다. 모델을 가끔 잘못된 행동을 할 수 있는 하나의 컴포넌트 (Component)로 취급하고, 모델이 말로써 통과할 수 없는 곳에 경계를 설정하십시오.

구체적으로, 이는 모델의 하위 단계에서 두 가지를 의미합니다:

권한 범위가 제한된 자격 증명 (Capability-scoped credentials). 에이전트는 현재 작업에 필요한 권한만을 보유합니다. 읽기 전용의 좁은 범위로 제한된 토큰 (Token)을 가진 탈취된 에이전트는 관리자 키 (Admin Key)를 가진 에이전트보다 훨씬 적은 피해를 입힙니다.
파괴적인 동사에 대한 게이트 (A gate on destructive verbs). 삭제, 전송, 결제, 액세스 권한 부여 — 이러한 작업들은 모델의 동작 여부에 의존하지 않는 명시적인 확인(정책, 확인 절차, 2단계 인증 등)을 거쳐야 합니다.

봉쇄 (Containment)는 폭발 반경 (Blast Radius)을 제한합니다. 탐지 (Detection)는 사건이 발생했음을 알려줍니다. 이 중 어느 것도 모델이 신뢰할 수 있어야 할 것을 요구하지 않으며, 이것이 바로 핵심입니다.

데이터 채널과 지시 채널을 분리하십시오

거의 모든 인젝션(injection) 버그는 단 한 문장으로 요약됩니다: 데이터가 지시 사항(instructions)으로 읽혔다는 것입니다. 가져온 웹 페이지, 검색된 문서, 도구 출력(tool output), 사용자 업로드 — 이 모든 것은 _데이터(data)_이며, 어딘가에서 모델이 _명령(commands)_으로 취급하는 컨텍스트(context)에 결합되었습니다.

따라서 사용자 메시지, 가져온 페이지, 도구 출력, 검색된 문서, 업로드 등 모든 외부 입력을 신뢰할 수 없는 것으로 취급하십시오. 여기서 간접 인젝션(Indirect injection)은 매우 까다로운 사례입니다. 페이로드(payload)가 에이전트가 스스로 가져온 콘텐츠에 실려 들어오기 때문에, "출처를 신뢰하는 것"은 아무런 도움이 되지 않습니다. 데이터가 들어오는 경계에서 방어해야 하며, 신뢰할 수 없는 텍스트를 지시 컨텍스트(instruction context)에 끼워 넣지 마십시오.

데이터 위생(Data hygiene)은 양방향으로 이루어집니다

여기서 놓치기 쉬운 부분이 있습니다. 여러분은 들어오는 것(in)을 감시합니다. 하지만 도구의 출력(output) 또한 유출 채널(leakage channel)이 될 수 있습니다.

에이전트 프레임워크(Agent frameworks)는 디버그 로깅(debug logging)을 포함한 도구의 표준 출력(stdout)을 모델의 컨텍스트 창(context window)으로 직접 전달하고, 거기서 다시 여러분의 로그로 보냅니다. 17,022개의 에이전트 기술(agent skills)을 대상으로 한 실증적 연구에 따르면, 바로 이러한 방식으로 자격 증명(credentials)이 유출되는 것이 발견되었으며, 그중 73.5%의 사례가 디버그 로깅 때문이었습니다. 비밀 정보는 모델을 위해 의도된 것이 아니었으나, 단지 표준 출력(stdout)에 있었고 프레임워크가 이를 전달했을 뿐입니다.

해결책은 화려하지 않습니다: 도구 출력이 컨텍스트나 로그에 도달하기 _전(before)_에 비밀 정보를 삭제(redact)하십시오. 입력과 동일한 규율을 반대 방향으로 적용하는 것입니다.

품질과는 별개로 행동을 모니터링하십시오

탈취된 에이전트는 해서는 안 될 일을 수행하면서도 깨끗하고 형식이 잘 갖춰진 "고품질(high quality)"의 출력을 생성할 수 있습니다. 결과물(result) 자체에는 잘못된 점이 없어 보이기 때문에 품질 모니터링으로는 이를 잡아낼 수 없습니다. 별도의 신호가 필요합니다: 이 _행동 시퀀스(sequence of actions)_가 이 에이전트의 정상적인 행동처럼 보이는가?

이는 예상되는 행동 시퀀스를 기준점(baseline)으로 설정하고, 편차(deviation)가 발생할 때 경고를 보내는 것을 의미합니다. 노력의 정도에는 다음과 같은 단계가 있습니다:

정적 규칙 (Static rules) — 비용이 저렴하며, 명백한 상황(예: 이메일을 전혀 보내지 않던 에이전트가 갑자기 이메일을 보내는 경우)을 포착합니다.
시퀀스 패턴 베이스라인 (Sequence-pattern baselines) — 에이전트 행동의 정상적인 형태를 학습하고, 이에 부합하지 않는 행동을 플래그(flag)합니다.
판사로서의 두 번째 모델 (A second model as judge) — 기본 에이전트의 행동에 대한 독립적인 검토를 수행합니다.

간과하기 쉬운 세부 사항 하나는 다음과 같습니다: 의사 결정 시점의 로그 컨텍스트 크기 (log context size at decision time)를 기록하십시오. 컨텍스트 크기는 행동을 형성하므로, 이를 조건화(condition)하지 않는 베이스라인은 드리프트(drift)가 발생하거나 오작동할 수 있습니다. 행동과 함께 컨텍스트 크기를 기록하십시오.

그리고 메모리는 이를 지속시킵니다

만약 에이전트가 메모리(memory)를 가지고 있다면, 단 한 번의 인젝션(one-shot injection)이 지속적인 인젝션이 될 수 있습니다. 즉, 오염된 "사실"이 한 번 기록되면 매 세션마다 재실행됩니다. 메모리를 위생적으로 관리하십시오: 인스턴스나 유형별로 범위를 제한(scope)하고, 기록되는 내용을 검증하며, 특정 "사실"이 어디에서 왔는지 추적할 수 있도록 항목별 출처(provenance)를 유지하십시오.

이 중 그 어떤 것도 프롬프트 인젝션(prompt injection) 자체를 방지하지는 못합니다. 이는 인젝션이 성공했다는 것을 가정하고, 그 다음 단계에서 시스템이 무엇을 해야 하는지를 묻는 것입니다. 구조화된 버전을 원하신다면 BRACE 런타임 가이드에서 이러한 사항들을 체크리스트 형태로 살펴볼 수 있습니다.

자, 솔직한 질문을 던져보겠습니다: 만약 지금 당장 당신의 에이전트가 작업 도중에 하이재킹(hijacked)된다면, 당신은 이를 액션 스트림(action stream)에서 확인할 수 있습니까? 아니면 프롬프트 이후의 모든 상황에 대해 눈을 가린 채 비행하고 있습니까? 당신의 행동 베이스라인(behavioral baseline)은 실제로 어떤 모습입니까?