[에이전트와 보안③] AI 에이전트, 어떻게 통제해야 하나?

인공지능(AI) 시대의 사이버보안 논의가 전 세계를 뜨겁게 달구고 있습니다. 앤트로픽의 ‘클로드 미토스 프리뷰’와 오픈AI의 ‘GPT-5.4-사이버’ 공개로 AI 모델의 취약점 탐지 능력이 주목 받는 가운데, 업무 현장에서는 AI 에이전트가 메일과 문서, 데이터베이스, 외부 도구에 접근해 실제 작업을 처리하기 시작했습니다. AI 에이전트의 자율성이 높아질수록, 보안이 통제해야 할 권한과 연결 지점은 더욱 늘어납니다. 이번 기획에서는 AI 에이전트가 왜 새로운 보안 과제로 떠올랐는지, 어떤 위험이 드러나고 있는지, 이를 통제하기 위한 기술과 정책, 거버넌스 해법을 차례로 짚어봅니다. [편집자주]

[에이전트와 보안①] AI 에이전트 시대, 보안의 초점이 바뀐다
[에이전트와 보안②] AI 에이전트 보안 위협 현실화…메일 삭제부터 코드 실행까지
[에이전트와 보안③] AI 에이전트, 어떻게 통제해야 하나 (이번호)
[에이전트와 보안④] AI 에이전트 보안, 거버넌스도 중요하다 (다음호)

메일을 읽고, 문서를 찾고, 외부 도구를 호출해 일을 처리하는 AI 에이전트는 이미 업무 환경에 들어왔다. AI 에이전트는 단순히 답을 내놓는 도구가 아니라 권한을 가진 실행 주체다. 그만큼 보안도 모델의 답변을 점검하는 수준에서 멈춰서는 안 된다. AI 에이전트를 통제하려면 먼저 어떤 에이전트가 어디에서 쓰이고 있는지 알아야 한다. 이후 어떤 권한을 줄 것인지, 어떤 도구와 연결할 것인지, 어떤 환경에서 실행할 것인지 정해야 한다. 위험한 입력과 출력은 중간에서 걸러야 하고, 실행 환경은 격리해야 한다. 어떤 행동을 했는지 추적할 수 있는 로그와 배포 전 시험 평가도 필요하다.

보이지 않는 에이전트부터 찾아야 한다

AI 에이전트 통제의 출발점은 ‘가시성’이다. 기업은 먼저 어떤 에이전트가 존재하는지 알아야 한다. 누가 만들었고, 어떤 업무에 쓰이며, 어떤 모델과 애플리케이션에 연결돼 있는지 파악하지 못하면 이후 통제도 어렵다. 문제는 에이전트를 만드는 방식이 쉬워졌다는 점이다. 직원은 자연어 몇 줄로 특정 업무를 처리하는 에이전트를 만들 수 있다. 문서 요약, 코드 검토, 회의록 정리, 데이터 조회처럼 작은 자동화가 부서 단위로 빠르게 늘어날 수 있다. 회사가 공식으로 배포한 에이전트만 관리해서는 전체 사용 현황을 보기 어렵다.

이런 상태에서는 섀도우 AI가 생기기 쉽다. 섀도우 AI는 회사가 승인하거나 관리하지 않은 AI 도구와 에이전트를 뜻한다. 어떤 직원이 개인 계정으로 외부 AI 서비스를 쓰고, 그 서비스에 내부 문서나 고객 정보를 넣어도 보안팀이 알지 못하면 데이터 유출 여부를 확인하기 어렵다. 사고가 나더라도 어떤 입력이 들어갔고, 어떤 응답이 나왔고, 어떤 후속 작업이 실행됐는지 추적하기 힘들다.

마이크로소프트는 지난 2월 공개한 보안 블로그에서 포춘 500대 기업의 80% 이상이 저코드·노코드 도구로 만든 활성 AI 에이전트를 사용하고 있다고 밝혔다. 동시에 많은 조직이 몇 개의 에이전트가 돌아가고 있는지, 누가 소유자인지, 어떤 데이터를 다루는지조차 답하기 어렵다고 지적했다. 마이크로소프트는 이를 해결하기 위해 중앙 등록소, 접근제어, 대시보드와 원격 측정, 상호운용성, 보안 신호를 핵심 관리 요소로 제시했다.

따라서 기업은 에이전트 목록부터 만들어야 한다. 어떤 에이전트를 허용할지, 어떤 모델과 앱만 연결할지, 개인용 AI 사용은 어디까지 제한할지 정해야 한다. 허용된 에이전트는 소유자, 목적, 연결 시스템, 처리 데이터, 로그 보관 기준을 함께 등록해야 한다. 에이전트가 많아질수록 이런 목록과 운영 기준은 보안 관리의 기본 자료가 된다.

