AI 에이전트의 권한을 LLM에게 결정하게 해서는 안 되는 이유

만약 당신이 AI 에이전트가 무엇을 할 수 있고 무엇을 할 수 없는지에 대한 의사결정을 거대 언어 모델 (LLM)에게 맡긴 적이 있다면, 당신은 왕국의 열쇠를 통째로 넘겨주고 있는 것일지도 모릅니다. 프로덕션 시스템 (Production systems)에서 LLM은 인상적일 정도로 창의적일 수 있지만, 당신이 강제해야 하는 보안 정책을 이해하지는 못합니다. 이 글에서는 왜 절대로 LLM이 에이전트의 권한을 결정하게 해서는 안 되는지에 대한 실무적인 1인칭 관점의 설명과, 에이전트를 위한 가볍고 감사 가능한 (auditable) 권한 프레임워크를 구현하는 방법을 공유합니다.

문제점: LLM은 보안 게이트키퍼가 아니다

LLM은 다음 토큰을 예측하도록 훈련되었지, 위험을 평가하도록 훈련된 것이 아닙니다. 당신이 LLM에게 "사용자가 무엇을 할 수 있는지 파악해봐"라고 요청하면 그럴듯하게 들리는 답변을 얻겠지만, 모델은 최소 권한 원칙 (principle-of-least-privilege), 컴플라이언스 (compliance) 규칙, 또는 귀사의 내부 정책 계층 구조조차 인지하지 못합니다. 최근 진행한 내부 테스트에서 저는 Claude-3-Opus가 데이터 추출 에이전트의 권한 세트를 제안하도록 했습니다. 모델은 기꺼이 에이전트에게 스토리지 버킷 (storage bucket)에 대한 전체 관리자 권한을 부여했는데, 이는 엄청난 데이터 유출 (data-exfiltration) 표면을 열어주는 결과를 초래했을 것입니다.

현실 세계의 결과

권한 상승 (Privilege escalation) – LLM은 의도치 않게 읽기 전용 리소스에 쓰기 권한을 부여할 수 있습니다.
컴플라이언스 위반 (Compliance violations) – 모델이 법적 제약 사항을 이해하지 못하면 GDPR 스타일의 데이터 주체 요청을 무시할 수 있습니다.
예상치 못한 비용 – 제한 없는 네트워크 액세스를 허용하면 외부 API에서의 토큰 사용량이 폭주할 수 있습니다.

결론은 무엇일까요? LLM은 훌륭한 협업자이지, 정책 집행자가 아닙니다.

오늘 바로 배포할 수 있는 간단한 권한 모델

모델을 신뢰하는 대신, 저는 에이전트가 무엇을, 어디서, 어떤 조건 하에 할 수 있는지를 정의할 수 있는 아주 작은 JSON 기반 정책 언어를 구축했습니다. 이 정책은 LLM이 호출되기 전에 평가되므로, 모델이 안전한 범위 내에서만 작동하도록 보장합니다.

// agent-policy.json
{
  "agent_name": "data_extractor",
...

이 정책은 의도적으로 선언적(declarative)으로 설계되었습니다. 즉, 수행 가능한 작업(actions), 리소스 글로브(resource globs), 그리고 보조 제약 조건(auxiliary constraints)을 나열합니다. 이 시점에서는 어떠한 코드도 실행되지 않으므로, 검토 및 감사(audit)가 용이합니다.

작은 Python 래퍼(Wrapper)를 통한 정책 강제

저는 LLM에 권한을 위임하기 전에 요청을 정책과 대조하여 확인하는 Python 모듈로 이 정책을 감싸(wrap) 구현했습니다. 아래는 강제 로직의 핵심 부분입니다.

import json, fnmatch, time
from pathlib import Path

...

사용 예시

policy = AgentPolicy('agent-policy.json')

# LLM이 10초 동안 버킷(bucket)에서 읽기를 원한다고 가정
...

만약 LLM이 금지된 작업(예: delete)을 제안하면, 래퍼는 외부 호출이 발생하기 전에 이를 중단합니다. 정책 강제 적용으로 인한 오버헤드는 불과 몇 밀리초(ms)에 불과하지만, 이는 치명적인 실수를 방지해 줍니다.

감사 자동화 및 지속적 개선

정책 파일이 일반적인 JSON 형식이므로, 코드와 함께 버전 관리(version-control)를 할 수 있습니다. 저는 모든 PR(Pull Request)에 대해 정적 분석(static-analysis) 테스트를 실행하는 CI 작업을 설정했습니다.

스키마 검증기(schema validator)를 사용하여 정책을 파싱합니다.
프로덕션 에이전트의 resource_patterns에 * 와일드카드가 포함되지 않도록 보장합니다.
외부 API에 접근하는 에이전트의 max_runtime_seconds가 60을 초과하지 않는지 확인합니다.

래퍼에서 생성된 감사 로그(stderr에 기록됨)는 모니터링 대시보드로 전송되어, 정책 위반 사항을 실시간으로 확인할 수 있게 해줍니다. 시간이 흐르면서 실제 사용 패턴을 학습함에 따라 정책을 더욱 엄격하게 다듬을 수 있습니다.

배운 점

LLM에게 권한을 절대 위임하지 마세요. 잘 훈련된 모델이라 할지라도 허용적인 설정(permissive settings)을 환각(hallucinate)할 수 있습니다.
작은 선언적 정책 계층은 실행 비용이 거의 없으면서도 보안 "가드레일(guardrail)"을 추가합니다.
직접 겪은 프로덕션 경험이 중요합니다. LLM이 관리자 버킷 접근 권한을 부여하도록 방치했던 저의 실수로 인해, 체계적인 접근 방식의 필요성을 절감했습니다.
정책을 코드와 마찬가지로 버전 관리하세요. 감사가 매우 간단해지며, 위험한 변경 사항이 발생했을 때 즉시 롤백(roll back)할 수 있습니다.

LLM을 명시적인 권한(explicit permissions)이 설정된 샌드박스(sandbox) 내에 유지함으로써, 시스템의 규정 준수(compliance), 비용 효율성, 그리고 안전성을 유지하는 동시에 AI의 창의적인 이점을 누릴 수 있습니다.

_이 가이드가 유용했다면, 댓글을 통해 여러분만의 권한 정책(permission-policy) 경험을 자유롭게 공유해 주세요. 똑똑하면서도

안전한(secure)

AI 에이전트를 함께 만들어 갑시다.