AI 에이전트 보안 체크리스트 10가지

시작하며

AI 에이전트 보안은 챗봇 보안보다 한 단계 더 까다롭다. 단순히 답변만 생성하는 도구가 아니라, 파일을 읽고, API를 호출하고, 메일을 보내고, 결제나 승인 흐름에 접근할 수 있기 때문이다.

2026년 기준으로 NIST, CISA, OWASP 같은 보안 기관과 커뮤니티도 AI 시스템의 보안 개발, 데이터 보호, 에이전트형 애플리케이션 위험을 별도로 다루고 있다. NIST는 AI 위험 관리 프레임워크와 AI 시스템 보안 통제 오버레이 작업을 진행하고 있고, CISA는 AI 데이터 보안과 보안 설계 원칙을 강조한다. OWASP도 Agentic AI 보안 위험을 별도 프로젝트로 정리하고 있다.

그래서 AI 에이전트를 도입할 때는 “어떤 모델을 쓸까”보다 “어디까지 시켜도 되는가”를 먼저 정해야 한다. 아래 체크리스트는 개발팀, 보안팀, 기획팀이 함께 보기 좋은 기준으로 정리했다.

 

1. AI 에이전트 보안은 권한 범위부터 정해야 한다

AI 에이전트에서 가장 먼저 볼 부분은 성능이 아니라 권한이다. 에이전트가 할 수 있는 일이 많아질수록 사고가 났을 때 피해 범위도 넓어진다.

특히 업무 자동화 에이전트는 메일, 문서 저장소, CRM, 결제 시스템, 사내 위키, 클라우드 콘솔과 연결되는 경우가 많다. 이때 “직원 계정 하나를 그대로 연결”하는 방식은 위험하다.

 

AI 에이전트 보안 체크리스트의 앞부분은 이렇게 잡는 편이 안전하다.

1. 최소 권한 원칙: 에이전트에게 필요한 권한만 준다. 읽기만 필요한 작업에 쓰기 권한을 주지 않는다.
2. 역할 분리: 조회용 에이전트, 작성용 에이전트, 승인용 에이전트를 구분한다.
3. 고위험 작업 제한: 결제, 삭제, 외부 발송, 권한 변경은 자동 실행하지 않고 사람의 확인을 거친다.
4. 임시 권한 사용: 장기간 유지되는 고정 토큰보다 만료 시간이 있는 인증 방식을 우선 검토한다.
5. 접근 대상 목록화: 어떤 API, 어떤 데이터베이스, 어떤 파일 저장소에 접근하는지 문서로 남긴다.

여기서 헷갈리기 쉬운 부분은 “로그인만 안전하면 되는 것 아닌가”라는 생각이다. AI 에이전트는 로그인 이후의 행동이 더 중요하다. 사용자가 악성 프롬프트를 넣거나, 외부 문서 안에 숨겨진 지시문이 들어가거나, 연결된 도구가 예상 밖으로 호출될 수 있다.

OWASP의 Agentic AI 보안 논의에서도 목표 탈취, 도구 오남용, 정체성 악용 같은 위험이 핵심 항목으로 다뤄진다. 결국 에이전트 보안은 모델만 막는 문제가 아니라 도구 사용 권한을 어떻게 제한할 것인가의 문제다.

 

2. 프롬프트와 데이터는 따로 보호해야 한다

AI 에이전트 보안에서 자주 빠지는 부분이 데이터 흐름이다. 입력 프롬프트, 시스템 프롬프트, 검색 문서, 업로드 파일, 대화 기록, 에이전트 메모리는 서로 다른 위치에 저장될 수 있다.

특히 에이전트가 장기 기억 기능을 쓰거나 벡터DB를 연결하면 보안 점검 범위가 넓어진다. 일반 앱처럼 DB만 보면 끝나는 구조가 아니다.

 

점검 항목	확인할 내용	놓치기 쉬운 위험
입력 데이터	사용자가 넣는 문장과 파일	개인정보나 내부 문서 유입
시스템 프롬프트	에이전트의 기본 지시문	외부 노출 시 우회 공격 가능
검색 데이터	RAG 문서와 벡터DB	오래된 권한 문서 재사용
메모리	대화 기록과 장기 기억	민감 정보가 계속 남을 가능성
출력 결과	메일, 문서, API 응답	외부 발송 전 검수 누락

 

CISA는 AI 데이터 보안 안내에서 AI 결과의 정확성, 무결성, 신뢰성에 데이터 보안이 중요하다고 설명한다. 이 말은 AI 에이전트에도 그대로 적용된다. 에이전트가 잘못된 데이터나 변조된 문서를 믿으면, 이후 행동도 틀어질 수 있다.

 

체크할 부분은 다음과 같다.

1. 민감 정보 필터링: 주민등록번호, 계좌번호, 고객 정보, 인증키가 프롬프트와 로그에 남지 않게 한다.
2. 시스템 프롬프트 보호: 내부 정책, 우회 방지 지시문, 도구 호출 조건이 외부에 그대로 노출되지 않게 한다.
3. RAG 문서 권한 동기화: 사용자가 볼 수 없는 문서를 에이전트가 대신 읽어 답하지 않도록 한다.
4. 메모리 저장 기준: 무엇을 기억하고 무엇을 저장하지 않을지 사전에 정한다.
5. 로그 보관 기간: 문제 추적에 필요한 기간과 개인정보 보호 기준을 함께 맞춘다.