실행 과정도 보여야 한다. 에이전트가 어떤 문맥을 읽었고, 어떤 도구를 호출했고, 어떤 결과를 냈는지 기록해야 한다. 다만 에이전트의 상호작용은 대부분 자연어와 로그 형태로 남는다. 양이 많고 여러 서비스가 동시에 얽히면 사람이 수동으로 따라가기 어렵다. 이 때문에 입력과 실행 경로를 한곳으로 모아보고, 이상 행동을 자동으로 탐지하는 구조가 필요하다.

금융보안원은 지난 16~17일 열린 ‘정보통신망 정보보호 컨퍼런스(NetSec-KR) 2026’에서 AI 에이전트 시스템을 입력, 게이트웨이, 런타임, 도구, 응답 흐름으로 나눠 설명했다. 이 구분은 가시성 확보에도 그대로 적용된다. 입력 단계에서는 어떤 채널로 요청이 들어왔는지 봐야 한다. 게이트웨이에서는 인증과 세션 정보를 남겨야 한다. 런타임에서는 모델이 어떤 문맥을 조합했는지 확인해야 한다. 도구 호출 단계에서는 어떤 기능이 실행됐는지 추적해야 한다.

가시성은 안전한 에이전트를 위한 거버넌스의 출발점이다. 허용된 AI만 쓰게 하고, 에이전트 목록을 관리하고, 실행 로그를 남기고, 이상 행동을 탐지해야 한다. 보이지 않는 에이전트는 통제할 수 없다. 통제되지 않는 자동화는 업무 효율이 아니라 새로운 위협이 된다.

에이전트 통제의 시작은 권한 관리

에이전트를 찾아냈다면 다음은 권한을 나누는 일이 중요하다. 에이전트는 단순히 답을 내놓는 챗봇이 아니다. 파일을 읽고, 데이터를 꺼내고, 외부 애플리케이션 프로그래밍 인터페이스(API)를 호출하고, 실제 작업을 실행한다.

이상근 고려대학교 정보보호대학원 교수는 “AI 에이전트 보안의 화두가 ‘권한 위임’에 있다”며 “기존 생성형 AI에 도구 사용과 실행 기능이 붙으면서, 사람이 하던 일을 에이전트가 대신하도록 권한을 넘겨받는 구조가 됐다”고 설명했다.

이 교수는 이 과정에서 권한 상승과 자격증명 문제가 생길 수 있다고 봤다. 사용자는 특정 범위 안에서만 권한을 줬다고 생각하지만, 에이전트가 잘못된 문맥이나 공격 입력을 만나면 더 넓은 권한을 행사하거나 의도하지 않은 행동을 할 수 있다는 것이다. 사람이 가진 권한을 에이전트에 그대로 넘기면 위험이 커지는 이유다.

권한 통제 방법으로는 역할 기반 접근제어(RBAC)만으로는 부족하다는 지적이 나온다. 기존 역할 기반 접근제어는 ‘관리자’, ‘개발자’, ‘인사 담당자’처럼 역할을 기준으로 권한을 나눈다. 하지만 보안 전문가들은 AI 에이전트 환경에서는 같은 관리자 권한이라도 에이전트가 할 수 있는 행동을 별도로 제한해야 한다고 본다. 예를 들어 사용자는 저장소를 공개로 바꿀 수 있어도, 그 사용자의 에이전트는 저장소 내용을 읽기만 하게 할 수 있다. 사용자는 전사 메일을 보낼 수 있어도, 에이전트는 초안 작성까지만 허용하고 발송은 사람 승인을 거치게 할 수 있다.

오펜시브 보안 전문기업인 티오리는 이를 FIGS 프레임워크의 첫 번째 축인 ‘세밀한 권한 통제(Fine-Grained Authorization)’로 설명한다. FIGS는 티오리가 제시한 AI 에이전트를 위한 보안 프레임워크로 ▲세밀한 권한 통제 ▲신원 검증(Identity) ▲가드레일(Guardrails) ▲샌드박스(Sandboxing)의 앞 글자를 묶은 개념이다.

박관순 티오리 최고정보보호책임자(CISO)는 “사람에게 주어진 권한을 에이전트에 그대로 넘기는 것이 아니라, 사용자 권한과 에이전트 권한의 교집합만 허용하는 구조가 필요하다”고 짚는다. 최고 권한자가 쓰는 에이전트라도 저장소 공개, 계정 삭제, 전사 메일 발송 같은 행동을 자동으로 할 수 없게 해야 한다는 뜻이다.

