AI 에이전트는 사내 데이터를 검색하고, API를 호출하고, 레코드를 수정하고, 메시지를 보내고, 여러 단계로 이어지는 업무 워크플로를 끝까지 수행할 수 있습니다. 이런 능력은 분명한 가치를 만들어내지만, 동시에 보안 사고 하나가 미치는 파급력도 그만큼 커집니다.
챗봇이 잘못된 답을 내놓으면 사용자가 혼란을 겪는 정도로 끝납니다. 그러나 과도한 권한을 가진 에이전트는 기밀 데이터를 유출하거나, 연결된 여러 시스템에 걸쳐 승인되지 않은 작업을 실행할 수 있습니다. 따라서 기업에는 모델이나 프롬프트만이 아니라 에이전트의 전체 수명 주기를 아우르는 보안 통제가 필요합니다.
이 AI 에이전트 보안 체크리스트는 에이전틱 시스템을 안전하게 설계·배포·운영하기 위한 12가지 실무 통제 항목을 정리한 것입니다.
AI 에이전트 보안 체크리스트 한눈에 보기
- 모든 에이전트를 등록하고 담당자를 지정합니다.
- 에이전트마다 전용 아이덴티티를 부여합니다.
- 최소 권한 원칙을 적용합니다.
- 범위가 좁고 검증된 도구만 노출합니다.
- 영향도가 큰 작업에는 사람의 승인을 요구합니다.
- 직접·간접 프롬프트 인젝션을 방어합니다.
- 민감 데이터와 시크릿을 보호합니다.
- 에이전트 실행 환경을 격리합니다.
- 작업과 출력을 결정론적으로 검증합니다.
- 에이전트 워크플로 전체를 로깅하고 모니터링합니다.
- 에이전트를 지속적으로 평가하고 레드팀 테스트를 수행합니다.
- 권한 회수와 사고 대응 절차를 준비합니다.
AI 에이전트가 새로운 보안 위험을 만드는 이유
AI 에이전트는 확률적 추론과 결정론적 업무 시스템에 대한 접근 권한을 결합합니다. 스스로 도구를 고르고, 여러 작업을 연쇄적으로 실행하고, 신뢰할 수 없는 콘텐츠를 읽으며, 사람이 계속 지켜보지 않아도 오랜 시간 동작할 수 있습니다.
여기서 몇 가지 중요한 위험이 생깁니다.
- 에이전트 탈취: 악의적인 지시가 에이전트를 본래 과업에서 다른 방향으로 끌고 갑니다.
- 도구 오용: 에이전트가 정상적인 기능을 안전하지 않거나 승인되지 않은 방식으로 사용합니다.
- 권한 남용: 과도한 권한은 오류나 공격이 발생했을 때의 피해 범위를 넓힙니다.
- 데이터 유출: 민감한 정보가 프롬프트, 출력, 로그, 외부 도구 호출에 섞여 나갑니다.
- 에이전트 난립: 조직이 배포된 에이전트와 자격 증명, 담당자, 연동 현황을 더 이상 파악하지 못합니다.
- 공급망 위험: 모델, 도구, MCP 서버, 플러그인, 데이터 소스가 외부 의존성을 끌어들입니다.
OWASP 에이전틱 애플리케이션 Top 10은 에이전트 행동 탈취, 도구 오용, 아이덴티티 및 권한 남용을 주요 위험으로 꼽습니다. 이런 위협에 대응하려면 아이덴티티, 데이터, 도구, 런타임, 운영 전반에 걸친 통제가 필요합니다.
1. 모든 에이전트를 등록하고 담당자를 지정한다
어떤 에이전트가 있는지 모르면 보호할 수도 없습니다. 다음 정보를 담은 중앙 인벤토리를 유지하세요.
- 에이전트 이름, 용도, 버전, 실행 환경
- 비즈니스 담당자와 기술 담당자
- 사용하는 모델, 도구, 데이터 소스, 외부 서비스
- 접근이 허용된 사용자와 사업 부서
- 위험 등급과 승인된 자율성 수준
- 마지막 보안 검토일과 예정된 폐기일
모든 에이전트에는 그 동작, 권한, 품질, 수명 주기에 책임을 지는 담당자가 실명으로 지정되어 있어야 합니다. 담당자가 없거나 사용되지 않는 에이전트는 비활성화한 뒤 제거해야 합니다.
2. 에이전트마다 전용 아이덴티티를 부여한다
여러 에이전트가 권한이 넓은 관리자 계정 하나를 공유하게 두어서는 안 됩니다. 프로덕션 에이전트마다 고유하고 검증 가능한 아이덴티티를 부여해, 접근 제어 결정과 감사 기록에서 에이전트를 사용자나 다른 서비스와 구분할 수 있게 하세요.
에이전트가 사용자를 대신해 작업할 때는 로그에 두 주체를 모두 남겨야 합니다. 작업을 실행한 에이전트와, 그 작업을 요청한 사람 또는 서비스입니다. 자격 증명은 가능한 한 수명을 짧게 두고 쉽게 회수할 수 있어야 합니다.
Microsoft의 최신 가이드 역시 실명 담당자, 명시적인 권한 범위, 감사 가능성, 검증된 회수 경로를 갖춘 전용 에이전트 아이덴티티를 권장합니다.
3. 최소 권한 원칙을 적용한다
에이전트는 정의된 용도에 필요한 데이터, 도구, 작업에만 접근해야 합니다. 고객 지원 에이전트라면 계정 정보를 조회하고 티켓을 생성할 수는 있지만, 전체 고객 목록을 내보내거나 결제 설정을 바꾸거나 사용자 권한을 관리해서는 안 됩니다.
최소 권한은 여러 층위에서 적용해야 합니다.
- 에이전트 수준: 이 에이전트가 사용할 수 있는 시스템과 도구는 무엇인가?
- 사용자 수준: 요청한 사용자가 접근할 수 있는 데이터는 무엇인가?
- 도구 수준: 허용되는 작업과 파라미터는 무엇인가?
- 데이터 수준: 어떤 테넌트, 레코드, 문서, 필드까지 볼 수 있는가?
- 시간 수준: 상승된 권한이 워크플로 하나가 끝나면 만료되는가?
도구, 워크플로, 담당자, 배포 환경이 바뀔 때마다 실제로 적용되는 권한을 다시 검토하세요.
4. 범위가 좁고 검증된 도구만 노출한다
도구는 모델의 판단을 실제 행동으로 바꾸는 지점이므로 매우 중요한 보안 경계입니다. 범용 기능보다는 업무에 특화된 작은 도구를 우선하세요.
예를 들어 에이전트에 데이터베이스 접근 권한을 통째로 주는 대신, 필드가 검증되는 create_support_ticket을 노출합니다. 프로덕션까지 닿을 수 있는 범용 셸 명령 대신 deploy_preview_environment를 노출합니다.
모든 도구는 다음 조건을 갖춰야 합니다.
- 정확한 설명과 구조화된 입력 스키마를 사용합니다.
- 모든 인자를 서버 측에서 검증하고 정규화합니다.
- 모델과 무관하게 독립적으로 인가를 강제합니다.
- 값, 레코드 수, 호출 빈도, 실행 시간에 한도를 둡니다.
- 시크릿을 노출하지 않는 예측 가능한 오류를 반환합니다.
- 재시도될 수 있는 작업은 멱등성을 보장합니다.
MCP(Model Context Protocol) 연동에서는 토큰 검증, 안전한 세션 관리, 인가 확인, 세션 탈취 방지를 포함한 공식 MCP 보안 모범 사례를 따르세요.
5. 영향도가 큰 작업에는 사람의 승인을 요구한다
모든 에이전트 작업에 승인이 필요한 것은 아닙니다. 그러나 재무, 법무, 보안, 평판에 큰 영향을 미치는 작업은 사람의 통제 아래 두어야 합니다.
에이전트가 다음 작업을 실행하기 전에는 승인을 거치는 것이 적절합니다.
- 외부 이메일이나 공개 메시지를 보낼 때
- 환불, 결제, 구매를 실행할 때
- 데이터를 삭제하거나 되돌릴 수 없게 수정할 때
- 역할, 권한, 보안 설정을 변경할 때
- 소프트웨어를 프로덕션에 배포할 때
- 민감한 정보를 다른 시스템과 공유할 때
확인 화면에는 실행하려는 작업의 정확한 내용, 대상, 영향을 받는 데이터, 사유가 표시되어야 합니다. 사용자는 작업을 거부하거나 수정할 수 있어야 합니다.
6. 프롬프트 인젝션을 방어한다
프롬프트 인젝션은 공격자가 지시문을 통해 에이전트의 행동을 바꾸려는 시도입니다. 특히 간접 프롬프트 인젝션이 중요한데, 악의적인 지시가 문서, 웹 페이지, 이메일, 지원 티켓, 도구 응답 안에 숨어 있을 수 있기 때문입니다.
신뢰할 수 없는 콘텐츠에는 공격이 포함될 수 있다고 전제하고, 여러 겹의 방어를 적용하세요.
- 신뢰할 수 있는 지시와 신뢰할 수 없는 콘텐츠를 명확히 분리합니다.
- 검색된 정보에 출처와 신뢰 수준을 표시합니다.
- 외부 콘텐츠를 처리하는 동안에는 사용 가능한 도구를 제한합니다.
- 비정상적인 계획 변경과 위험한 도구 호출 순서를 탐지합니다.
- 민감한 작업 전에 결정론적 정책 검사를 적용합니다.
- 신뢰할 수 없는 콘텐츠가 외부 작업에 영향을 미쳤다면 사람의 승인을 요구합니다.
방어용 프롬프트만으로는 충분하지 않습니다. 보안 규칙은 모델 바깥에서 강제해야, 에이전트가 콘텐츠를 잘못 해석하더라도 효력을 유지할 수 있습니다.
7. 민감 데이터와 시크릿을 보호한다
에이전트가 처리할 수 있는 정보를 분류하고, 그 정보가 어디까지 이동할 수 있는지 정의하세요. 개인식별정보, 재무 기록, 소스 코드, 계약서, 자격 증명은 각각 다른 통제가 필요할 수 있습니다.
- API 키와 토큰은 서버 측 시크릿 관리자에 보관합니다.
- 원본 자격 증명을 프롬프트나 모델이 볼 수 있는 컨텍스트에 절대 넣지 않습니다.
- 검색 결과를 테넌트, 사용자, 문서, 필드 권한에 따라 필터링합니다.
- 모델을 호출하기 전에 불필요한 민감 필드를 마스킹합니다.
- 전송 중 데이터와 저장 데이터를 모두 암호화합니다.
- 프롬프트, 출력, 트레이스의 보존 및 삭제 정책을 정의합니다.
- 모델 제공업체가 제출된 데이터를 보관하거나 학습에 사용하는지 확인합니다.
로깅은 조사 필요성과 프라이버시 사이에서 균형을 잡아야 합니다. 모든 프롬프트와 도구 결과를 남기면 디버깅에는 도움이 되지만, 접근과 보존을 통제하지 않으면 그 자체가 새로운 민감 데이터 저장소가 됩니다.
8. 에이전트 실행 환경을 격리한다
코드를 실행하거나, 파일을 처리하거나, 웹사이트를 탐색하거나, 의존성을 설치하는 에이전트는 격리된 환경에서 실행해야 합니다. 컨테이너, 샌드박스, 제한된 네트워크 접근, 임시 파일 시스템, 실행 한도를 활용하세요.
런타임은 한 작업이 다른 사용자의 파일이나 자격 증명에 접근하지 못하도록 막아야 합니다. 네트워크 허용 목록으로 통신 대상을 승인된 서비스로 제한할 수 있습니다. 메모리, CPU, 시간, 출력 크기, 에이전트 단계 수에도 한도를 설정하세요.
생성된 코드에 자격 증명을 직접 넘겨서는 안 됩니다. 신뢰할 수 있는 브로커가 승인된 작업을 대신 실행하면, 시크릿을 샌드박스와 모델 컨텍스트 바깥에 둘 수 있습니다.
9. 작업과 출력을 결정론적으로 검증한다
언어 모델은 확률적으로 동작합니다. 업무 제약 조건은 결정론적 코드로 구현해야 합니다.
도구 인자, 데이터베이스 변경, 금액, 수신자, 파일 경로, URL, 데이터 형식, 워크플로 상태 전이를 검증하세요. 허용 목록과 업무 규칙은 에이전트가 처음 계획을 세울 때만이 아니라 실행 직전에도 적용해야 합니다.
생성된 텍스트에 대해서는 필수 항목, 인용 출처, 민감 데이터, 금지 콘텐츠, 불확실성 고지 필요 여부를 확인합니다. 위험도가 높은 출력은 2차 검토자나 사람의 판단을 거쳐야 할 수 있습니다.
10. 에이전트 워크플로 전체를 로깅하고 모니터링한다
기존 애플리케이션 로그는 대개 최종 API 응답만 보여줍니다. 에이전트 보안에는 전체 실행 경로에 대한 가시성이 필요합니다.
- 사용자와 에이전트의 아이덴티티
- 에이전트 버전, 모델, 지시문, 활성화된 도구
- 검색된 출처와 신뢰 등급
- 도구 이름, 검증된 인자, 결과, 오류
- 승인 요청과 사용자의 결정
- 정책에 의한 거부, 재시도, 폴백, 최종 결과
비정상적인 접근, 반복되는 권한 실패, 예상 밖의 도구 호출 순서, 과도한 토큰 또는 작업량, 금지된 시스템 접근 시도, 승인·거부 비율의 급격한 변화에 대해 알림을 설정하세요.
11. 에이전트를 지속적으로 평가하고 레드팀 테스트를 수행한다
보안 테스트에는 실제 워크플로와 적대적 시나리오가 모두 포함되어야 합니다. 다음 항목을 테스트하세요.
- 직접·간접 프롬프트 인젝션
- 승인되지 않은 데이터 요청과 테넌트 간 접근
- 사람의 승인을 우회하려는 시도
- 악의적인 도구 응답과 변조된 문서
- 예상하지 못한 도구 조합과 과도한 자율성
- 출력, 로그, 외부 호출을 통한 데이터 유출
- 서비스 중단, 부분 실패, 재시도 동작
모델, 프롬프트, 도구, 데이터 소스, 정책, 오케스트레이션 로직이 바뀔 때마다 평가 스위트를 실행하세요. NIST의 AI 위험 관리 프레임워크와 생성형 AI 프로파일은 이 수명 주기 전반에서 AI 위험을 관리하고 측정하는 데 유용한 기반이 됩니다.
12. 권한 회수와 사고 대응 절차를 준비한다
모든 프로덕션 에이전트에는 검증된 중단 경로가 있어야 합니다. 팀은 다음을 수행할 수 있어야 합니다.
- 에이전트를 즉시 비활성화합니다.
- 토큰을 회수하고 자격 증명을 교체합니다.
- 전체 시스템을 재배포하지 않고도 도구를 제거하거나 권한을 축소합니다.
- 실행 중인 워크플로를 중단하고 대기 중인 작업을 막습니다.
- 영향을 받은 사용자, 레코드, 외부 시스템을 식별합니다.
- 민감 데이터를 보호하면서 증거를 보존합니다.
- 되돌릴 수 있는 변경은 롤백하고 담당자에게 통보합니다.
누가 알림을 받는지, 누가 에이전트를 일시 중지할 수 있는지, 사고를 어떻게 분류하는지, 언제 법무·컴플라이언스·고객·파트너에게 통지해야 하는지를 정의하세요. 그리고 사고가 일어나기 전에 이 절차를 미리 테스트하세요.
보안 통제의 우선순위를 정하는 방법
에이전트가 미칠 수 있는 영향에서 출발하세요. 읽기 전용 사내 지식 어시스턴트와 자율적으로 움직이는 재무 에이전트에 같은 수준의 통제를 요구할 필요는 없습니다.
- 워크플로 파악: 사용자, 데이터, 도구, 작업, 외부 의존성을 식별합니다.
- 위험 분류: 민감도, 자율성, 되돌릴 수 있는지 여부, 잠재적 피해 범위를 평가합니다.
- 권한 경계 설정: 에이전트가 읽고 실행할 수 있는 범위를 정확히 정의합니다.
- 결정론적 통제 추가: 정책을 모델 바깥에서 강제합니다.
- 테스트와 모니터링: 자율성을 넓히기 전에 정상 동작과 적대적 상황에서의 동작을 모두 검증합니다.
읽기 전용 접근과 위험도가 낮은 작업부터 시작하세요. 워크플로가 안정적으로 동작한다는 것이 입증되고, 조직이 이를 안전하게 모니터링하고 중단할 수 있을 때에만 자율성을 넓혀야 합니다.
자주 묻는 질문
AI 에이전트의 가장 큰 보안 위험은 무엇인가요?
가장 파급력이 큰 위험은 대개 조작된 행동과 과도한 권한이 결합될 때 발생합니다. 에이전트가 민감한 데이터나 강력한 도구에 접근할 수 있으면 프롬프트 인젝션의 위험성은 훨씬 커집니다.
시스템 프롬프트만으로 AI 에이전트를 보호할 수 있나요?
아닙니다. 시스템 지시문은 행동을 유도하는 데 도움이 되지만 결정론적인 보안 경계는 아닙니다. 인증, 인가, 검증, 격리, 승인, 모니터링은 애플리케이션과 연결된 서비스에서 강제해야 합니다.
모든 에이전트 작업에 사람의 승인이 필요한가요?
아닙니다. 위험도가 낮고, 되돌릴 수 있으며, 충분히 테스트된 작업은 자동으로 실행해도 됩니다. 승인은 영향도가 크거나 판단이 모호한 작업에 집중해야, 워크플로를 쓸 수 없게 만들지 않으면서도 감독의 실효성을 유지할 수 있습니다.
에이전트 권한은 얼마나 자주 검토해야 하나요?
권한은 정기적으로 검토하고, 에이전트의 담당자, 범위, 도구, 모델, 데이터 소스, 환경이 바뀔 때마다 다시 검토해야 합니다. 사용하지 않는 접근 권한은 즉시 제거하세요.
MCP 서버는 기본적으로 안전한가요?
MCP는 프로토콜과 인가 기능을 정의할 뿐, 각 서버와 클라이언트는 별도로 안전하게 구현해야 합니다. 민감한 시스템을 연결하기 전에 서버의 소유 주체, 권한, 토큰 처리 방식, 도구 동작, 로깅, 업데이트 정책을 검증해야 합니다.
결론
안전한 AI 에이전트를 만들려면 강력한 모델이나 정성 들여 작성한 프롬프트만으로는 부족합니다. 아이덴티티, 권한, 도구, 데이터, 실행 환경, 검증, 모니터링, 사고 대응에 이르기까지 여러 겹의 방어가 필요합니다.
Nextchain은 맞춤형 AI 에이전트, RAG(검색 증강 생성) 시스템, MCP 연동, 안전한 업무 자동화 구축을 지원합니다. 귀사의 보안 및 운영 요구 사항에 맞는 AI 에이전트 아키텍처를 함께 설계하고 싶다면 Nextchain에 문의하세요.
