AI 에이전트의 권한을 결정하기 위해 LLM을 사용하지 마세요

저는 AARM이라는 그룹에 속해 있습니다. 이 그룹은 AI 에이전트가 실행될 때 실제로 무엇을 할 수 있는지 어떻게 보안을 유지할 것인가를 연구하는 사람들의 모임입니다. 기본 아이디어는 제어(control)가 바로 실행(action) 단계에 위치해야 한다는 것입니다. 도구 호출(tool call)이 실행되기 전에 확인해야 하며, 에이전트는 그 확인 과정을 우회할 수 없어야 합니다. 따라서 이 그룹의 모든 구성원은 에이전트에게 "제발 하지 마세요"라고 말하는 것이 보안 모델이 아니라는 점에 이미 동의하고 있습니다.

제가 의아하게 생각하는 점은, 그 방 안에서조차 사람들이 결정을 내리는 주체로 LLM을 활용하려는 모습을 계속 본다는 것입니다. 에이전트가 무언가를 하려고 할 때, 그 동작을 가로채서 두 번째 모델에게 전달한 뒤 괜찮은지 묻고, 그 모델이 대답하는 대로 실행하는 방식입니다. 모델이 모델을 감시하는 셈이죠. 저는 정말 이해가 가지 않으며, 왜 그런지 그 이유를 짚어보고 싶습니다. 사람들이 이 방식이 실제로 무엇을 가져다주는지에 대해 깊이 고민하지 않은 채 의존하고 있다고 생각하기 때문입니다.

당신이 실제로 방어하려는 것

애초에 왜 에이전트에 가드레일(guard)을 설치하려고 하는지 그 이유로 돌아가 봅시다. 에이전트가 설득당할 수 있기 때문입니다. 에이전트가 읽는 페이지에 숨겨진 프롬프트 인젝션 (prompt injection), 조용히 새로운 지침을 전달하는 도구 결과 (tool result), 혹은 교묘하게 요청을 구성하는 사용자 등이 있을 수 있습니다. 에이전트는 당신이 논리적으로 대화할 수 있는 대상이며, 문제는 잘못된 사람이 에이전트와 논리적으로 대화할 수 있다는 점입니다.

이제 LLM-판사 (LLM-judge) 설정이 이에 대해 무엇을 하는지 살펴보십시오. 그것은 첫 번째 대상 앞에 당신이 논리적으로 대화할 수 있는 두 번째 대상을 배치하는 것입니다. 이 부분이 제가 막히는 지점입니다. 왜냐하면 그것은 단지 다른 모자를 쓰고 있는 동일한 약점이기 때문입니다. 누군가가 에이전트를 휘두를 수 있는 입력을 만들어낼 수 있다면, 판사 또한 동일한 종류의 압력에 반응하는 동일한 종류의 시스템이기 때문에 똑같은 종류의 입력에 휘둘릴 실질적인 가능성이 있습니다.

어쩌면 통할 수도 있습니다. 판사에게 더 주의 깊게 프롬프트를 작성하여 압박에 더 강하게 만들었을 수도 있습니다. 하지만 "설득당하기 더 어렵다"는 것은, 설득당하지 않게 만드는 것이 바로 이 계층을 고용한 목적 전체일 때, 의존하기에는 매우 이상한 기준입니다.

같은 질문, 다른 답변

두 번째 문제가 있으며, 일상적인 관점에서 보면 이것이 실제로 저를 괴롭히는 문제입니다. 모델에게 같은 질문을 두 번 던졌을 때 서로 다른 두 가지 답변을 얻을 수 있다는 점입니다. 이것은 패치로 해결할 수 있는 버그가 아니라, 그 자체의 특성입니다. 바로 샘플링 (sampling)입니다. 동일한 입력 (input)을 줄 때마다 매번 동일한 출력 (output)을 반환하는 함수 (function)가 아닙니다.

우리가 만드는 대부분의 것들에 있어서 이는 완전히 괜찮으며, 솔직히 말하면 모델이 유용한 이유 중 하나이기도 합니다. 하지만 질문이 '에이전트가 운영 데이터베이스 (production database)를 삭제해도 되는가'와 같은 것이 되는 순간, 그 특성은 실질적인 부채 (liability)로 변합니다. 동일한 작업이 화요일에는 통과되고 수요일에는 차단될 수 있으며, 그 이유를 실제로 지목할 수 있는 근거도 없습니다. 왜냐하면 근거라는 것이 존재하지 않기 때문입니다. 그저 주사위가 다르게 던져졌을 뿐입니다. 감사관 (auditor)을 위해 이를 문서화하거나, 새벽 2시에 무언가 잘못 통과된 이유를 파악하려 할 때 스스로에게 이를 설명하는 일은 매우 어려울 것입니다.

