LLM 접근 제어는 요청 경로의 어디에 위치해야 하는가

질문 뒤에 숨겨진 질문

LLM 접근 제어 및 모니터링에 대한 모범 사례를 찾는 팀들은 보통 이미 작동하는 에이전트를 보유하고 있습니다. 이 에이전트는 도구(tools)를 호출합니다. 그리고 그 도구들은 작동합니다. 문제는 통제를 추가할지 여부가 아니라, 그 통제가 어디에 위치해야 하는지, 그리고 그 위치가 통제 자체보다 왜 더 중요한지에 관한 것입니다.

이는 아키텍처 문제입니다. 배치를 올바르게 하면 나머지 체크리스트는 기계적인 과정이 됩니다. 잘못하면 추가하는 모든 통제는 자문(advisory)에 불과합니다.

AI 에이전트 보안이 다루는 것

AI 에이전트 보안은 자율적이거나 반자율적인 시스템이 보유한 자격 증명(credentials) 및 도구로 무엇을 할 수 있는지 제약하는 학문입니다. 이것은 프롬프트 엔지니어링(prompt engineering)이 아닙니다. 콘텐츠 필터링도 아닙니다. 이는 다른 모든 특권 워크로드와 동일한 문제입니다. 즉, 하나의 신원(identity)이 리소스에 대해 작용하고, 그 신원과 리소스 사이에 있는 무언가가 해당 행동이 허용되는지 결정하는 것입니다.

차이점은 신원이 모델이라는 것, 행동이 런타임(runtime)에 선택된다는 것, 그리고 리소스가 종종 예측 불가능한 호출자(caller)를 위해 설계된 적이 없는 내부 API라는 점입니다.

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

세 가지 도구(티켓 리더기, 레포지토리 라이터, HTTP 페처)를 가진 에이전트를 고려해 봅시다. 각 도구는 자격 증명을 보유합니다. 각 자격 증명은 설정 시 한 번 발급되었으며, 특정 작업에 대해 범위가 지정된 적이 없습니다.

세 가지 실패 모드가 뒤따릅니다.

첫째, 너무 광범위한 범위(over-broad scope). 레포지토리 라이터는 토큰이 도달할 수 있는 모든 리포지토리의 모든 브랜치에 푸시할 수 있습니다. 왜냐하면 이 토큰은 전체 조직을 위해 발급되었기 때문입니다. 에이전트는 단 하나의 리포지토리만 필요했습니다.

둘째, 만료 기한 없음(no expiry). 자격 증명이 작업보다 오래 지속됩니다. 4분 동안 실행된 세션은 누군가 회전시키기 전까지 유효한 토큰을 남깁니다.

셋째, 결정 로그 부재(no decision log). 에이전트가 신뢰할 수 없는 입력으로부터 구성한 URL로 HTTP 페처를 호출할 때, 어떤 에이전트 신원이 이 호출을 했는지, 어떤 범위 하에서 했는지, 그리고 그 범위가 이 작업에 의도된 것이었는지를 기록하는 것이 아무것도 없습니다. 이러한 기록 없이는 무슨 일이 일어났는지 답할 방법이 없습니다.

이러한 것들 중 어느 것도 공격자가 교묘할 필요를 요구하지 않습니다. 단지 에이전트가 유용해야 할 뿐이며, 실제로 그렇습니다.

이를 막는 메커니즘

제어는 요청 경로(request path)에, 에이전트 런타임과 도구 사이(between the agent runtime and the tool)에 위치해야 합니다. 시스템 프롬프트(system prompt)가 아니며, 정책 문서도 아니고, 검토 프로세스도 아닙니다.

순서가 중요합니다:

1. 에이전트의 신원(identity)을 확인합니다. 모든 호출은 공유 서비스 계정(shared service account)이 아닌 안정적인 신원을 가집니다.
2. 요청된 범위(scope)를 확인합니다. 호출은 단순히 어떤 도구를 원하는지뿐만 아니라, 무엇을 하고 싶은지를 선언합니다.
3. 권한을 검사합니다. 해당 신원이 이 작업을 위해 그 범위를 가지고 있거나 그렇지 않습니다.
4. 결정을 기록합니다. 신원, 범위, 도구, 시간과 함께 허용 또는 거부를 합니다.
5. 실행하거나, 에이전트가 처리할 수 있는 거부 응답을 반환합니다.

