LLM 접근 제어 및 모니터링: 검증은 실제로 어디에 위치해야 하는가

질문

LLM 접근 제어(access controls)와 모니터링(monitoring)의 모범 사례를 찾는 팀들은 보통 이미 모델을 배포하고 그 모델에 연결된 도구들을 가지고 있습니다. 문제는 통제를 추가할지 여부가 아닙니다. 문제는 그 통제가 어디에 위치해야 하는지, 그리고 그 통제가 신뢰받기 위해 무엇을 기록해야 하는가입니다.

이 글은 공격자(attack side)의 관점에서 이 질문에 답합니다. 공격이 특별해서가 아니라, 실패 모드(failure modes) 자체가 경계가 정확히 어디에 위치해야 하는지를 알려주기 때문입니다.

AI 에이전트 보안이 다루는 범위

AI 에이전트 보안은 자율적이거나 반자율적인 시스템이 주어진 도구들로 무엇을 할 수 있는지 제약하고, 실제로 무엇을 했는지 관찰하는 실천입니다.

여기에는 서로 선택적이지 않은 두 가지 절반이 있습니다:

강제(Enforcement). 어떤 도구 호출이, 어떤 에이전트에 의해, 어떤 리소스에 대해, 어떤 조건 하에서 허용되는지.
관찰(Observation). 시도된 것과 성공한 것에 대한 영속적인 기록으로, 사건을 재구성하기에 충분해야 합니다.

강제는 있지만 관찰이 없는 시스템은 감사(audit)할 수 없습니다. 관찰은 있지만 강제가 없는 시스템은 매우 잘 문서화된 보안 침해입니다.

공격 표면, 구체적으로

흥미로운 실패 사례들은 추상적인 프롬프트 주입(prompt injection)이 아닙니다. 그것들은 접근 가능하고 범위가 지정된 도구의 평범한 결과들입니다.

검색 도구를 고려해 봅시다. 이 도구는 테넌트 식별자(tenant identifier)와 쿼리(query)를 받습니다. 에이전트는 tenant A용으로 배포되었습니다. tenant A의 사용자가 에이전트가 tenant B를 식별자로 사용하여 해당 도구를 호출하도록 유발하는 입력을 만듭니다. 모델은 테넌시(tenancy) 개념을 가지고 있지 않습니다. 그 도구는 주어진 매개변수를 받아들입니다. 호출은 tenant B 데이터를 반환합니다.

이 과정의 어느 것도 정교한 익스플로잇(exploit)은 아닙니다. 탈옥(jailbreak)도 없고, 모델 가중치 유출(model weights exfiltration)도 없으며, 새로운 기술도 없습니다. 단지 매개변수와 그것을 신뢰하는 도구, 그리고 그 사이에 검증이 없는 것뿐입니다.

같은 형태가 다른 유형의 도구 전반에 걸쳐 반복됩니다:

모델이 제공하는 경로를 받는 쓰기 도구(write tool)입니다.
호출된 작업이 아닌, 실행되는 프로세스 자체에 범위가 있는 셸 또는 코드 실행 도구입니다.
배포 시 에이전트별로 범위를 지정하는 것이 미뤄져 모든 에이전트가 사용할 수 있도록 된 자격 증명(credential)을 보유한 도구입니다.

각 경우 모두 근본 원인은 동일합니다. 권한 부여 결정이 배포 시점에 한 번 이루어졌고, 호출 시점에는 재평가되지 않았기 때문입니다.

모델 계층에서 제어할 수 없는 이유

시스템 프롬프트에 제한을 두는 것이 매력적일 수 있습니다. 다른 테넌트(tenant)에 접근하지 마십시오. 작업과 관련된 도구만 사용하십시오.

하지만 이것은 통제가 아닙니다. 확률적인 시스템에 대한 제안일 뿐입니다. 천 번의 호출 동안 유효할 수도 있지만, 만 번째 호출에서 실패할 수 있으며, 경계가 무너졌다는 신호조차 받지 못하게 됩니다.

접근 제어는 결정론적(deterministic)이어야 합니다. 즉, 자신이 제한하려는 행위의 동작을 하는 컴포넌트 안에 존재해서는 안 됩니다.

이를 막는 메커니즘

이 검사는 도구 경계(tool boundary), 즉 에이전트와 도구 구현 사이의 요청 경로에서 호출마다 평가되어야 합니다.

순서가 중요합니다:

에이전트가 인자(argument)를 포함한 도구 호출을 방출합니다.
도구가 실행되기 전에 해당 호출을 가로챕니다(intercept).
호출자 신원, 도구 신원, 그리고 인자를 정책과 비교하여 평가합니다.
결정 사항이 기록됩니다.
그 후에야 비로소 도구가 실행되거나, 호출이 거부됩니다.

3단계가 핵심입니다. 인자는 단순히 호출자뿐만 아니라 권한 부여 입력(authorization input)의 일부입니다. read_document에 대한 도구 호출은 본질적으로 허용되거나 거부되는 것이 아닙니다. 어떤 문서인지, 어떤 에이전트가, 누구를 대신하여 요청하는지에 따라 달라집니다.