규칙 (rule)은 그렇게 작동하지 않습니다. deny delete on production은 예외 없이 매번, 단 한 번도 빠짐없이 운영 데이터베이스가 삭제되지 않음을 의미합니다. 규칙을 읽을 수 있고, 테스트할 수 있으며, 6개월 후에 로그 (log)를 확인하여 정확히 무엇이 요청되었고 무엇이 반환되었는지 확인할 수 있습니다. 결정은 당신이 실제로 책임질 수 있는 것이며, 이것이 바로 규칙이 신뢰할 수 있는 부분이 될 수 있는 이유 전체입니다.

이것은 LLM에 반대하는 논거가 아닙니다

여기서 주의를 기울이고 싶습니다. 왜냐하면 이 논리를 너무 과하게 확장하기 쉽기 때문이며, 모델이 보안 근처에는 아예 발을 들여놓아서는 안 된다는 식의 버전 또한 틀린 말이기 때문입니다.

모델은 이러한 작업 중 많은 것들을 아주 잘 수행합니다. 어떤 동작을 보고 무언가 잘못되었다는 것을 알아차리는 것, 특정 텍스트가 민감하다고 알려주는 것, 무언가가 얼마나 위험해 보이는지에 대해 대략적인 점수를 매기는 것, 그리고 고정된 규칙으로는 절대 잡아낼 수 없었을 일련의 호출(calls) 과정에서 나타나는 패턴을 포착하는 것 등이 그러합니다. 이 모든 것은 실재하며, 그중 상당 부분에 대해 모델은 여러분이 가진 최고의 도구입니다. 문제는 LLM이 보안 경계(security boundary) 근처에 있는 것이 아니었습니다. 문제는 LLM이 경계 그 자체가 되어, 최종적인 '예' 또는 '아니오'를 결정하는 주체가 되는 것입니다.

따라서 제가 내린 결론은 계층화(layered)된 접근 방식입니다. 모델이 진정으로 잘하는 소프트한 작업, 즉 이상한 점을 감시하고, 플래그(flag)를 표시하고, 여러분에게 확인해 보라고 알려주는 작업은 모델에게 맡기십시오. 다만, 모델이 문을 여는 주체가 되게 하지는 마십시오. 실제 동작을 실행할지 여부에 대한 최종 결정은 매번 동일한 답을 내놓을 수 있고 사후에 그 근거를 보여줄 수 있는 무언가에 기반해야 합니다. 모델은 그 과정에 얼마든지 기여할 수 있습니다. 다만 결정하는 주체가 될 수는 없습니다.

실제로 문제가 발생하는 지점

에이전트가 돈, 운영 환경(prod), 고객 데이터와 같이 중요한 요소에 가까워질수록, 이 모든 논의는 더 이상 이론적인 이야기가 아니게 됩니다. 만약 모델이 할 수 있는 최악의 일이 형편없는 문단을 작성하는 정도라면, 괜찮습니다. 이 문제로 밤잠을 설칠 필요는 없으며, 그 시간에 더 유용한 일을 하러 가셔도 좋습니다. 하지만 모델이 돈을 움직이거나 테이블(table)을 삭제할 수 있는 순간이 되면, 실행 허용 여부는 동전 던지기처럼 결정되어서는 안 되며, 애초에 보호하려고 했던 바로 그 시스템과 같은 종류의 시스템 내부에 존재해서도 안 됩니다.

똑똑하고 문맥을 파악하는(context-aware) 기능은 모델의 강점인 '무언가 잘못되었을 때 알아차리는 것'에 배치하십시오. 그리고 단호한 경계선은 에이전트가 말로써 빠져나갈 수 없는 곳에 두십시오.

그 마지막 부분이 제가 구축해 온 오픈 소스 프로젝트인 Faramesh의 핵심 사고방식입니다. 허가(permit)/거부(deny)/보류(defer) 결정은 결정론적(deterministic)이며, 그 경로에 모델이 개입하지 않으며, 모든 호출은 서명된 로그(signed log)에 기록됩니다. 하지만 이 도구 자체가 핵심은 아닙니다. 설령 여러분이 직접 이와 유사한 버전을 만든다 하더라도, 최종 결정권만큼은 모델로부터 분리하십시오. 그 부분은 의도적으로 지루해야 합니다.