LLM 접근 제어 및 모니터링 구현을 위한 모범 사례

엔지니어들이 실제로 던지는 질문

팀이 LLM 기능을 출시할 때, 첫 번째 검토 질문은 보통 프롬프트 품질에 관한 것입니다. 두 번째, 더 조용한 질문은 접근성에 관한 것입니다. 누가 모델을 호출할 수 있는지, 어떤 컨텍스트를 가지고 호출하는지, 그리고 모델이 대신 도구(tool)를 호출하기로 결정했을 때 무슨 일이 발생하는지에 대한 문제입니다.

본 기사는 이 두 번째 질문에 답합니다. 본 글은 독자들이 이미 LLM 애플리케이션 구축 방식에 대해 충분히 이해하고 있다고 가정하며, 접근 제어는 어디에 속해야 하는지 그리고 어떻게 모니터링할지에 초점을 맞춥니다.

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

AI 에이전트 보안은 자율적이거나 반자율적인 LLM 시스템이 '무엇을 말할 수 있는지'뿐만 아니라 '무엇을 할 수 있는지'를 제약하는 학문입니다. 텍스트를 반환하는 챗봇은 작은 피해 범위(blast radius)를 가집니다. 파일을 읽고, API를 호출하고, 메시지를 보내거나, 레코드를 수정할 수 있는 에이전트는 더 큰 피해 범위를 가집니다.

이 구분이 중요한 이유는 제어 표면(control surface)이 다르기 때문입니다. 텍스트 전용 모델의 경우, 주로 입력 및 출력 필터링에 신경을 씁니다. 하지만 에이전트의 경우, 그것이 수행하는 모든 도구 호출에 걸쳐 신원(identity), 권한 부여(authorization), 범위(scope), 그리고 감사 가능성(auditability)에 신경 써야 합니다.

공격 표면(Attack Surface), 구체적으로

에이전트는 일반적으로 다음과 같은 요청 경로에 위치합니다:

1. 사용자 또는 시스템이 요청을 보냅니다.
2. 에이전트가 컨텍스트를 조립하는데, 여기에는 검색된 문서나 도구 출력이 포함되는 경우가 많습니다.
3. 모델이 계획(plan)이나 도구 호출을 생성합니다.
4. 도구가 에이전트가 보유한 어떤 자격 증명(credentials)으로 실행됩니다.

문제가 발생하는 지점은 2단계와 4단계입니다. 검색된 콘텐츠는 신뢰할 수 없는 입력입니다. 만약 문서에 지침이 포함되어 있다면, 모델은 이를 합법적인 것으로 간주할 수 있습니다. 이것이 바로 프롬프트 인젝션(prompt injection)이며, 이는 이론적인 문제가 아닙니다. 외부 콘텐츠를 읽고 특권화된 도구 토큰을 보유하는 모든 에이전트는 노출됩니다.

실패 모드는 모델 자체가 악의적이라는 것이 아닙니다. 실패 모드는 모델이 잘못된 지침에 순종하고, 그 결과 생성된 도구 호출이 특정 사용자 및 작업과 비교하여 아무것도 확인하지 않았기 때문에 권한을 얻는 경우입니다.

이를 막는 메커니즘

LLM 시스템의 접근 제어는 모델 외부, 즉 모든 액션의 경계에서 강제될 때 작동합니다.

순서가 중요한 부분입니다:

• 호출자 인증 (Authenticate the caller). 모든 요청은 사용자, 서비스 또는 다른 에이전트인 신원을 담고 있습니다.
• 액션 권한 부여 (Authorize the action). 도구가 실행되기 전에, 해당 신원과 작업에 대한 정책을 기준으로 요청된 작업을 확인합니다.
• 최소 권한으로 실행 (Execute with least privilege). 도구 자격 증명은 에이전트가 할 수 있는 모든 것의 합집합이 아니라, 이 호출에 필요한 범위만을 부여해야 합니다.
• 결정 기록 (Record the decision). 모니터링은 허용된 호출, 거부된 호출, 시도된 호출을 신원 및 적용된 정책과 함께 포착해야 합니다.

만약 실행 후에 권한을 부여한다면, 이는 침해를 방지하는 것이 아니라 침해의 감사 추적(audit trail)을 생성하는 것입니다. 만약 프롬프트 내부에서 권한을 부여한다면, 모델에게 스스로 감시하도록 요청하는 것인데, 이는 프롬프트 인젝션이 정확히 무력화시키는 속성입니다.

모니터링도 동일한 논리를 따릅니다. 모델 출력을 로깅하는 것은 모니터링이 아닙니다. 모니터링은 권한 부여 결정, 사용된 범위, 그리고 결과를 기록하여 어떤 에이전트가 어떤 사용자 대신 어떤 도구를 호출했는지, 그리고 그것이 허용되었는지를 답변할 수 있게 하는 것입니다.

RESK를 이용한 구현

RESK는 이 패턴을 위한 강제 및 가시성 계층(enforcement and visibility layer)을 제공합니다.

reskSecure는 에이전트와 그 도구 호출에 최소 권한을 강제합니다. 이는 요청 경로에 위치하여, 호출자를 인증하고 실행 전에 각 액션을 정책과 비교하며 확인하기 때문에, 가로채기되거나 잘못 전달된 호출은 나중에 기록되는 것이 아니라 거부됩니다.

ReskPoints는 모니터링 측면을 제공합니다: 권한 부여 결정 및 에이전트 활동의 기록으로, 무엇이 허용되었고, 무엇이 거부되었으며, 어느 범위가 필요 이상으로 넓은지 볼 수 있게 합니다.

이 두 가지가 함께 문제의 양쪽 절반을 다룹니다: 경계에서의 예방과 그 이후의 증거입니다.

에이전트에게 최소 권한을 강제하세요: https://resk.fr/projects/resksecure.html

에이전트별 도구 권한을 어떻게 범위 지정할지에 대한 관련 주제는 AI 에이전트 도구 권한(AI agent tool permissions) 기사를 참고하세요.

체크리스트

• 모델에 대한 모든 요청에는 신원이 부여됩니다.
• 모든 도구 호출은 실행된 후가 아니라, 사전에 승인됩니다.
• 도구 자격 증명(credentials)은 특정 작업을 위한 최소한의 범위를 부여합니다.
• 검색된 콘텐츠는 신뢰할 수 없는 입력으로 취급되며, 절대 지침으로 간주되지 않습니다.
• 승인 결정은 신원, 범위, 결과와 함께 기록됩니다.
• 거부되거나 시도된 호출은 조용히 무시되지 않고 가시적입니다.
• 에이전트가 더 이상 필요하지 않은 권한을 축적하지 않도록 범위를 정기적으로 검토합니다.

LLM 시스템의 접근 제어는 프롬프트 문제가 아닙니다. 이는 요청 경로 문제입니다. 그리고 다른 모든 특권 시스템에서 해결하는 방식과 동일하게 해결됩니다: 인증(authenticate), 승인(authorize), 최소 권한으로 실행(execute with least privilege)하고, 결정을 기록합니다.