AI 에이전트 보안 가이드: 자동화 전에 점검할 7가지

AI 에이전트에게 메일 발송·코드 배포·고객 데이터 조회 권한을 줄 생각이라면, 먼저 멈춰야 합니다. 문제는 에이전트가 틀린 답을 낼 수 있다는 수준이 아닙니다. 에이전트는 도구를 호출하고 실제 시스템을 움직일 수 있어, 한 번의 잘못된 지시나 권한 설정이 곧 운영 사고로 이어질 수 있습니다. 이 글은 최근 공식 보안 권고를 바탕으로 ‘에이전트를 써도 되는 업무’와 ‘아직 사람 승인이 필요한 업무’를 구분합니다.

AI 에이전트와 챗봇은 무엇이 다른가

일반 챗봇은 질문에 답하거나 초안을 만드는 데 주로 머뭅니다. 반면 AI 에이전트는 목표를 받아 계획을 세우고, 파일·브라우저·API·데이터베이스 같은 도구를 선택해 여러 단계를 실행합니다. 생산성이 커지는 이유도 여기에 있지만, 위험도 같은 지점에서 커집니다. 잘못된 답변은 사람이 고치면 되지만, 잘못된 실행은 되돌리기 어렵거나 외부 시스템에 영향을 줄 수 있습니다.

영국 NCSC는 최근 에이전트형 AI를 도입할 때 자율성이 클수록 오작동·권한 오남용·의도 밖 행동의 영향이 커진다고 경고했습니다. 핵심은 AI가 특별히 ‘악의적’이어서가 아닙니다. 사람처럼 상식으로 맥락을 보완하지 못하는 시스템에 광범위한 권한과 모호한 목표를 동시에 주는 설계가 위험한 것입니다.

오늘의 핵심: 모델 안전장치만 믿으면 안 된다

많은 팀이 “상용 모델의 안전 필터가 있으니 괜찮다”고 생각합니다. 이 판단은 불완전합니다. 모델 내부의 보호 기능은 하나의 방어선일 뿐이며, 프롬프트 인젝션·도구 연결 설정·유출된 인증정보·잘못 열린 네트워크 경로를 모두 막아주지 못합니다. NCSC도 내장 안전장치를 전체 보안 체계로 취급해서는 안 된다고 명시합니다.

최근 공개된 사례는 이 구분을 더 선명하게 합니다. OpenAI는 제3자 사이버 평가 중 테스트 환경의 인터넷 접근 설정 오류로 모델이 실제 사이트에 닿은 사례를 설명했습니다. 회사의 설명에 따르면 이는 일반 공개 환경의 동작을 그대로 보여주는 사례는 아니며, 고도화된 샌드박스 탈출도 아니었습니다. 그러나 반대로 말하면, 에이전트의 위험은 모델 능력만이 아니라 주변 환경의 작은 구성 오류와 결합해 커질 수 있다는 뜻입니다.

사실과 해석을 나누면 이렇습니다.

확인된 사실: NCSC는 에이전트 도입 시 최소 권한, 샌드박스, 실시간 관찰, 중단 수단을 권고합니다. OpenAI는 특정 평가 환경에서 구성 오류와 인터넷 접근이 의도 밖 활동의 조건이 됐다고 공개했습니다.

해석: 따라서 ‘에이전트 도입 여부’보다 ‘어디까지 실행 권한을 줄 것인가’가 실제 보안 의사결정의 중심입니다. 모든 자동화가 위험하다는 결론은 과장이고, 무제한 권한을 준 자동화가 위험하다는 결론은 근거가 충분합니다.

에이전트를 도입해도 되는 업무, 아직 이른 업무

먼저 시작하기 좋은 영역

반복적이고 결과를 쉽게 검수할 수 있으며, 실패해도 되돌릴 수 있는 작업이 우선입니다. 예를 들어 공개 문서 요약, 사내 지식 검색의 초안 작성, 테스트 환경의 이슈 분류, 읽기 전용 데이터에서의 보고서 초안이 여기에 해당합니다. 이 경우에도 데이터 범위와 도구 호출 범위는 명시적으로 제한해야 합니다.

사람 승인을 남겨야 하는 영역

고객에게 메시지를 보내거나, 비용이 발생하는 구매를 하거나, 운영 서버를 바꾸거나, 권한을 부여·회수하거나, 민감 데이터를 외부로 전송하는 일은 기본적으로 승인 단계가 필요합니다. ‘매번 사람을 거치면 자동화의 의미가 없다’는 반론이 있을 수 있습니다. 맞는 말이지만, 그 해결책은 승인을 없애는 것이 아니라 승인 조건을 좁히고 저위험 작업부터 자동화하는 것입니다.

도입 전 7문항 체크리스트

• 목표: 에이전트가 해야 할 일과 절대 하면 안 되는 일을 한 문장씩 정의했는가?
• 권한: 전용 계정과 최소 권한, 짧은 만료 시간의 인증정보를 사용했는가?
• 데이터: 에이전트가 읽을 수 있는 폴더·DB·SaaS 데이터를 업무에 필요한 범위로만 제한했는가?
• 네트워크: 기본 차단 후 필요한 도메인·API만 허용 목록으로 열었는가?
• 실행: 삭제·배포·결제·외부 발송처럼 되돌리기 어려운 행동은 사람 승인을 거치게 했는가?
• 관찰: 어떤 도구를 언제 호출했는지와 실패·우회 시도를 추적할 로그가 남는가?
• 중단: 이상 행동이 보일 때 프로세스뿐 아니라 네트워크·토큰까지 즉시 끊을 수 있는가?

‘AI 에이전트가 보안을 해결한다’는 주장도 경계해야 한다

AI는 취약점 탐색, 로그 분류, 반복 대응을 빠르게 해 보안팀의 생산성을 높일 수 있습니다. 하지만 이것이 보안 인력을 대체하거나 기존 보안 부채를 자동으로 해결한다는 뜻은 아닙니다. 에이전트가 더 많은 시스템에 접근할수록 잘못된 행동의 폭발 반경도 넓어집니다. 관찰되지 않는 자동화는 효율이 아니라 숨겨진 위험일 수 있습니다.

이 주장의 한계도 분명합니다. 모든 조직이 최고 수준의 격리 환경을 구축할 필요는 없습니다. 읽기 전용의 좁은 업무라면 과도한 통제가 오히려 도입을 막을 수 있습니다. 통제 수준은 업무의 피해 규모와 자율성에 비례해야 합니다. 다만 고객 데이터·금전·운영 인프라에 연결되는 순간에는 ‘일단 돌려보고 문제 생기면 고친다’는 접근의 비용이 지나치게 커집니다.

결론: 지금 필요한 것은 AI 에이전트를 막연히 도입하거나 막연히 두려워하는 일이 아닙니다. 낮은 위험 업무에서 시작하고, 최소 권한·샌드박스·승인·로그·즉시 중단을 설계한 뒤 자율성을 단계적으로 넓혀야 합니다. 에이전트의 성능 데모보다 이 다섯 가지를 답하지 못한다면, 그 자동화는 아직 운영 환경에 올릴 준비가 안 됐습니다.

확인한 출처
· 영국 NCSC, Managing the cyber risk of agentic AI
· 영국 NCSC, Thinking carefully before adopting agentic AI
· OpenAI, Third-party cyber evaluations involving OpenAI models
2026년 9월 15일 기준. 각 서비스의 실제 보안 설정과 기능은 제품·배포 환경에 따라 다릅니다.