티오리에 따르면, AI 에이전트의 실행 권한은 기본적으로 읽기 전용에서 시작하는 방식이 안전하다. 에이전트가 처음부터 수정, 삭제, 발송, 외부 전송 권한을 갖지 않게 하고, 위험도가 높은 작업은 단계적으로 승인을 받게 해야 한다. 내부 문서 검색이나 요약은 자동으로 처리하더라도, 외부 메일 발송, 권한 변경, 계정 삭제, 저장소 공개, 결제, 배포 같은 작업은 사람 승인이나 추가 인증을 거치게 하는 식이다.

티오리는 권한을 오래 유지하지 않는 것도 중요하다고 봤다. 에이전트가 특정 작업을 수행할 때만 짧은 시간 동안 필요한 권한을 받고, 작업이 끝나면 바로 회수하는 구조가 필요하다. 장기 토큰이나 고정된 접근키를 에이전트에 붙여두면, 에이전트가 탈취됐을 때 공격자가 같은 권한을 계속 쓸 수 있다. 박 CISO는 “작업 단위의 임시 권한, 짧은 수명의 토큰, 특정 도구에만 적용되는 제한된 권한 범위가 필요하다”고 했다.

권한을 판단하는 지점과 실행하는 지점을 나누는 방식도 활용할 수 있다. 정책 결정 지점(PDP)은 이 에이전트가 이 데이터를 읽어도 되는지를 판단하고, 정책 집행 지점(PEP)은 실제 도구 호출이나 데이터 접근을 막거나 허용한다. 박 CISO는 “에이전트가 직접 모든 권한을 들고 움직이는 것이 아니라, 중간 정책 계층이 매번 ‘이 행동을 해도 되는지’ 확인하는 구조”라며 “이런 구조를 두면 프롬프트 인젝션으로 에이전트가 이상한 명령을 받아도, 정책 계층에서 차단할 수 있다”고 설명했다.

마이크로소프트는 지난 2월 10일 자사 보안 블로그에서 공개한 ‘사이버 펄스(Cyber Pulse)’ 관련 글에서 “AI 에이전트에도 사람이나 서비스 계정과 같은 보안 기준을 적용해야 한다”고 설명했다. 이를 위해 필요한 권한만 부여하는 최소권한, 신원·기기·위치·위험 수준을 확인하는 명시적 검증, 침해를 전제로 한 설계 원칙을 제시했다.

신원·가드레일·샌드박스로 실행을 통제해야 한다

권한을 나눴다면 다음은 에이전트의 실행 방식 자체를 검증하는 단계다. 티오리는 FIGS 프레임워크에서 신원 검증, 가드레일, 샌드박스를 세밀한 권한 통제 외에 필요한 AI 에이전트 보안의 핵심 축으로 제시했다. 에이전트가 허용된 서버나 클라우드에서 실행되는지, 정해진 컨테이너와 계정 안에서 동작하는지, 실행 파일이 변조되지 않았는지 확인해야 한다는 접근이다.

신원 검증 영역에서는 스파이피(SPIFFE)와 스파이어(SPIRE) 같은 오픈소스 표준 기반 방식이 거론된다. 스파이피는 소프트웨어 워크로드의 신원을 정의하는 규격이고, 스파이어는 이를 구현한 런타임이다. 클라우드 네이티브 컴퓨팅 재단(CNCF)은 스파이피와 스파이어를 졸업 프로젝트로 분류하고 있다. 스파이어는 등록된 조건에 맞는 워크로드를 검증한 뒤 스파이피 아이디와 짧은 수명의 신원 증명서(SVID)를 발급한다. 장기 비밀번호를 코드나 환경변수에 오래 두는 대신, 실행 위치와 조건을 검증한 뒤 제한된 시간 동안만 자격증명을 주는 방식이다.

이상근 교수도 에이전트 보안에서 비인간 신원 관리가 중요해진다고 봤다. 그는 “사람이 아닌 에이전트가 누구에게 권한을 위임받았는지, 다른 시스템이 그 신원을 어떻게 믿을 것인지가 새 과제가 됐다”고 설명했다. 에이전트가 사람을 대신해 여러 도구를 호출하는 구조에서는 사람 계정 관리만으로는 부족하다는 것이다.

