인공지능(AI)이 기업의 업무시스템에 깊숙이 들어오면서 보안의 관점도 달라지고 있다. 이제는 AI 모델이 얼마나 안전한 답변을 생성하는지만으로 보안 수준을 판단하기 어렵다. AI 에이전트가 어떤 정보를 읽고, 어떤 시스템에 연결되며, 어느 범위까지 실제 작업을 수행할 수 있는지가 새로운 보안 과제로 떠올랐다.
조직 내부로 들어온 AI 에이전트와 연결된 자산 및 권한을 어떻게 관리할 것인지 살펴본다.
금융권에서도 이러한 변화가 나타나고 있다. 망분리 규제 개선 이후 자산관리와 심사, 고객상담 등에 AI 활용이 확대되고 있으며, AI 에이전트가 여러 업무를 연속적으로 수행하거나 기존 업무시스템과 연동하는 사례도 늘어나는 추세다.
AI 보안은 모델 자체를 보호하는 데 그쳐서는 안 된다. AI가 접근하는 데이터와 업무시스템, 응용프로그램인터페이스(API), 서비스 계정, 인증 토큰까지 관리 범위에 포함해야 한다. 결국 AI 시대의 보안 역시 자산에 대한 가시성을 확보하는 데서 시작한다.
AI가 바꾸는 공격과 방어의 속도
AI는 기존 사이버 공격의 속도를 높이는 동시에 새로운 침해 경로를 만들어내고 있다.
피싱과 취약점 악용, 계정 탈취, 공급망 침해 등 공격의 기본 원리는 크게 달라지지 않았다. 그러나 공격자는 AI를 활용해 더 적은 비용으로 많은 표적을 탐색하고 다양한 공격 방식을 반복적으로 시험할 수 있게 됐다.
취약점 탐색 분야에서도 변화가 나타나고 있다. 구글 딥마인드와 구글 프로젝트 제로가 공동 개발한 AI 에이전트 '빅 슬립(Big Sleep)'은 실제 소프트웨어에서 알려지지 않은 취약점을 탐색하는 데 활용됐다. 구글은 빅 슬립이 취약점을 발견하고 위협 인텔리전스와 연계해 악용 가능성이 높은 취약점에 선제적으로 대응하는 데 기여했다고 설명했다.
중요한 것은 AI가 취약점을 발견했다는 사실 자체가 아니다. 공격자와 방어자 모두 AI를 활용하면서 취약점 발견부터 분석, 악용 가능성 판단, 패치와 검증까지 소요되는 시간이 빠르게 단축되고 있다는 점이다.
기존의 정기적 취약점 점검과 사후 패치 중심 대응만으로는 이러한 속도 변화에 대응하기 어렵다. 기업은 외부 노출 자산과 취약점 현황을 지속적으로 파악하고, AI 서비스와 연결된 자산의 위험까지 함께 평가해야 한다.
정상적인 문서가 악성 명령으로 바뀌는 위험
AI 에이전트 환경에서 주목해야 할 대표적인 위협은 '간접 프롬프트 인젝션(Indirect Prompt Injection)'이다.
이는 공격자가 AI에 직접 악성 명령을 입력하는 대신, AI가 업무 과정에서 읽는 문서나 외부 콘텐츠에 악의적인 지시를 숨기는 공격 방식이다.
과거에는 이메일과 웹페이지, 코드 주석, 업무 문서 등이 주로 사람이 읽는 정보였다. 하지만 AI 에이전트가 이러한 자료를 읽고 실제 업무까지 수행하게 되면서 상황이 달라졌다.
외부 문서에 포함된 문장이 AI에 의해 단순한 정보가 아닌 실행 지시로 해석될 수 있기 때문이다.
예를 들어 개발 지원 에이전트가 공개 코드 저장소의 이슈를 읽는다고 가정해 보자. 공격자가 해당 이슈에 내부 환경설정 파일을 검색하도록 유도하는 문구를 삽입하면, 에이전트는 이를 정상적인 업무 지시로 오인할 수 있다.
이때 에이전트가 내부 코드 저장소와 파일 시스템에 접근할 수 있는 광범위한 권한을 갖고 있다면 외부 문서 하나가 내부 기밀정보에 접근하는 통로가 될 수 있다.
국제 웹 보안단체 OWASP는 대규모언어모델(LLM) 애플리케이션의 주요 보안 위험으로 프롬프트 인젝션과 과도한 에이전트 권한을 제시하고 있다.
이러한 공격은 기존 보안 도구만으로 대응하기 어렵다. 정적 애플리케이션 보안 테스트(SAST)는 소스코드의 취약점을 찾고, 소프트웨어 구성 분석(SCA)은 오픈소스 구성요소의 위험을 점검한다. 데이터 유출 방지(DLP)와 계정·접근관리(IAM) 역시 각각의 보안 영역을 담당한다.
그러나 정상적인 문서에 포함된 악성 지시가 AI의 행동을 바꾸고, 그 결과 과도한 권한이 사용되는 문제는 개별 보안 도구만으로 완전히 해결하기 어렵다.
따라서 기업은 AI가 읽는 외부 문서와 이메일, API 응답, 도구 실행 결과를 기본적으로 신뢰할 수 없는 입력으로 취급해야 한다. 동시에 AI가 읽을 수 있는 정보와 실제 실행할 수 있는 작업의 경계를 명확하게 구분해야 한다.
MCP 자체보다 연결된 권한 설계가 문제
모델 컨텍스트 프로토콜(MCP)은 AI 에이전트가 외부 시스템 및 도구와 상호작용할 수 있도록 지원하는 연결 방식이다.
이를 통해 AI는 파일 저장소와 코드 저장소, 이메일, 고객관계관리(CRM), 데이터베이스, 클라우드 관리 시스템 등에 접근해 실제 업무를 수행할 수 있다.
문제는 MCP라는 기술 자체가 아니라 연결 과정에서 부여되는 권한의 범위다.
신뢰할 수 없는 외부 콘텐츠를 읽는 AI 에이전트에 여러 시스템에서 사용할 수 있는 인증 토큰과 광범위한 실행 권한을 부여하면 작은 입력 조작이 대규모 보안 사고로 이어질 가능성이 커진다.
특히 하나의 서비스 계정이나 인증 토큰을 여러 시스템에서 공유하면 특정 에이전트의 침해가 다른 업무시스템으로 확산될 수 있다.
기업은 AI 에이전트가 어떤 외부 콘텐츠를 읽는지, 어떤 내부 시스템에 접근하는지, 어떤 인증 토큰을 사용하는지 파악해야 한다. 또한 읽기와 쓰기, 삭제, 외부 전송 등 권한 범위를 구분하고 실제 도구 호출과 데이터 접근 이력을 확인할 수 있어야 한다.
이를 위해 AI 에이전트와 MCP 서버, API 게이트웨이, 서비스 계정, 인증 토큰, 데이터 저장소 등을 기존 IT 자산관리 범위에 포함할 필요가 있다.
AI 에이전트를 독립적인 소프트웨어 하나로 보는 것이 아니라 여러 자산과 계정, 서비스가 연결된 하나의 관계망으로 관리해야 한다는 의미다.
AI 연결 자산을 기존 취약점 관리체계에 통합해야
AI 에이전트의 보안 위험을 줄이기 위해서는 자산 식별부터 위험 평가, 실행 통제, 조치 이력 관리까지 일관된 체계를 마련해야 한다.
첫 번째는 AI 관련 자산을 기존 자산관리 범위에 포함하는 것이다.
AI 모델뿐 아니라 외부 AI 서비스, 코딩 보조 도구, MCP 서버, 플러그인, 벡터 데이터베이스, 검색증강생성(RAG) 문서 저장소, 연동 API와 서비스 계정까지 식별해야 한다.
승인되지 않은 AI 도구와 관리되지 않는 API 연동 등 이른바 섀도 IT와 섀도 API도 점검 대상이다. 별도의 AI 자산 목록을 만드는 데 그치지 않고 기존 서버와 애플리케이션, 네트워크, 클라우드 자산정보와 연결하는 것이 중요하다.
두 번째는 AI 연결성을 반영한 위험 평가다.
모든 취약점이 동일한 위험을 갖는 것은 아니다. 고객정보에 접근하는 AI 에이전트와 연결된 데이터베이스나 실제 서비스 배포 권한을 가진 시스템의 취약점은 일반적인 내부 개발 환경의 취약점보다 큰 영향을 미칠 수 있다.
따라서 공통 취약점 평가 시스템(CVSS) 점수뿐 아니라 자산 중요도와 외부 노출 여부, 데이터 민감도, 접근 권한, AI 에이전트와의 연결 관계 등을 종합적으로 고려해 조치 우선순위를 결정해야 한다.
세 번째는 최소권한과 사람의 승인 절차를 적용하는 것이다.
에이전트별로 전용 계정을 발급하고 읽기·쓰기·삭제·외부 전송 권한을 구분해야 한다. 특히 고객정보 외부 전송과 결제, 계약 변경, 운영시스템 배포, 계정 권한 변경 등 영향이 큰 작업에는 사람의 명시적인 승인과 복구 절차가 필요하다.
금융보안원도 2026년 10월 '금융분야 AI 에이전트 보안 평가기준(안)'을 마련했다. 해당 기준은 실행 권한과 격리, 사람의 승인, 작업 범위 확인, 자율 실행을 중단하는 킬스위치 등을 점검 대상으로 제시하고 있다. 연말 시범 검증을 거쳐 2027년 정식 점검기준으로 확대 적용할 계획이다.
네 번째는 조치 이력과 감사 증적을 확보하는 것이다.
보안 사고가 발생했을 때 어떤 에이전트가 어떤 정보를 읽었고, 어떤 계정으로 어느 시스템에 접근했으며, 어떤 도구를 실행했는지 확인할 수 있어야 한다.
취약점 발견과 조치 시점, 담당자, 승인 기록, 재점검 결과까지 연결해 관리해야 사고의 영향 범위를 신속하게 판단하고 책임 있는 대응이 가능하다.
AI 보안의 출발점은 자산 가시성
금융회사가 고객상담 지원 AI 에이전트를 내부 업무시스템에 연결하는 상황을 가정해 보자.
먼저 에이전트와 MCP 서버, 서비스 계정, API를 식별하고 고객정보를 보유한 시스템과의 연결 관계를 기록해야 한다. 이후 여러 보안 진단 도구에서 수집한 소프트웨어 취약점과 설정 오류를 해당 자산에 통합한다.
이를 바탕으로 외부 노출 여부와 자산 중요도, AI 연결성을 반영해 위험을 평가하고 조치 담당자와 기한을 지정한다. 개선 이후에는 재점검을 통해 위험이 해소됐는지 확인하고 관련 기록을 남긴다.
경영진은 AI 에이전트와 서비스 계정의 자산 등록률, 소유자 지정률, 최소권한 적용률, 공유 토큰 사용 현황, 고위험 작업 승인율 등을 통해 보안 통제 수준을 확인할 수 있다.
이러한 통합관리가 AI 에이전트의 실행 통제를 대신하는 것은 아니다. 입력 검증과 최소권한, 사람의 승인, 긴급 중단 수단은 별도로 설계하고 운영해야 한다.
다만 어떤 AI 에이전트가 무엇에 연결돼 있는지 파악하지 못한다면 이러한 통제를 어디에 적용해야 할지조차 판단하기 어렵다.
AI 도입이 확대될수록 보안의 질문도 달라져야 한다. 어떤 모델을 사용할 것인지뿐 아니라 해당 모델과 에이전트가 어떤 자산을 읽고, 어떤 시스템에 연결되며, 어떤 권한으로 무엇을 실행할 수 있는지 확인해야 한다.
외부 노출 자산과 미조치 위험, 소프트웨어 구성요소와 운영 자산의 연결 관계, AI 에이전트 보안은 결국 하나의 과제로 이어진다.
조직이 보유한 자산과 위험을 정확히 파악하고 필요한 조치를 실행하며, 그 결과를 지속적으로 검증하는 것이다.
AI 보안은 새로운 보안 제품 하나를 추가하는 것으로 완성되지 않는다. 기존 자산·취약점·조치 관리체계를 AI가 연결되는 시스템까지 확장하고, 그 위에 최소권한과 실행 통제를 결합하는 것에서 시작해야 한다.