여기서 중요한 점은 삭제와 저장 중지가 다르다는 것이다. 이미 저장된 대화, 로그, 벡터 데이터 삭제와 앞으로 저장하지 않도록 설정하는 것은 별도 작업이다. AI 에이전트 운영 정책에는 이 둘을 나눠 적어야 한다.

 

3. 도구 호출과 외부 연결은 사람이 볼 수 있어야 한다

AI 에이전트가 위험해지는 순간은 “생각”할 때보다 “행동”할 때다. 검색만 하는 에이전트와 고객에게 메일을 보내는 에이전트는 보안 수준이 달라야 한다.

 

특히 다음 작업은 자동 실행보다 승인 절차를 두는 편이 안전하다.

1. 외부 메일 발송: 고객, 거래처, 언론사 등 외부 수신자에게 나가는 메시지는 검수 단계를 둔다.
2. 파일 삭제와 수정: 원본 파일 삭제, 계약서 수정, 보고서 덮어쓰기는 되돌리기 어렵다.
3. 결제와 구매 요청: 소액이라도 반복 실행되면 비용 사고로 이어질 수 있다.
4. 권한 변경: 사용자 초대, 관리자 권한 부여, API 키 생성은 고위험 작업으로 본다.
5. 외부 API 호출: 어떤 요청을 보냈고 어떤 응답을 받았는지 로그로 남긴다.

이 부분에서 필요한 설정은 휴먼 인 더 루프다. 모든 작업을 사람이 확인하라는 뜻은 아니다. 위험도가 낮은 조회나 초안 생성은 자동화하되, 영향이 큰 실행만 승인하도록 나누는 방식이다.

NIST의 AI 위험 관리 프레임워크도 AI 위험을 조직이 식별하고 관리하는 구조를 강조한다. AI 에이전트에서는 이 구조가 더 현실적이다. 모델 성능 평가만으로는 부족하고, 에이전트가 실제로 어떤 시스템을 움직이는지까지 봐야 한다.

 

4. 운영 전 반드시 볼 보안 리스크와 예외 조건

AI 에이전트는 일반 소프트웨어 보안 점검과 겹치는 부분이 많지만, 에이전트 특유의 예외가 있다. 특히 프롬프트 인젝션, 메모리 오염, 도구 호출 오남용은 기존 웹 보안 점검만으로 잡기 어렵다.

 

운영 전에는 아래 10가지를 하나씩 확인하는 편이 좋다.

1. 권한 최소화: 에이전트 전용 계정을 만들고 필요한 권한만 부여했는지 확인한다.
2. 도구 허용 목록: 에이전트가 호출할 수 있는 API와 플러그인을 목록으로 제한한다.
3. 고위험 작업 승인: 삭제, 결제, 외부 발송, 권한 변경에는 사람의 확인 단계를 둔다.
4. 프롬프트 인젝션 방어: 외부 문서나 웹페이지의 지시문을 그대로 따르지 않도록 정책을 둔다.
5. 데이터 분리: 고객 정보, 내부 문서, 테스트 데이터가 같은 저장소에서 섞이지 않게 한다.
6. 메모리 관리: 장기 기억에 저장되는 항목과 삭제 기준을 명확히 한다.
7. 로그와 감사 추적: 누가, 언제, 어떤 명령을 넣었고 에이전트가 어떤 도구를 호출했는지 남긴다.
8. 출력 검수: 법무, 재무, 보안, 고객 응대처럼 민감한 결과물은 자동 발송하지 않는다.
9. 비상 중지 장치: 이상 행동이 보이면 에이전트 권한과 도구 호출을 즉시 끊을 수 있어야 한다.
10. 정기 재점검: 모델, 플러그인, API, 정책 문서가 바뀔 때마다 보안 설정을 다시 본다.

이 중에서 가장 현실적인 출발점은 도구 허용 목록과 고위험 작업 승인이다. 처음부터 모든 공격을 완벽히 막으려 하기보다, 에이전트가 실제 피해를 만들 수 있는 행동을 먼저 제한하는 것이 낫다.

OWASP의 Agentic AI 관련 자료도 에이전트가 자율적으로 목표를 수행하고 도구를 쓰는 과정에서 새로운 보안 위험이 생긴다는 점을 다룬다. CISA의 Secure by Design 흐름과 함께 보면, AI 에이전트는 나중에 보안을 덧붙이는 방식보다 설계 단계에서 권한, 데이터, 로그, 승인 흐름을 같이 정해야 한다.

 

마치며

AI 에이전트 보안의 핵심은 “똑똑한 모델을 고르는 것”보다 “실수했을 때 어디까지 영향을 줄 수 있는지 제한하는 것”이다. 권한, 데이터, 도구 호출, 로그, 승인 절차만 제대로 잡아도 운영 위험은 크게 줄일 수 있다.

도입 전에는 사내 기준만 보지 말고 NIST, CISA, OWASP의 최신 AI 보안 안내를 함께 확인하는 것이 좋다. 특히 보안 정책, 개인정보 처리, 외부 API 연동 조건은 조직마다 달라질 수 있으므로 공식 안내와 내부 보안 담당 부서 기준에서 최종 확인해야 한다.