LLM 접근 제어 및 모니터링: 요청 경로의 어느 지점에 검증 로직을 배치해야 하는가

질문

팀들은 LLM(대규모 언어 모델) 접근 제어 및 모니터링 구현에 대한 모범 사례를 문의합니다. 일반적인 답변으로는 프롬프트, 시스템 메시지, 그리고 가드레일 모델에 관한 것입니다. 이들은 유용하지만, 그것들은 접근 제어는 아닙니다. 접근 제어란 특정 주체(principal)가 자원(resource)에 대해 어떤 행동을 수행할 수 있는지 여부에 대한 결정입니다. 만약 그 결정이 모델이 읽는 텍스트로만 표현된다면, 모델은 그 결정에서 벗어나도록 유도될 수 있습니다.

본 기사는 아키텍처에 관한 것입니다. 즉, 제어 로직이 요청 경로의 어느 지점에 속해야 하는지, 그리고 왜 그 배치가 정책(policy)과 단순한 제안(suggestion) 사이의 차이를 만드는지에 대한 내용입니다.

여기서 AI 에이전트 보안이란 무엇을 의미하는가

AI 에이전트 보안은 자율적이거나 반자율적인 시스템이 부여받은 자격 증명(credentials)과 도구(tools)로 무엇을 할 수 있는지 제약하는 학문입니다. 모델은 그 구성 요소 중 하나일 뿐입니다. 에이전트는 전체 루프, 즉 모델 출력, 도구 선택, 도구 실행, 관찰, 그리고 다음 턴으로 이루어집니다.

바로 이 루프 때문에 에이전트 보안은 모델 보안과 다릅니다. 잘못된 문장을 생성하는 모델은 당황스러운 실수에 불과합니다. 하지만 잘못된 도구 호출을 하는 에이전트는 부작용(side effect)입니다. 즉, 행(row)이 기록되거나, 메시지가 전송되거나, 파일이 읽히거나, 결제가 시작되는 등의 실제 행동으로 이어집니다. 피해 범위(blast radius)는 토큰(tokens)에 있는 것이 아니라 도구(tools)에 있습니다.

공격 표면을 구체적으로 고려하기

세 가지 도구를 가진 지원 에이전트를 가정해 봅시다: 고객 기록 읽기, 환불 처리, 이메일 전송. 이 에이전트는 세 가지 기능을 모두 수행할 수 있는 단일 서비스 자격 증명으로 실행됩니다.

공격자는 모델을 해킹할 필요가 없습니다. 그들이 필요한 것은 모델이 지침(instruction)으로 취급하는 컨텍스트에 텍스트를 주입하는 것입니다. 이 텍스트는 검색된 문서, 티켓 본문, 에이전트가 가져오는 웹 페이지, 또는 이전 도구 결과 등을 통해 도착할 수 있습니다. 일단 컨텍스트 안에 들어가면, 모델은 공격자가 선택한 금액으로 환불 도구를 선택할 수도 있습니다.

이 경로의 어떤 부분도 낯설지 않습니다. 실패는 구조적인 문제입니다. 즉, 에이전트가 보유한 자격 증명이 수행하는 작업보다 너무 광범위하고, 도구 호출을 결정하는 주체가 신뢰할 수 없는 입력에 의해 영향을 받을 수 있는 바로 그 구성 요소와 동일하기 때문입니다.

두 번째 실패 모드는 순서(ordering) 문제입니다. 많은 구현체들이 도구 호출이 전송된 후에 검증을 수행하거나, 해결된 도구 호출 자체가 아닌 텍스트로서의 모델 출력을 검증합니다. 검사가 실행될 무렵에는 이미 부작용(side effect)이 발생한 상태입니다. 이 경우 로깅은 결정(decision)이 아니라 결과(outcome)를 기록하게 되어 사고 상황을 재구성하기 어렵게 만듭니다.

이를 막는 메커니즘

제어는 모델과 도구 실행기(tool executor) 사이의 경계에 있어야 합니다. 구체적으로, 요청 경로는 다음과 같아야 합니다:

1. 모델이 구조화된 도구 호출을 방출합니다.
2. 호출은 전송되기 전에 가로채집니다(intercepted).
3. 호출은 주체(principal), 도구(tool), 그리고 리소스 범위(resource scope)로 해결됩니다.
4. 해당 주체와 범위에 대해 정책 결정이 이루어집니다.
5. 허용(allow)만 실행기에게 전달됩니다. 거부(deny)는 에이전트 루프(agent loop)에 유형화된 오류를 반환합니다.
6. 결정, 인자(arguments), 그리고 결과가 동일한 경계에서 기록됩니다.

두 가지 속성이 중요합니다. 첫째, 결정은 모델 외부에서 이루어지므로 신뢰할 수 없는 컨텍스트가 이를 재작성할 수 없습니다. 둘째, 결정이 실행 전에 발생하므로 거부(deny)가 되돌릴 부작용을 갖지 않습니다.

범위 지정(Scoping)도 또 다른 절반입니다. 모든 것을 할 수 있는 하나의 자격 증명(credential) 대신, 각 도구 호출은 작업을 만족시키는 가장 좁은 범위에 대해 평가됩니다. 환불 도구 호출은 금액과 고객 식별자를 포함하며, 정책은 이 둘 모두를 제한할 수 있습니다. 읽기 도구 호출은 레코드 식별자를 포함하며, 정책은 이 주체에게 보이는 레코드를 제한할 수 있습니다.

모니터링도 동일한 경계를 따릅니다. 유용한 신호는 최종 답변 텍스트가 아닙니다. 그것은 도구 호출의 순서, 각 호출의 주체, 결정, 그리고 인자입니다. 이것이 사고 발생 후 어떤 호출이 허용되었고, 어떤 것이 거부되었으며, 무엇이 변경되었는지 알려줄 수 있는 것입니다.

RESK를 사용한 구현

reskSecure는 이 경계에 대한 강제 지점(enforcement point)입니다. 이는 에이전트와 도구 실행기 사이에 위치하며, 각 도구 호출을 주체(principal)와 범위(scope)로 해석하고, 전송하기 전에 허용(allow) 또는 거부(deny)를 반환합니다. 이 검사가 모델 외부에서 이루어지므로, 모델이 지침을 따르는지에 의존하지 않습니다.

ReskPoints는 동일한 경계에 있는 관찰 가능성 계층(observability layer)입니다. 이는 도구 호출, 결정 사항, 그리고 인수를 기록하여, 모니터링 뷰가 에이전트가 보고한 내용이 아닌 실제로 시도했던 내용을 반영하도록 합니다.

실질적인 효과는 강제되는 최소 권한 원칙(least privilege)입니다. 에이전트에게 좁은 범위만 부여하고, 거부된 사례를 관찰하며, 증거가 뒷받침하는 곳에서만 범위를 넓힐 수 있습니다. 이는 광범위한 접근을 허용하고 프롬프트가 유지되기를 바라는 것과는 다른 자세입니다.

도구 권한이 어떻게 모델링되는지에 대한 관련 질문은 AI 에이전트 도구 권한(AI agent tool permissions) 기사를 참조하십시오.

체크리스트

• 에이전트가 호출할 수 있는 모든 도구와 그 뒤의 자격 증명(credential)을 식별합니다.
• 권한 부여 결정을 모델 출력과 도구 전송 사이의 경계로 이동시킵니다.
• 실행 전에 각 도구 호출을 주체, 도구, 그리고 리소스 범위로 해석합니다.
• 기본적으로 거부(Deny by default)하고, 거부 시 에이전트 루프에 형식화된 오류를 반환합니다.
• 도구가 리소스 식별자나 양을 받는 경우, 단순히 도구 이름뿐만 아니라 인수를 제한합니다.
• 결정 사항, 인수, 그리고 결과를 동일한 경계에서 기록합니다.
• 거부 사례를 정기적으로 검토하고 증거가 있을 때만 범위를 넓힙니다.
• 검색된 콘텐츠와 도구 결과는 루프에 대한 신뢰할 수 없는 입력(untrusted input)으로 취급합니다.

reskSecure를 사용하여 에이전트의 최소 권한 원칙을 강제하십시오.