만약 1단계가 누락되면, 모든 후속 검사는 익명(anonymous)입니다. 만약 2단계가 누락되면, 행동 접근(action access)을 확인하는 것이 아니라 도구 접근만을 확인하게 되며, 이는 아무것도 확인하지 않는 것과 같습니다. 만약 4단계가 누락되면, 관찰 가능성(observability) 없이 강제만 하게 되어 볼 수 없는 것을 강화할 수 없습니다.

이것이 프롬프트보다는 요청 경로에 속하는 이유는, 프롬프트는 모델 입력이기 때문입니다. 모델 입력은 조언적(advisory)입니다. 범위 내에 머물도록 지시받은 모델이라도 그 범위를 벗어난 호출을 구성할 수 있으며, 그 호출과 도구 사이에는 아무것도 없습니다. 요청 경로에서의 검사는 조언이 아닙니다. 그것은 게이트(gate)입니다.

모니터링이 다른 절반입니다

모니터링 없이 강제만 하는 것은 설명할 수 없는 거부와 안전하게 제거할 수 없는 권한을 낳습니다.

유용한 로그 항목은 작습니다: 에이전트 신원, 요청된 범위, 도구, 결정, 타임스탬프. 이를 통해 운영적으로 중요한 세 가지 질문에 답할 수 있습니다.

어떤 범위가 사용되지 않는가? 그것들은 제거 후보입니다.

어떤 신원이 평소의 집합을 벗어난 범위를 요청하는가? 그것들은 검토 후보입니다.

어떤 거부가 한 도구 주변에 집중되는가? 그 도구는 잘못 구성되었거나(misconfigured) 테스트되고 있는 것입니다.

한 번도 사용되지 않은 권한은 삭제할 수 있는 권한입니다. 이것이 로깅의 핵심 목적입니다. 최소 권한 원칙(least privilege)을 일회성 설계 결정에서 지속적으로 실행할 수 있는 루프로 전환하는 것입니다.

RESK를 이용한 구현

reskSecure는 요청 경로 검사를 강제합니다. 에이전트 신원(Agent identity), 범위 해석(scope resolution), 권한 결정(permission decision), 그리고 결정 기록(decision record)은 런타임과 도구 사이에 위치하므로, 범위를 벗어난 호출은 도구에 도달하지 못합니다.

ReskPoints는 이러한 결정들에 대한 가시성 계층을 제공합니다. 어떤 범위가 사용되었는지, 어떤 신원이 무엇을 요청하는지, 그리고 거부가 어디에 집중되는지를 파악할 수 있게 하여, 권한 집합을 설정 시의 추측이 아닌 실제 트래픽을 기반으로 강화할 수 있습니다.

이 둘은 문제의 두 절반, 즉 게이트(gate)와 기록(record)을 다룹니다. 강제 적용(Enforcement)은 호출을 막습니다. 기록은 다음에 무엇을 변경해야 하는지 알려줍니다.

만약 광범위한 자격 증명(broad credentials)을 이미 보유한 에이전트부터 시작한다면, 실질적인 순서는 먼저 게이트를 설치하고, 일정 기간 동안 관찰한 다음, 기록에 사용되지 않는 범위들을 제거하는 것입니다.

체크리스트

• 모든 에이전트 호출은 공유 서비스 계정이 아닌 고유한 신원을 가집니다.
• 모든 호출은 범위를 선언하며, 도구가 실행되기 전에 해당 범위가 검사됩니다.
• 권한 검사는 프롬프트나 문서에 있는 것이 아니라 요청 경로에 위치합니다.
• 모든 허용(allow) 및 모든 거부(deny)는 신원, 범위, 도구, 시간과 함께 기록됩니다.
• 사용되지 않은 범위는 주기적으로 제거됩니다.
• 거부는 검토되어야 합니다. 왜냐하면 그 클러스터가 하나의 신호이기 때문입니다.
• 자격 증명은 만료되며, 만료 시점은 순환 일정(rotation calendar)이 아닌 작업에 연결됩니다.

도구 권한이 에이전트별로 어떻게 범위 지정되는지에 대한 관련 질문은 AI agent tool permissions 기사를 참조하십시오.

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