AI 에이전트를 붙이고 나면 곧바로 부딪히는 질문이 하나 있습니다. 이 녀석한테 권한을 어디까지 줄 것인가.
너무 조이면 매번 확인만 받다가 아무것도 자동화가 안 됩니다. 너무 풀면 어느 날 물어보지도 않고 뭔가를 보내버립니다. 그리고 이 둘 사이의 선은 문서에 안 적혀 있습니다. 직접 굴려보면서 찾아야 합니다.
이 문제에는 이름이 있습니다. OWASP가 붙인 이름입니다.
OWASP는 이걸 LLM06이라고 부릅니다
OWASP GenAI Security Project가 내놓은 Top 10 for LLM Applications 2025에는 열 가지 위험이 들어 있습니다. 그중 여섯 번째가 LLM06:2025 Excessive Agency, 우리말로 하면 과도한 행위 권한입니다.
참고로 2025년판 열 가지는 이렇습니다.
- LLM01 Prompt Injection
- LLM02 Sensitive Information Disclosure
- LLM03 Supply Chain
- LLM04 Data and Model Poisoning
- LLM05 Improper Output Handling
- LLM06 Excessive Agency
- LLM07 System Prompt Leakage
- LLM08 Vector and Embedding Weaknesses
- LLM09 Misinformation
- LLM10 Unbounded Consumption
다른 아홉 개는 대부분 "모델이 이상하게 동작한다"는 쪽입니다. LLM06만 성격이 다릅니다. 모델은 정상 동작했는데 결과가 사고인 경우를 다룹니다.
이게 왜 중요하냐면, 프롬프트 인젝션을 완벽하게 막아도 LLM06은 그대로 남기 때문입니다. 공격자가 없어도 발생합니다. 에이전트가 그냥 자기 판단으로 실행해버리면 그걸로 끝입니다.
과도한 권한은 세 갈래로 옵니다
OWASP는 원인을 크게 셋으로 나눕니다. 실제로 겪어보면 이 구분이 꽤 정확합니다.
첫째, 기능이 너무 많습니다. 파일을 읽으려고 붙인 도구가 삭제까지 됩니다. 메일을 읽으려고 준 권한에 발송이 딸려 옵니다. 필요한 건 읽기 하나인데 쓰기가 덤으로 붙는 구조입니다.
둘째, 권한이 너무 넓습니다. 특정 폴더만 보면 되는데 계정 전체 권한으로 붙여둡니다. 당장은 편하고, 사고 날 때 범위가 전부입니다.
셋째, 자율성이 너무 큽니다. 이게 제일 무섭습니다. 되돌릴 수 없는 행동을 확인 없이 실행할 수 있게 열어둔 상태요. 앞의 둘은 설정 문제지만 이건 설계 문제입니다.
그래서 권한을 단계로 나눕니다
제가 쓰는 방식은 권한을 하나의 스위치로 두지 않고 단계로 쪼개는 것입니다. 읽기만 되는 상태, 정해진 작업공간 안에서만 쓰기가 되는 상태, 전체 접근이 열린 상태를 구분해두고 상황에 따라 다르게 씁니다.
이 3단 구조를 실제로 어떻게 쓰는지는 따로 정리해뒀습니다.
- OpenClaw 권한 모드 이해하기｜읽기 전용·작업공간·전체 접근의 차이
- OpenClaw 도구가 막힐 때｜샌드박스·도구 정책·Elevated 권한을 구분하는 법
- OpenClaw 허용 목록을 여러 채널에서 재사용하는 법｜Access groups의 역할과 한계
단계를 나눠두면 좋은 점이 하나 있습니다. "권한을 줄까 말까"가 아니라 "어느 단계로 줄까"가 됩니다. 전자는 매번 고민이지만 후자는 기본값을 정해둘 수 있습니다.
진짜 경계선은 "되돌릴 수 있는가"입니다
여러 기준을 써봤는데 결국 하나로 정리됐습니다. 되돌릴 수 있는 행동과 없는 행동. 이 선 하나가 나머지를 거의 다 설명합니다.
읽기, 검색, 파일 정리, 초안 작성, 분류 — 이런 건 틀려도 다시 하면 됩니다. 여기서 일일이 확인받으면 자동화의 의미가 없습니다. 그냥 하게 둡니다.
반대로 이런 것들이 있습니다.
- 메일 발송, SNS 게시, 외부 공개 업로드
- 결제와 환불
- 계정 설정 변경
- 프로덕션 배포
- 삭제, 덮어쓰기
이것들의 공통점은 실행되는 순간 취소가 안 되거나, 취소해도 흔적이 남는다는 점입니다. 보낸 메일은 회수해도 이미 읽혔을 수 있고, 올린 글은 내려도 캐시에 남습니다.
그래서 저는 이 목록을 명시적 승인 없이는 실행하지 않는 행동으로 못 박아뒀습니다. 에이전트가 아무리 확신해도, 아무리 제가 전에 비슷한 걸 승인했어도, 이 범주는 매번 물어보게 합니다.
여기에 하나 덧붙이면 — 한 번의 승인이 다음 번까지 이어지지 않게 하는 게 중요합니다. "지난주에 이 메일 보내도 된다고 하셨잖아요"는 위험한 논리입니다. 맥락이 바뀌면 같은 행동도 다른 결과를 냅니다.
승인 게이트를 어디에 두느냐
실수하기 쉬운 지점이 있습니다. 승인을 계획 단계에 두면 소용이 없습니다.
"이제 메일을 보내겠습니다"에 승인하는 것과, "이 내용으로 이 주소에 보냅니다"에 승인하는 것은 완전히 다릅니다. 전자는 사실상 백지수표입니다. 게이트는 실행 직전, 실제 내용이 확정된 지점에 있어야 합니다.
그리고 승인 화면에는 실제로 나갈 것이 그대로 보여야 합니다. 요약본을 보여주고 원문을 보내면 승인의 의미가 없습니다.
정리
LLM06 Excessive Agency는 모델을 똑똑하게 만든다고 해결되지 않습니다. 오히려 모델이 똑똑해질수록 더 많은 걸 스스로 하려 들기 때문에 권한 설계가 더 중요해집니다.
세 가지만 정해두면 대부분 커버됩니다.
- 권한을 단계로 나눈다. 기본값은 가장 좁은 단계로.
- 되돌릴 수 있는가로 선을 긋는다. 되돌릴 수 없는 건 전부 승인 대상.
- 게이트는 실행 직전에 둔다. 그리고 나갈 내용을 그대로 보여준다.
에이전트에게 권한을 주는 건 사람에게 권한을 주는 것과 다르지 않습니다. 신입에게 회사 카드를 주되 한도를 걸고, 큰 건은 결재를 받게 하는 것과 같은 이야기입니다. 다른 점이라면 에이전트는 훨씬 빠르고, 지치지 않고, 잘못을 스스로 부끄러워하지 않는다는 것 정도입니다.
참고 자료
- OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2025 — genai.owasp.org/llm-top-10
- LLM06:2025 Excessive Agency — genai.owasp.org/llmrisk/llm062025-excessive-agency