입출력 단계에서는 가드레일이 대응 기술로 제시된다. 가드레일은 단순 금칙어 필터가 아니다. 사용자가 넣은 프롬프트, 에이전트가 읽는 문서, 모델이 내놓는 응답, 외부 도구 호출 요청을 중간에서 점검하는 방어 계층에 가깝다. 오픈AI는 에이전트형 AI의 프롬프트 인젝션이 단순 문자열 차단 문제를 넘어 사회공학과 비슷한 양상으로 진화하고 있다고 설명한다. 웹페이지, 이메일, 문서 안의 숨은 지시가 에이전트의 이상한 행동으로 이어질 수 있기 때문에, 입력 필터 외에 가드레일 같은 안전장치가 필요하다는 것이다.

AI 보안 전문 스타트업 에임인텔리전스는 가드레일을 AI 에이전트 통제의 핵심 장치로 본다. 유상윤 에임인텔리전스 대표는 “AI가 무엇을 보고 어떤 출력을 내며 어디까지 행동할 수 있는지에 대한 관리 체계가 아직 뒤처져 있다”며 “입력과 출력 전 단계에서 유해 행위를 차단하는 실시간 AI 방화벽이 필요하다”고 설명한다. AI 방화벽 같은 가드레일을 세워 유해 입력과 출력, 환각, 민감 데이터 노출을 점검하는 방식이 중요하다는 것이다.

가드레일 구현 사례로는 엔비디아의 ‘네모 가드레일(NeMo Guardrails)’이 있다. 네모 가드레일은 입력·출력 레일과 주제 제한 방식으로 대규모언어모델(LLM) 애플리케이션의 동작을 제어하는 오픈소스 도구다. 위험한 입력을 막고, 민감정보가 포함된 출력을 줄이며, 정해진 업무 범위를 벗어난 응답을 제한하는 방식이다.

실행 환경을 격리하는 ‘샌드박스’도 AI 에이전트를 통제하는 방법 중 하나로 제시된다. 티오리는 FIGS 프레임워크의 한 축으로 샌드박스를 꼽았다. 에이전트가 코드를 실행하고 외부 시스템과 연결되면, 프롬프트 인젝션이나 오판이 실제 원격 코드 실행으로 이어질 수 있기 때문이다. 샌드박스는 에이전트가 실행되는 공간을 다른 시스템과 분리하고, 필요한 시간 동안만 열었다가 작업이 끝나면 닫는 격리 환경이다.

박 CISO는 “일반 컨테이너보다 강한 격리가 필요한 경우 웹어셈블리(WASM) 샌드박스나 마이크로VM(MicroVM) 같은 방식도 검토할 수 있다”고 설명했다. 웹어셈블리는 원래 웹 브라우저에서 프로그램을 안전하게 실행하기 위해 쓰이던 기술이다. 운영체제 기능에 직접 접근하지 못하도록 제한된 실행 공간을 만들 수 있어, 에이전트가 작은 코드나 도구를 실행할 때 공격 표면을 줄이는 데 활용할 수 있다. 마이크로VM은 작은 가상 서버를 띄워 그 안에서 작업을 실행하는 방식이다. 웹어셈블리보다 무겁지만 격리 수준이 높고, 파이썬 라이브러리나 복잡한 분석 작업을 수행하기 쉽다.

엔비디아도 실행 계층을 분리하는 샌드박스 방식의 구현 사례를 제시했다. 엔비디아는 최근 네모클로(NemoClaw)라는 오픈소스 스택을 통해 항상 켜져 있는 AI 에이전트를 더 안전하게 실행하는 방식을 소개했다. 스택은 여러 기술 구성요소를 묶은 실행 체계를 뜻한다. 네모클로의 핵심 구성요소인 오픈셸(OpenShell)은 에이전트 밖에서 정책을 집행하는 런타임이다. 에이전트가 직접 파일 수정, 명령 실행, 외부 전송 같은 권한을 들고 움직이는 대신, 오픈셸이 중간에서 행동을 허용할지를 판단한다. 샌드박스 실행, 세밀한 권한 통제, 개인정보 보호 라우팅도 이 계층에서 처리한다.

레드팀 평가로 실제 방어력을 검증해야 한다

앞서 살펴본 가시성 확보, 권한 분리, 신원 검증, 가드레일, 샌드박스는 AI 에이전트 통제를 위한 기본 장치다. 하지만 이런 장치를 갖췄다고 해서 안전성이 곧바로 입증되는 것은 아니다. 실제 공격자가 메일 본문에 숨은 지시를 넣었을 때 가드레일이 막는지, 에이전트가 권한 밖의 도구를 호출하려 할 때 정책 계층이 차단하는지, 샌드박스가 실행 환경을 제대로 격리하는지는 실제로 시험해봐야 한다.

