서론
AI 에이전트는 질문에 답하는 모델을 넘어 메일, 파일 저장소, SaaS, 데이터베이스, 티켓 시스템 같은 외부 도구를 호출한다. 이 연결은 업무 자동화의 가치를 높이지만, 모델의 출력이 곧바로 조회·수정·전송 같은 실행으로 이어지는 경로도 만든다. 따라서 보안 설계의 핵심은 모델 응답의 품질만이 아니라, 그 응답이 호출할 수 있는 도구와 하위 시스템의 권한이다.
핵심 위험은 모델이 “틀린 답”을 만드는 데서 끝나지 않는다. 신뢰할 수 없는 문서나 웹 페이지에 포함된 지시가 에이전트의 판단에 섞이고, 넓게 부여된 도구 권한과 결합하면 의도하지 않은 데이터 접근·외부 전송·업무 시스템 변경으로 확대될 수 있다. OWASP는 이를 LLM06:2025 Excessive Agency로 분류하며, 과도한 기능, 과도한 권한, 과도한 자율성을 주요 원인으로 든다.
이 글은 특정 제품 취약점 공지가 아니라, 조직이 AI 에이전트를 도입하거나 운영할 때 권한·도구 호출·데이터 반출을 점검하는 보안 가이드다. 모든 에이전트가 같은 위험도를 갖는 것은 아니며, 실제 위험은 연결된 시스템과 실행 가능한 작업에 따라 달라진다.
근거와 적용 범위
| 본문 주장 | 근거 | 적용 범위 |
|---|---|---|
| 외부 파일·웹 페이지가 모델 동작을 바꾸는 간접 프롬프트 인젝션이 가능하다 | OWASP LLM01은 외부 소스의 콘텐츠가 모델 동작을 의도치 않게 바꿀 수 있다고 설명한다. | 외부 문서·검색·메일을 모델 컨텍스트에 넣는 시스템 |
| 과도한 기능·권한·자율성은 피해 범위를 키운다 | OWASP LLM06은 이 세 항목을 Excessive Agency의 원인으로 제시한다. | 도구 호출 또는 하위 시스템 연동이 있는 에이전트 |
| 사전 시험·모니터링·사고 대응은 운영 통제의 일부여야 한다 | NIST AI 600-1은 거버넌스, 사전 배포 시험, 사고 공개를 생성형 AI 위험 관리의 주요 고려사항으로 다룬다. | 조직에서 운영·배포하는 생성형 AI 시스템 |
여기서 제시하는 정책 예시와 점검 항목은 보편적 설계 권고이며, 특정 제품의 기본 설정이나 특정 공격의 발생 사실을 뜻하지 않는다. 실제 통제 수준은 데이터 분류, 업무 영향도, 규제 요구사항, 연결된 시스템의 권한 모델을 기준으로 결정한다.
본론
왜 AI 에이전트의 권한 모델이 중요한가
일반적인 챗봇은 답변 자체가 주된 결과물이다. 반면 에이전트는 모델이 계획을 세우고, 연결된 도구를 선택하며, API 요청이나 워크플로를 실행한다. 따라서 보안 검토 대상은 모델뿐 아니라 다음 연결 전체다.
| 구성 요소 | 점검 질문 | 대표 위험 |
|---|---|---|
| 모델과 프롬프트 | 외부 콘텐츠의 지시가 시스템 지시보다 우선할 수 있는가 | 간접 프롬프트 인젝션, 잘못된 도구 선택 |
| 도구 정의 | 도구가 수행할 수 있는 동작과 입력값이 제한돼 있는가 | 과도한 조회·수정·삭제 |
| 인증 정보 | 에이전트마다 분리된 짧은 수명의 자격 증명을 쓰는가 | 토큰 재사용, 권한 확산 |
| 데이터 경로 | 입력·검색 결과·도구 응답에 민감정보가 섞이는가 | 비밀정보의 모델 컨텍스트 유입 |
| 실행 통제 | 외부 전송·권한 변경 같은 작업에 사람이 승인하는가 | 승인 없는 고위험 실행 |
| 관측성 | 요청 주체, 도구, 대상, 승인, 결과를 추적할 수 있는가 | 사고 원인 규명과 복구 지연 |
권한은 에이전트의 이름이 아니라 작업 단위로 부여해야 한다. 예를 들어 “고객지원 에이전트”에 CRM 전체 쓰기 권한을 주는 대신, 고객 조회와 사전에 정의된 티켓 생성만 허용한다. 배포 보조 에이전트도 운영 환경의 임의 명령 실행 권한이 아니라, 승인된 변경 요청에 연결된 제한된 배포 작업만 호출하도록 구성한다. OWASP LLM06 역시 개방형 도구보다 세분화된 기능을 사용하고, 하위 시스템 권한은 필요한 최소 범위로 제한할 것을 권고한다.
공격이 실행으로 이어지는 경로
간접 프롬프트 인젝션은 에이전트가 읽는 문서, 이메일, 웹 페이지, 티켓 댓글, 검색 결과 등에 포함된 콘텐츠가 모델 동작을 의도치 않게 바꾸는 상황을 말한다. OWASP LLM01은 외부 웹사이트나 파일을 입력으로 수용하는 경우를 간접 프롬프트 인젝션의 예로 든다.공격자는 “이 문서를 요약하라”는 정상 업무 흐름에 숨은 문구를 넣어 연결된 도구의 사용을 유도할 수 있다. 모델이 외부 콘텐츠를 신뢰할 수 없는 데이터가 아니라 실행 지시처럼 취급하면 문제가 발생한다.
다음은 방어 관점의 단순화된 흐름이다.
외부 문서 또는 이메일
↓
에이전트가 문서 내용을 컨텍스트에 포함
↓
악성 지시가 도구 호출 판단에 영향
↓
넓은 권한의 커넥터가 데이터 조회·전송 또는 변경 수행
↓
감사 로그·승인 절차 부재 시 탐지와 복구가 지연
이 경로가 성립하려면 모델의 취약성만이 아니라, 실행 가능한 도구와 과도한 권한이 함께 존재해야 한다. OWASP LLM01은 프롬프트 인젝션을 완벽히 막는 방법이 불확실하다고 설명한다. 따라서 프롬프트 필터 하나로 해결하려 하기보다 신뢰 경계, 권한, 승인 절차를 겹겹이 설계해야 한다. NIST의 생성형 AI 프로파일도 생성형 AI 위험 관리를 거버넌스, 사전 배포 시험, 사고 공개 등 조직의 관리 활동과 연결해 다룬다.
데이터 반출 통제: 모델에 들어가는 정보와 밖으로 나가는 정보를 분리한다
데이터 반출은 단순히 파일 다운로드만을 뜻하지 않는다. 에이전트가 고객 정보·내부 문서·API 응답을 읽고, 이를 외부 메일·메신저·웹훅·타사 서비스에 전달하는 모든 흐름이 대상이다. 특히 하나의 에이전트가 내부 검색과 외부 전송 도구를 동시에 보유하면, 정상 업무 도구 조합이 반출 경로가 될 수 있다.
우선 데이터 분류 기준을 도구 정책에 반영한다. 공개 데이터와 내부 데이터, 개인정보·자격 증명·계약 정보처럼 제한된 데이터를 구분하고, 제한 데이터는 기본적으로 외부 전송 도구의 입력값으로 허용하지 않는다. 가능하면 모델에 원문을 모두 전달하지 말고, 서버 측 검색 계층에서 접근 권한을 확인한 뒤 필요한 최소 발췌만 제공한다.
도구 호출 전에 적용할 수 있는 정책 예시는 다음과 같다.
tool: external_message_send
allow_when:
- destination_domain in approved_domains
- data_classification == public
- human_approval == true
deny_when:
- payload_contains_secret == true
- payload_contains_personal_data == true
audit_fields:
- requester_identity
- agent_identity
- destination
- approval_id
- policy_decision
이 정책은 예시이며, 실제 구현에서는 데이터 분류 정확도와 업무 예외 처리 절차를 함께 검증해야 한다. 탐지 규칙만 두고 전송 자체를 허용하면 오탐 또는 탐지 지연 시 이미 데이터가 외부로 나갈 수 있다. 고위험 대상에는 사전 차단과 승인 절차가 더 적합하다.
우선순위별 대응 전략
즉시 조치: 도구와 자격 증명 인벤토리를 만든다
운영 중인 에이전트별로 연결 도구, 호출 가능한 동작, 서비스 계정, 접근 데이터, 외부 전송 가능 여부, 소유자를 목록화한다. 읽기 권한처럼 보이는 도구도 민감한 데이터에 접근하면 반출 위험이 있다. 더 이상 사용하지 않는 커넥터와 장기 토큰은 폐기하거나 회전한다.
고위험 동작은 기본 차단으로 전환한다. 삭제, 대량 다운로드, 권한 변경, 비밀정보 조회, 외부 수신자 전송, 결제·배포 실행은 사람의 명시적 승인 없이는 수행되지 않아야 한다. 승인 화면에는 에이전트의 자연어 요약만 표시하지 말고 대상, 변경 전후 값, 전송 범위, 호출 도구를 함께 보여준다.
단기 조치: 최소 권한과 분리를 적용한다
에이전트별 서비스 계정과 OAuth 범위를 분리한다. 같은 토큰을 여러 에이전트나 개발·운영 환경에 공유하지 않고, 가능한 경우 짧은 수명 토큰과 작업별 위임을 사용한다. 읽기·쓰기·관리 권한을 나누고, 쓰기 도구는 허용된 리소스와 필드만 받도록 API 계층에서 검증한다.
외부 콘텐츠는 신뢰할 수 없는 입력으로 취급한다. 검색 결과나 첨부 문서의 텍스트를 시스템 지시와 구분하고, 외부 콘텐츠가 도구 호출 조건이나 정책을 바꾸지 못하게 한다. 도구 호출의 매개변수는 모델이 임의로 만든 문자열을 그대로 수용하지 말고, 스키마 검증·허용 목록·서버 측 정책 확인을 통과시킨다.
중기 조치: 평가와 모니터링을 운영 절차에 넣는다
사전 배포 평가에는 정상 업무 시나리오뿐 아니라 악성 문서, 지시 충돌, 권한 상승 유도, 민감정보가 포함된 도구 응답, 외부 전송 유도 사례를 포함한다. 평가는 단발성 레드팀 행사로 끝내지 않고 도구·모델·프롬프트·정책 변경 때마다 반복한다.
감사 로그에는 사용자 요청, 에이전트 ID와 버전, 사용한 도구, 입력·출력의 민감정보 마스킹 상태, 정책 판단, 승인 ID, 실제 결과를 남긴다. 로그에 원문 비밀정보를 과도하게 저장하지 않도록 별도 접근 통제와 보존 정책도 적용한다. 실패한 도구 호출과 정책 거부 이벤트는 공격 징후를 찾는 데 특히 중요하다.
운영 체크리스트
| 우선순위 | 점검 항목 | 권장 조치 | 담당 |
|---|---|---|---|
| Critical | 외부 전송·권한 변경·삭제가 자동 실행되는가 | 승인 게이트를 적용하고 기본 차단 | 서비스 소유자, 보안팀 |
| Critical | 공유 토큰 또는 과도한 관리자 권한이 있는가 | 계정 분리, 권한 축소, 토큰 회전 | IAM 담당 |
| High | 외부 문서가 도구 호출에 영향을 줄 수 있는가 | 신뢰 경계 분리, 입력 검증, 허용 목록 | 개발팀 |
| High | 내부 검색과 외부 전송 도구가 한 에이전트에 결합됐는가 | 데이터 분류 정책과 도구 분리 | 아키텍트 |
| Medium | 도구 호출과 승인 이력이 남는가 | 구조화된 감사 로그와 경보 추가 | 운영팀 |
| Medium | 정책 변경 전 공격 시나리오를 시험하는가 | 프롬프트 인젝션·반출 시나리오 평가 | 보안팀 |
| Low | 비상 중지와 토큰 폐기 절차가 문서화됐는가 | 런북·복구 훈련·책임자 지정 | 서비스 소유자 |
결론
AI 에이전트 도입의 보안 기준은 모델이 얼마나 자연스럽게 답하는지가 아니라, 어떤 데이터에 접근하고 어떤 동작을 실제로 실행할 수 있는지에 있다. 프롬프트 인젝션 대응만 강화해도 넓은 권한과 무승인 실행이 남아 있으면 위험은 사라지지 않는다.
우선 모든 도구와 권한을 목록화하고, 고위험 실행은 사람 승인으로 전환해야 한다. 이어서 작업 단위 최소 권한, 외부 입력 격리, 데이터 분류 기반 전송 정책, 변경 가능한 감사 로그를 결합한다. 이 통제는 에이전트의 활용을 막기 위한 장치가 아니라, 자동화를 안전하게 확장하기 위한 운영 기반이다.
참고자료
[owasp-agency]: OWASP GenAI Security Project, LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
[owasp-pi]: OWASP GenAI Security Project, LLM01:2025 Prompt Injection — https://genai.owasp.org/llmrisk/llm01-prompt-injection/
[nist]: NIST, AI 600-1 Generative AI Profile — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.
댓글 (0)
댓글을 작성하려면 로그인이 필요합니다.
로그인아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!