4단계는 3단계를 감사 가능(auditable)하게 만드는 요소입니다. 만약 결정 사항이 인자와 함께 기록되지 않는다면, 나중에 경계가 유지되었는지 여부를 답변할 수 없습니다.

이것이 세션별 권한 부여(per session authorization)가 불충분한 이유이기도 합니다. 에이전트 세션은 여러 작업을 거치고 여러 리소스를 사용할 수 있습니다. 세션 범위로 제한된 권한 부여는 해당 세션이 접촉하게 될 모든 것에 대한 권한을 의미합니다.

구체적인 실패 사례

에이전트에게 요약 작업과 검색 도구(retrieval tool)가 주어집니다. 이 도구는 문서가 저장된 곳인 프로덕션 문서 스토어(production document store)에 배포 시 범위가 설정되었습니다.

다른 팀을 위한 두 번째 에이전트에게도 동일한 도구가 제공됩니다. 이는 도구 레지스트리(tool registry)가 공유되고, 에이전트별 범위 지정은 로드맵 상의 과제였기 때문입니다.

두 번째 에이전트는 해당 에이전트에 합법적인 접근 권한을 가진 사용자로부터 프롬프트를 받아 사용자가 볼 수 없는 문서를 검색하도록 지시받습니다. 검색은 성공하고, 요약도 성공하며, 결과물이 반환됩니다.

어떤 경보도 울리지 않습니다. 왜냐하면 위반할 호출별 정책(per call policy)이 없고 검사할 호출별 로그(per call log)가 없었기 때문입니다. 이 사고는 시스템이 호출을 감지했을 때가 아니라, 누군가가 그 내용을 알아차렸을 때 발견됩니다.

완화 방안

중요도 순으로 세 가지 속성이 있습니다:

배포 단위가 아닌 에이전트별 최소 권한(Least privilege per agent, not per deployment). 각 에이전트는 자신의 작업에 필요한 가장 좁은 도구 세트와 가장 좁은 인자 범위(argument scope)를 갖게 됩니다. 만약 에이전트가 쓰기 도구가 필요하지 않다면, 해당 도구를 가지지 않습니다.

인자를 포함한 호출 시점의 권한 부여(Authorization at call time, with arguments in scope). 정책은 호출자(caller), 도구(tool), 그리고 인자를 함께 평가합니다. 도구 호출은 영구적인 허가(standing permission)가 아니라 요청입니다.

취소할 수 있는 충분한 컨텍스트를 갖춘 호출별 로깅(Per call logging with enough context to revoke). 에이전트의 신원, 도구, 인자, 결정, 그리고 결과를 기록합니다. 만약 어떤 에이전트가 무엇을 건드렸는지 이름을 붙일 수 없다면, 그것을 자신 있게 취소할 수 없습니다.

RESK를 사용한 구현

reskSecure는 도구 경계(tool boundary)에서 강제 실행 지점(enforcement point)을 제공합니다. 정책은 인자를 포함하여 호출별로 평가되므로, 검색 호출은 일반적인 도구가 아닌 해당이 명시하는 특정 리소스에 대해 승인됩니다. 거부와 허가는 결정되는 즉시 기록됩니다.

ReskPoints는 관찰(observation) 측면을 제공합니다. 툴 호출과 그 결과가 포착되므로, 어떤 에이전트가 어떤 리소스를 건드렸는지에 대한 질문에 수동으로 로그를 재구성할 필요 없이 답할 수 있습니다.

이 둘은 위에서 설명된 두 절반, 즉 모델 외부에 위치하여 결정론적인 강제(enforcement)와 조치하기에 충분히 완벽한 관찰(observation)을 포괄합니다.

에이전트에 최소 권한(least privilege)을 적용하세요: https://resk.fr/projects/resksecure.html

에이전트별 툴 권한은 어떻게 구성해야 하는지에 대한 관련 질문은 AI 에이전트 툴 권한(AI agent tool permissions)을 참고하세요.

체크리스트

모든 툴 호출은 툴이 실행되기 전에 가로채집니다(intercepted).
인가(Authorization)는 호출자, 툴, 그리고 인수를 함께 평가합니다.
인가는 세션별이나 배포 시점이 아닌, 호출(call) 단위로 평가됩니다.
각 에이전트는 자신의 작업에 필요한 가장 좁은 범위의 툴 세트를 보유합니다.
인수 범위가 단순히 툴 가용성뿐만 아니라 제약됩니다.
모든 결정(permit 및 deny)은 그 인수를 포함하여 기록됩니다.
로그는 어떤 에이전트가 어떤 리소스를 건드렸는지 답하기에 충분합니다.
원시 로그에서 상태를 재구성할 필요 없이 취소(Revocation)가 가능합니다.
어떤 인가 결정도 모델이 지침을 따르는 것에 의존하지 않습니다.