이상근 교수는 이 지점에서 ‘시험 기반 평가’가 필요하다고 강조한다. 제로 트러스트 같은 원칙은 방향성으로는 유효하지만, 실제 보안 수준은 구체적인 공격 시나리오를 넣어봐야 확인할 수 있다는 것이다. 그는 “기존 인증 체계를 자동차에 범퍼와 에어백이 있는지 확인하는 절차로 볼 수 있다”며 “반면 시험 기반 평가는 실제 충돌 시험을 해서 탑승자가 얼마나 보호되는지 확인하는 방식에 가깝다”고 설명했다.

에이전트 보안에서도 마찬가지다. 이 교수는 “실험 기반의 평가가 에이전트에도 적용되어야 한다”며 “간접 프롬프트 인젝션, 권한 남용, 도구 오용, 공급망 취약점, 예상치 못한 코드 실행 같은 상황을 실제로 재현해 보고, 어느 수준까지 막는지 점수화해야 한다”고 했다. 보안 원칙을 적용했다는 것보다, 공격을 넣었을 때 실제로 멈추는지를 확인하는 절차가 더 중요하다는 말이다.

소프트웨어 보안 강화를 위해 활동하는 전 세계적인 비영리 재단 ‘OWASP(Open Worldwide Application Security Project)’는 지난해 12월 ‘에이전트 애플리케이션 톱10’을 공개해 자율형·도구형 AI 시스템의 핵심 위험을 정리했다. 목표 하이재킹, 도구 오남용, 신원·권한 남용, 공급망 취약점, 예상치 못한 코드 실행, 메모리와 문맥 오염 등이 포함됐다. 이런 분류는 에이전트별 시험 시나리오를 만들 때 기준점으로 활용할 수 있다.

NetSec-KR 2026에서도 비슷한 진단 방식이 제시됐다. 이태진 가천대학교 스마트보안학과 교수는 ‘자동화된 에이전틱 AI 보안 취약성 및 방어 수준 진단’ 발표에서 노트북LM, 코파일럿, 오픈클로 같은 실제 에이전트형 서비스를 대상으로 간접 프롬프트 인젝션 공격 성공 여부를 점검하는 방식을 소개했다. 그는 “로그 분석이 가능한 환경에서는 그레이박스 방식으로, 내부 구조를 보기 어려운 상용 서비스에는 블랙박스 방식으로 취약성을 점검할 수 있다”고 설명했다.

운영 단계까지 자동화해야 통제가 완성된다

레드팀 평가로 AI 에이전트의 보안 취약점을 확인했다면, 다음 과제는 운영 자동화다. 배포 전 점검을 통과한 에이전트라도 실제 업무 환경에서는 계속 바뀐다. 연결되는 도구가 늘고, 접근하는 데이터가 달라지고, 플러그인과 모델, 실행 환경도 업데이트된다. 따라서 에이전트 보안은 한 번의 점검으로 끝나지 않는다.

운영 단계에서는 먼저 에이전트가 연결한 자산을 계속 파악해야 한다. 어떤 에이전트가 어떤 파일시스템, 데이터베이스, 애플리케이션 프로그래밍 인터페이스(API), 모델 컨텍스트 프로토콜(MCP) 서버, 플러그인과 연결돼 있는지 알아야 한다. 연결 지점을 모르면 취약점이 발견돼도 어떤 에이전트가 영향을 받는지 판단하기 어렵다.

패치도 같은 문제다. 에이전트 자체의 런타임, 연결된 도구, 플러그인, 샌드박스, API 서버 중 어느 한 곳에 취약점이 생기면 전체 실행 경로가 위험해질 수 있다. 취약점을 찾아도 적용이 늦으면 방어 효과는 제한적이다. 서비스 중단이 두려워 패치를 미루면, 탐지와 분석이 빨라져도 실제 위험은 계속 남는다.

이상근 교수는 “두뇌만 AI고 손발은 잘려 있으면 의미가 없다”며 “취약점을 찾고 패치를 만드는 AI가 있어도, 자산 식별과 영향성 평가, 패치 적용이 사람 손에만 묶여 있으면 공격 속도를 따라갈 수 없다”고 강조했다. 그는 “보안 운영 자동화는 에이전트 보안의 마지막 단계로 볼 수 있다. 에이전트 목록을 관리하고, 연결 자산을 식별하고, 취약점이 어느 경로에 영향을 주는지 평가해야 한다. 이후 패치 적용, 권한 회수, 세션 차단, 도구 비활성화 같은 조치까지 빠르게 이어져야 한다”고 덧붙였다.

글. 바이라인네트워크
<곽중희 기자>god8889@byline.network