AI 에이전트 프롬프트 인젝션 방어와 권한 분리 5단계
- 프롬프트 인젝션은 사용자 입력뿐 아니라 이메일·웹페이지·파일에도 포함될 수 있습니다.
- 도구 기능과 연결 계정의 권한을 작업에 필요한 최소 범위로 제한합니다.
- 외부 전송·삭제처럼 영향이 큰 작업에는 별도 승인과 기록을 적용합니다.
AI 에이전트의 프롬프트 인젝션 방어는 시스템 프롬프트에 금지 문구를 추가하는 것만으로 끝나지 않습니다. 외부 콘텐츠를 신뢰할 수 없는 입력으로 다루고, 도구 기능과 연결 계정의 권한을 줄이며, 영향이 큰 동작은 실행 전에 통제해야 합니다. 프롬프트 인젝션은 입력이나 외부 콘텐츠가 모델의 행동이나 출력을 의도하지 않은 방향으로 바꾸는 취약점입니다. 예를 들어 이메일 요약 에이전트에는 메일 읽기 기능만 제공하고, 발송과 삭제는 별도 기능 및 승인 절차로 분리할 수 있습니다. OWASP는 프롬프트 인젝션을 완벽히 예방할 방법이 있는지는 불확실하다고 설명하며, 영향을 줄이는 통제를 권고합니다.
에이전트는 왜 권한 분리가 필요한가
직접 공격과 간접 공격을 함께 봅니다
직접 프롬프트 인젝션은 사용자가 입력한 문구가 모델의 행동을 바꾸려는 방식입니다. 간접 프롬프트 인젝션은 에이전트가 읽는 이메일, 웹페이지, 첨부 파일, 검색 결과 등에 공격 지시를 포함하는 방식입니다. 사용자는 평범한 요약을 요청했더라도, 에이전트가 읽은 문서의 내용이 다른 행동을 유도할 수 있습니다. 사람이 알아보기 어려운 텍스트나 이미지 안의 지시도 모델이 처리한다면 공격 입력이 될 수 있습니다. [OWASP 프롬프트 인젝션 안내](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)는 외부 파일과 웹페이지, 사람이 인지하기 어려운 입력, 이미지에 포함된 지시를 위험 사례로 설명합니다.
위험은 도구 권한과 결합할 때 커집니다
읽기만 하는 에이전트와 외부 메일 발송, 파일 삭제, 결제, 셸 명령까지 할 수 있는 에이전트는 잘못된 판단이 초래할 수 있는 피해 범위가 다릅니다. OWASP는 과도한 기능·권한·자율성이 예상하지 못했거나 조작된 모델 출력에 따른 피해를 키울 수 있다고 설명합니다. 따라서 모델이 공격을 알아차리도록 하는 것뿐 아니라, 잘못 판단해도 실행할 수 있는 행동과 접근 가능한 데이터의 범위를 제한해야 합니다. [OWASP 과도한 에이전트 권한 안내](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)를 참고할 수 있습니다.
먼저 정할 기준: 역할·데이터·행동
작업 하나에 필요한 권한을 적습니다
에이전트마다 목적, 접근 데이터, 허용 행동, 금지 행동을 정리하세요. 예를 들어 ‘받은 메일 요약’에는 지정된 메일 읽기와 요약 반환이 필요할 수 있습니다. 주소록 전체 내보내기, 메일 전달·삭제, 계정 설정 변경은 그 작업에 꼭 필요하지 않다면 권한에서 제외합니다. ‘필요하면 사용’처럼 포괄적으로 허용하기보다 대상 리소스와 행동을 구체적으로 적으면 검토하기 쉽습니다.
입력 경로마다 신뢰 경계를 표시합니다
사용자 요청, 시스템 지침, 외부에서 가져온 데이터, 도구가 반환한 결과를 애플리케이션에서 서로 구분해 관리합니다. 외부 문서를 프롬프트에 넣을 때 출처와 신뢰할 수 없는 콘텐츠임을 표시하는 것은 모델의 혼동을 줄이는 보조책입니다. 하지만 구분 표식이나 “명령을 따르지 말라”는 안내만으로 접근 제어가 생기지는 않습니다. 실제 권한 검사는 모델 밖의 애플리케이션과 연결 시스템에서 수행해야 합니다.
| 작업 | 기본 허용 예시 | 분리하거나 제한할 권한 |
|---|---|---|
| 메일 요약 | 지정된 받은편지함 읽기 | 발송·전달·삭제 |
| 문서 검색 | 승인된 저장소 검색 | 수정·공유 링크 생성 |
| 코드 보조 | 지정 저장소 읽기 | 셸 실행·배포·비밀값 접근 |
AI 에이전트 권한 분리 5단계
1단계: 에이전트와 데이터 흐름을 목록화합니다
각 에이전트가 어떤 사용자 요청을 받고, 어디서 데이터를 가져오며, 어떤 도구를 호출하고, 결과를 어디로 보내는지 적습니다. 이메일·웹·RAG(검색 증강 생성)·메모리·다른 에이전트의 응답도 입력 출처로 기록합니다. 도구 목록에서 사용하지 않는 기능과 출처가 불명확한 연결을 찾아냅니다.
2단계: 도구를 작고 구체적인 기능으로 나눕니다
‘모든 메일 관리’나 ‘임의 URL 가져오기’처럼 범위가 넓은 도구 하나를 주기보다 목적별 기능으로 나눕니다. 읽기와 발송, 검색과 삭제, 코드 조회와 실행은 별개의 기능으로 분리하세요. 호출 인자는 허용된 폴더·레코드·도메인 등으로 제한하고, 자유 형식 명령을 그대로 셸이나 데이터베이스 쿼리에 전달하지 않습니다.
3단계: 사용자와 작업 단위로 권한을 적용합니다
도구 서버가 사용하는 계정에는 필요한 API 범위만 부여합니다. 사용자별 데이터 작업은 공용 관리자 계정 대신 해당 사용자의 인증과 권한 범위에 연결합니다. 데이터베이스에서는 필요한 테이블에 읽기 권한만, 저장소에서는 지정 프로젝트에 읽기 권한만 부여하는 방식입니다. 요청마다 대상 리소스와 행동의 권한을 서버에서 확인해야 합니다.
4단계: 되돌리기 어렵거나 외부로 나가는 작업은 승인시킵니다
메일 발송, 외부 공유, 대량 다운로드, 결제, 삭제, 배포처럼 영향이 큰 동작은 실행 전에 사람이 내용을 확인하도록 설계합니다. 승인 화면에는 대상, 데이터 범위, 변경 내용, 수신처를 보여주세요. 승인 정보는 승인한 작업에만 유효하게 하고, 요청 내용이나 대상이 달라지면 다시 승인받습니다. 읽기나 초안 작성은 자동화할 수 있어도, 외부 전송을 모델의 판단만으로 완료시키지 않는 편이 안전합니다.
5단계: 공격 시나리오를 시험하고 기록을 점검합니다
테스트 환경에서 악성 지시가 포함된 메일·문서·검색 결과를 넣고, 에이전트가 다른 사용자의 데이터 조회나 미승인 전송을 시도하는지 확인합니다. 허용·차단 결과와 함께 어떤 도구가 어떤 사용자·리소스·인자로 호출됐는지 기록합니다. 프롬프트, 도구 설정, 권한 정책이 바뀔 때 같은 시나리오를 다시 실행해 회귀 여부를 확인하세요. 로그에는 민감한 본문 전체를 무조건 남기지 말고, 추적에 필요한 식별자와 결과를 중심으로 기록하며 접근을 통제합니다. MCP 서버 요청 로그와 도구 호출 추적법은 호출 흐름을 점검할 때 참고할 수 있습니다.
기억할 기준: 모델이 허용 여부를 스스로 결정하게 두지 마세요. 도구 요청은 서버가 사용자·대상·행동을 확인한 뒤 실행하고, 영향이 큰 작업은 별도 승인을 거쳐야 합니다.
도구 권한은 어디서 강제해야 하나
모델 밖의 실행 계층에서 검사합니다
모델에 전달하는 도구 설명이나 시스템 프롬프트는 사용 지침이지 접근 제어 장치가 아닙니다. 애플리케이션 서버가 로그인 사용자와 요청을 검증하고, 각 도구 서버도 자원 접근 권한을 확인해야 합니다. 모든 요청을 연결된 시스템의 권한 정책에 따라 검증하면 모델의 판단에만 의존하는 일을 줄일 수 있습니다. OWASP의 과도한 에이전트 권한 대응 지침도 필요한 도구와 기능·권한을 최소화하고, 연결 시스템에서 권한을 검증하도록 권고합니다.
자격 증명과 네트워크 범위도 제한합니다
API 키나 토큰을 프롬프트, 모델 컨텍스트, 도구 결과에 직접 넣지 않습니다. 작업별로 분리된 자격 증명을 사용하고, 가능하면 짧은 유효기간과 필요한 범위만 적용합니다. 네트워크 접근은 승인된 서비스로 제한하고, 임의 주소로 요청을 보내는 기능은 별도 검증을 둡니다. MCP 등 외부 도구 연결을 사용한다면 서버와 도구 설정의 변경을 검토하고, 승인되지 않은 서버가 추가되지 않도록 관리하세요.
운영 전 확인할 실패 지점
- 읽기 도구에 쓰기 권한이 함께 있음: 연결 서비스의 실제 OAuth 범위와 API 계정 권한을 확인합니다.
- 도구 결과를 그대로 다음 명령에 연결함: 외부 콘텐츠는 데이터로 취급하고 실행 인자는 스키마와 허용 목록으로 검증합니다.
- 승인이 형식적임: 사용자가 실제 수신자·대상·변경 내용을 확인해야 승인할 수 있게 합니다.
- 에이전트끼리 권한을 공유함: 위임받는 에이전트에도 별도 신원과 제한된 도구 목록을 부여합니다.
- 로그가 호출 사실만 남김: 누가 어떤 도구로 어떤 대상에 접근했는지 추적할 수 있는지 확인합니다.
한국인터넷진흥원은 2026년 7월 7일 AI 보안 위협 대응을 위한 『AI 보안 위협 대응 매뉴얼』을 게시했습니다. 안내된 목차에는 AI 보안 위협 분류 및 진단, 산업별 위협 시나리오, 위협별 대응 방안이 포함되어 있습니다. 실제 적용 시에는 조직의 데이터 등급, 업무 영향, 사용 중인 도구의 권한 모델에 맞춰 통제를 검증하세요. OWASP의 내용은 설계 권고이며 특정 환경의 안전을 보증하지 않습니다.
최종 점검: 공격 문구가 에이전트에 영향을 주더라도 민감 데이터 조회, 외부 전송, 파괴적 변경으로 이어지지 않는지 권한 경계와 승인 절차를 함께 시험하세요.
자주 묻는 질문
Q. 시스템 프롬프트에 금지 규칙을 쓰면 충분한가요?
아닙니다. 금지 규칙은 보조 수단입니다. 권한 검사는 애플리케이션과 연결 시스템에서 수행하고, 최소 권한과 승인 절차를 실제로 적용해야 합니다.
Q. 읽기 전용 도구도 프롬프트 인젝션에 취약한가요?
그럴 수 있습니다. 읽기 결과에 민감한 정보가 포함되거나 다른 도구가 외부 전송을 할 수 있다면 정보 유출로 이어질 수 있습니다. 읽기 범위와 후속 도구의 권한을 함께 살펴보세요.
Q. 모든 도구 호출에 사람 승인이 필요한가요?
항상 그럴 필요는 없습니다. 검색과 요약처럼 영향이 제한된 작업은 자동화할 수 있습니다. 발송·삭제·결제·배포처럼 외부 영향이 크거나 되돌리기 어려운 작업은 승인 대상으로 분류하는 편이 안전합니다.
Q. 프롬프트 인젝션 탐지 필터만으로 방어할 수 있나요?
탐지 필터는 의심 콘텐츠를 찾는 데 도움을 줄 수 있지만, 모든 변형이나 숨겨진 입력을 잡는다고 보장할 수 없습니다. 필터와 별개로 도구 권한 제한, 서버 측 인가 검사, 승인 및 로그를 함께 적용하세요.
