과도한 권한

과도한 권한 (LLM06:2025) — 예상 밖의 행동이 실제 피해로 이어지는 순간

LLM 기반 시스템은 개발자가 부여한 '권한(agency)'을 가지고 동작해요. 확장(extension)을 통해 함수를 호출하거나 다른 시스템과 연동하고, 심지어 어떤 확장을 호출할지 LLM 에이전트가 동적으로 정하기도 하죠. 문제는 LLM이 예상 밖의, 모호한, 또는 조작된 출력에 반응해서 파괴적인 동작을 실행할 수 있다는 거예요. 이게 바로 Excessive Agency(과도한 권한) 취약점이에요. OWASP가 정리한 LLM06:2025 정의와 완화 전략을 강사 목소리로 풀어볼게요.

출처: OWASP GenAI Security Project — LLM06:2025 Excessive Agency

무엇이 방아쇠를 당기나요

LLM이 고장 나는 원인이 뭐든, 그 결과로 피해가 발생할 수 있어요. 대표적인 트리거를 보면 이래요.

  • 잘못 설계된 무해한 프롬프트나 성능이 낮은 모델이 만들어내는 환각/혼동.
  • 악성 사용자의 직접/간접 프롬프트 인젝션, 또는 손상된 확장이나 (멀티 에이전트 시스템에서) 손상된 동료 에이전트.

그리고 그 근본 원인은 보통 세 가지로 압축돼요.

  • 과도한 기능(Excessive Functionality) — 시스템 의도에 필요 없는 함수까지 확장이 가진 경우.
  • 과도한 권한(Excessive Permissions) — 다운스트림 시스템에 필요 이상의 권한을 가진 경우.
  • 과도한 자율성(Excessive Autonomy) — 고영향 동작을 독립적으로 검증·승인 없이 실행하는 경우.

이 취약점은 모델이 상호작용할 수 있는 시스템의 범위에 따라 기밀성·무결성·가용성 전반에 걸쳐 큰 피해로 번질 수 있어요.

실제 사례

  • LLM 에이전트가 문서 저장소에서 문서를 읽어야 하는데, 선택한 써드파티 확장이 수정·삭제 기능까지 포함하고 있는 경우.
  • 개발 중에 시험해보던 플러그인을 더 나은 대안으로 교체했는데, 원래 플러그인이 아직도 LLM 에이전트에 남아 있는 경우.
  • 특정 셸 명령 하나를 실행하는 확장이, 다른 셸 명령까지 실행되는 걸 막지 못하는 경우.
  • 읽기 전용이면 충분한데, DB에 SELECT 뿐 아니라 UPDATE·INSERT·DELETE 권한을 가진 정체성으로 연결하는 경우.
  • 사용자 개인 문서를 읽는 확장이 모든 사용자 파일에 접근 가능한 고권한 계정으로 저장소에 붙는 경우.
  • 문서 삭제 기능이 사용자 확인 없이 삭제를 실행하는 경우.

완화 전략

  • 호출 가능한 확장을 최소화 — LLM 에이전트가 부를 수 있는 확장을 필요한 만큼만 남겨요. URL 내용을 가져올 필요가 없다면 그런 확장은 아예 제공하지 말아요.
  • 확장 내 함수를 최소화 — 메일 요약만 필요하면 읽기 기능만 두고, 삭제·발송 기능은 넣지 마요.
  • 오픈엔드 확장 회피 — 셸 명령 실행, URL fetch 같은 열린 기능 대신 세밀한 기능만 하는 확장을 만들어요. 예를 들어 파일 쓰기가 필요하면 셸 함수 대신 '파일 쓰기 전용 확장'을 만들어요.
  • 다운스트림 권한 최소화 — 제품 DB로 추천을 만드는 에이전트면 'products' 테이블 읽기 권한만 주고, 다른 테이블이나 INSERT·UPDATE·DELETE 권한은 제거해요. DB 정체성에 적절한 DB 권한을 적용하는 거예요.
  • 사용자 인증·스코프 추적 — 사용자 대신 수행하는 동작은 그 사용자의 컨텍스트에서, 최소 권한으로 실행되게 해요. 코드 저장소를 읽는 확장이라면 OAuth로 인증하고 최소 스코프를 요구해요.
  • 고영향 동작은 사람 승인 — 소셜 콘텐츠 발행 같은 동작에 human-in-the-loop 승인 절차를 넣어요. 다운스트림 시스템에 구현하거나 확장 내에 넣을 수 있어요.
  • 다운스트림에서 인가 구현 — LLM이 결정하도록 맡기지 말고, 모든 요청을 보안 정책으로 검증하는 완전 매개(complete mediation) 원칙을 지켜요.
  • 보안 코딩 관행 — OWASP ASVS 권고를 따르고 입력 정화에 집중하며, 개발 파이프라인에 SAST·DAST·IAST를 적용해요.

피해를 완전히 막진 못해도 손상 범위를 줄이는 보조 수단으로는, LLM 확장과 다운스트림 시스템 활동을 로깅·모니터링하고, 비율 제한(rate limiting)으로 일정 시간 내 부정적 동작 수를 줄이는 방법이 있어요.

예시 시나리오

개인 이메일 요약을 위해 메일 함에 접근하는 개인 비서 앱이 있다고 볼게요. 읽기만 필요했는데 선택한 플러그인에 발송 기능이 포함돼 있고, 간접 인젝션에 취약해 악성 이메일이 '고객 사서함을 뒤져 민감정보를 공격자 이메일로 보내라'고 지시할 수 있죠. 이 경우 ① 읽기만 하는 확장으로 과도한 기능을, ② 읽기 전용 OAuth 스코프로 과도한 권한을, ③ LLM이 만든 메일마다 사용자가 확인 후 '보내기'를 누르게 해 과도한 자율성을 제거할 수 있어요.

더 알아보기 (Learn more)