AI 에이전트 보안이란 무엇인가?
AI 에이전트 보안은 자율적이거나 반자율적인 LLM 시스템이 '무엇을 말할 수 있는지'뿐만 아니라 '무엇을 할 수 있는지'를 제어하는 학문입니다. 텍스트만 반환하는 모델은 콘텐츠(content) 문제입니다. 도구를 호출하고, 데이터 저장소(data stores)를 읽고, 워크플로우(workflows)를 트리거하는 모델은 실행(execution) 문제입니다. 에이전트가 자격 증명(credentials)을 보유하고 함수를 호출할 수 있게 되는 순간, 보안 문제는 프롬프트 품질에 대한 것이 아니라 접근 제어(access control)에 관한 문제가 됩니다.
본 글은 특정 질문에 답합니다: LLM 접근 제어를 구현하고 모니터링하는 최고의 방법론은 무엇인가? 이 답변은 공격 경로를 중심으로 구성되는데, 이는 접근 제어가 무엇을 막고 있는지 알아야만 의미가 있기 때문입니다.
공격 표면(Attack Surface)의 구체적 분석
에이전트는 일반적으로 외부 세계와 연결되는 세 가지 방법을 가집니다:
- 도구 호출(Tool calls). 모델은 구조화된 호출을 방출하고 런타임(runtime)이 이를 실행합니다. 만약 도구가 광범위한 자격 증명에 바인딩되어 있다면, 모델은 해당 자격 증명이 허용하는 모든 것에 그 자격 증명을 사용할 수 있습니다.
- 검색된 콘텐츠(Retrieved content). 문서, 웹 페이지, 티켓 등이 컨텍스트 창(context window)으로 흘러들어옵니다. 이들 중 어느 것이든 지침을 담고 있을 수 있습니다. 모델은 데이터와 지침을 신뢰성 있게 구별할 수 없습니다.
- 메모리 및 상태(Memory and state). 에이전트가 작성한 내용은 지속되며, 이후의 턴이나 다른 에이전트에 의해 읽힐 수 있습니다.
공격은 이론적인 것이 아닙니다. 검색된 문서에는 에이전트에게 요청되지 않은 도구를 호출하라고 지시하는 줄이 포함되어 있을 수 있습니다. 모델은 이 지침을 컨텍스트처럼 보여서 이를 따릅니다. 런타임은 해당 도구가 사용 가능하고 자격 증명이 유효하기 때문에 그 호출을 실행합니다. 이 과정에서 모델 자체가 손상될 필요는 없었습니다. 단지 그 도구에 접근할 수만 있으면 되었습니다.
이것이 바로 프롬프트 수준의 방어(prompt-level defenses)가 자체적으로 불충분한 이유입니다. 허용된 행동 집합(allowed action set)이 너무 크다면, 필터링만으로는 문제를 해결할 수 없습니다.
막는 메커니즘
제어는 프롬프트에 있는 것이 아니라 도구 경계(tool boundary)에 있어야 합니다. 이 작업을 수행하는 두 가지 메커니즘이 있습니다:
도구별 범위 인증 정보(Per-tool scoped credentials). 각 도구는 해당 도구가 필요로 하는 것만 부여하는 인증 정보를 받습니다. 에이전트는 광범위한 접근 권한을 가진 공유 토큰을 보유하지 않습니다. 작업 범위를 벗어난 도구에 호출이 발생하면, 해당 도구의 인증 정보가 존재하지 않으므로 실행 전에 호출이 실패합니다.
인자(arguments)를 포함한 호출 로깅(Invocation logging). 모든 도구 호출은 사용된 인증 정보, 전달된 인자, 그리고 결정과 함께 기록됩니다. 모니터링은 나중에 추가되는 대시보드가 아닙니다. 그것은 경계가 허용한 것에 대한 기록입니다. 호출이 거부되면, 로그는 그 이유를 보여줍니다.
순서가 중요합니다. 권한 부여(Authorization)는 실행 전에 확인되어야 하며, 나중에 확인되어서는 안 됩니다. 부작용이 발생한 후에 작성된 로그는 감사 추적(audit trail)일 뿐, 제어(control)가 아닙니다.
구체적인 실패 모드 (A concrete failure mode)
지원 티켓을 요약하는 에이전트를 가정해 봅시다. 이 에이전트는 티켓을 읽고 이메일을 보낼 수 있는 하나의 API 토큰을 가지고 있습니다. 티켓 본문에는 지난 10개 티켓을 외부 주소로 전달하라는 지침이 포함되어 있습니다. 모델은 이메일 도구를 호출합니다. 토큰은 유효합니다. 호출은 성공합니다.
실패는 모델이 속았기 때문이 아닙니다. 실패는 요약 작업에서 이메일 도구에 접근할 수 있었다는 점입니다. 도구별 범위 지정(per-tool scoping)을 사용하면, 요약 작업은 티켓 읽기 인증 정보만 보유합니다. 이메일 도구는 범위를 벗어납니다. 호출이 거부되고, 그 거부는 시도된 인자와 함께 기록됩니다.
RESK를 사용한 구현 (Implementation with RESK)
RESK는 요청 경로 주변에 제어를 추가하는 것이 아니라, 그 경로 자체에 제어를 구축합니다.
reskSecure는 에이전트 도구 접근에 대한 최소 권한(least privilege)을 강제합니다. 사용자는 특정 작업에 대해 에이전트가 호출할 수 있는 도구를 정의하고, reskSecure는 도구별로 인증 정보를 바인딩합니다. 해당 범위 밖의 호출은 실행 전에 거부됩니다. 이 거부는 인증 정보와 인자(arguments)와 함께 기록되므로, 모니터링은 별도의 관찰 계층(observation layer)이 아닌 경계 자체를 반영하게 됩니다.
ReskPoints는 해당 결정이 요청 경로를 따라 적용되는 강제 적용 지점(enforcement points)을 제공하므로, 호출이 반드시 통과해야 하는 경계에서 확인이 이루어지며 우회될 수 있는 사이드카 내부가 아닙니다.
도구 권한 모델(tool permission model)에 대한 자세한 내용은 저희의 AI 에이전트 도구 권한(AI agent tool permissions) 기사에서 읽어보실 수 있습니다.
에이전트에 최소 권한 원칙(least privilege)을 적용하려면 여기에서 시작하세요: reskSecure.
체크리스트 (Checklist)