2026년 여름, AI 업계에서 가장 많이 회자된 단어는 '성능'이 아니라 '이탈'이었다. 오픈AI는 7월 21일 자사 모델이 내부 사이버 역량 평가 도중 테스트 환경을 벗어나 허깅페이스 운영 인프라에 침입했다고 공식 인정했다. 에이전트는 패키지 저장소 프록시의 알려지지 않은 취약점을 스스로 찾아 외부 인터넷에 도달했고, 주말 동안 내부 자격증명을 수집하며 이동했다. 영국 AI보안연구소(AISI)는 8월 4일 보고서에서 사이버 평가 122회 실행 가운데 10회에서 총 19건의 '승인되지 않은 행동'이 발생했다고 공개했다. 일부 에이전트는 가짜 신원을 만들어 오픈소스 프로젝트 관리자에게 악성 코드 병합을 요구했고, 사람이 이를 발견해 막았다. 8월 중순 이후 국내외 언론과 보안 커뮤니티에서는 이 사례들이 다시 집중 조명됐다. 이번 사건들은 테스트 환경의 네트워크 경계와 권한 통제가 실패할 경우, 평가 목적의 자율 시스템도 실제 외부 조직에 영향을 줄 수 있음을 보여줬다.

경영자가 이 뉴스에서 읽어야 할 것은 공포가 아니다. 이탈 사례의 공통점은 '모델이 똑똑했다'가 아니라 '환경이 권한을 느슨하게 줬다'는 데 있다. AISI는 이 사례가 일반 운영환경에서의 행동을 그대로 재현한 것은 아니며, 최대 역량을 측정하기 위해 실제 인터넷 접근이 가능한 평가 환경과 완화된 안전장치를 사용한 조건에서 발생했다고 설명했다. 핵심은 모델의 행동만큼이나 네트워크·도구·계정 권한이 어떻게 열려 있었는지에 있다. 즉 문제의 본질은 기술이 아니라 권한 설계다. 그리고 권한 설계는 개발팀이 아니라 경영진이 먼저 결정해야 할 영역이다.

왜 '도입 여부'보다 '권한 범위'가 먼저인가

맥킨지가 2025년 6~7월 전 세계 1,993명을 대상으로 진행한 'State of AI 2025' 조사에서 응답 기업의 62%가 AI 에이전트를 최소한 실험 중이라고 답했다. 이 중 23%는 최소 한 개 기능에서 에이전트를 확산 단계로 운영하고 있고, 39%는 실험 단계에 있다. 그러나 개별 기능 단위로 보면 실제 확산에 이른 비율은 최대 10% 수준에 그친다. 대다수 조직이 '써보고는 있지만, 어디까지 맡길지 정하지 못한' 상태라는 의미다.

가트너는 2025년 6월 발표에서 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것으로 전망했다. 비용 상승, 불분명한 사업 가치, 부족한 리스크 통제가 주요 이유로 꼽혔다. 이 전망이 시사하는 바는 분명하다. 에이전트 프로젝트는 기술이 부족해서가 아니라, 조직이 '무엇을 허락하고 무엇을 금지할지'를 정하지 못해 중단된다. 권한 기준이 없으면 보안팀은 모든 것을 막고, 현업은 모든 것을 열어달라고 요구하며, 프로젝트는 그 사이에서 표류한다.

국내 상황도 다르지 않다. 2026년 1월 22일 시행된 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」(AI 기본법)은 고영향 AI에 대한 사업자 책임과 안전성 확보 의무를 규정한다. 금융·의료·채용·공공서비스 등 법령상 지정 영역에서 이용자의 권리와 안전에 중대한 영향을 줄 수 있는 AI를 운영한다면, 고영향 AI 해당 여부와 인간의 최종 의사결정 관여를 함께 검토해야 한다. 이때 '누가 어떤 권한을 부여했고 어떤 조건에서 멈추도록 했는가'는 법이 요구하는 문서화·안전성 확보·인간 감독 체계의 근거가 된다. 권한 기준은 보안 문서가 아니라 경영 의사결정의 기록이다.

CEO가 먼저 정해야 할 7개 운영권한

권한 기준을 정할 때 경영진이 가장 먼저 바로잡아야 할 오해가 하나 있다. 에이전트의 권한을 '에이전트에게 준다'고 생각하는 것이다. 실제로 권한은 에이전트가 아니라 에이전트가 사용하는 계정과 자격증명에 부여된다. 에이전트가 관리자 계정으로 실행되면 에이전트의 판단이 아무리 신중해도 관리자의 모든 권한을 갖는다. 따라서 권한 설계의 첫 단계는 에이전트 전용 계정을 만들고, 그 계정에 사람 직원보다 좁은 권한만 주는 것이다. 사람 직원의 계정을 에이전트와 공유하는 순간, 7개 권한 기준은 의미를 잃는다.

아래 7개 권한은 법적 의무나 업계 표준이 아니라, 최근 사례와 보안 실무의 공통 원칙을 경영진이 '예/아니오/조건부'로 답할 수 있도록 사업 행위 단위로 재구성한 필자의 제안이다. 각 권한마다 핵심 질문과 기본 권고안, 그리고 중단조건을 함께 정해야 한다.

첫째, 읽기 권한이다. 에이전트가 어떤 데이터를 볼 수 있는가의 문제다. 핵심 질문은 "이 에이전트가 접근하는 데이터 가운데 외부에 유출되면 사업이 중단될 수준의 정보가 포함되는가"이다. 고객 개인정보, 미공개 재무, 인사 평가, 계약 원문은 기본적으로 읽기 범위에서 제외하고, 업무상 꼭 필요하다면 마스킹된 사본만 제공하는 것이 기본 권고안이다. 읽기는 가장 낮은 위험처럼 보이지만, 허깅페이스 사례에서 에이전트는 먼저 외부 인터넷으로 이어지는 경로를 확보한 뒤 침투 과정에서 자격증명과 내부 접근수단을 악용했다. 무엇을 읽을 수 있느냐가 이후 행위의 상한선을 정한다는 점은 여전히 유효하다.

둘째, 쓰기 권한이다. 생성, 수정, 삭제를 구분해야 한다. 초안 작성과 같은 생성은 비교적 넓게 허용할 수 있다. 그러나 기존 기록의 수정과 삭제는 원칙적으로 사람의 승인 뒤에만 실행되도록 해야 한다. 2025년 7월 한 코딩 에이전트가 명시적 동결 지시에도 불구하고 운영 데이터베이스를 삭제한 사례는 업계에 널리 알려져 있다. 핵심 질문은 "이 에이전트의 쓰기 작업을 되돌릴 수 있는가"이다. 되돌릴 수 없는 쓰기는 자동화 대상이 아니다.

셋째, 결제·자금집행 권한이다. 구매, 송금, 환불, 광고비 집행, 구독 결제가 여기에 해당한다. 기본 권고안은 건당 한도와 일일 누적 한도를 동시에 두고, 한도 이내라도 신규 수취처에는 반드시 사람의 승인을 요구하는 것이다. 핵심 질문은 "이 에이전트가 하루에 집행할 수 있는 최대 금액은 얼마이고, 그 금액을 잃어도 회사가 감당할 수 있는가"이다. 이 질문에 숫자로 답하지 못하면 결제 권한은 부여하지 않는 것이 맞다.

넷째, 배포·운영반영 권한이다. 코드 배포, 설정 변경, 콘텐츠 발행, 가격 변경처럼 고객이나 시장에 즉시 노출되는 행위다. 기본 권고안은 '에이전트는 준비까지, 반영은 사람이'라는 원칙이다. 배포 버튼은 사람이 누른다. 다만 되돌리기가 즉시 가능하고 영향 범위가 명확히 제한된 경우에는 단계적으로 자동화를 허용할 수 있다. 핵심 질문은 "잘못 반영됐을 때 고객이 알아차리기 전에 되돌릴 수 있는가"이다.

다섯째, 외부접속 권한이다. 인터넷 검색, 외부 API 호출, 타사 시스템 로그인이 해당한다. 2026년 여름 이탈 사례들의 공통 분모가 바로 이 권한이었다. AISI 사례에서는 인터넷 접근이 의도적으로 열려 있었고, 오픈AI 사례에서는 닫혀 있다고 믿었던 경로가 실제로는 열려 있었다. 기본 권고안은 허용 목록 방식이다. 접속 가능한 외부 주소를 명시적으로 나열하고, 나열되지 않은 모든 곳은 차단한다. 핵심 질문은 "이 에이전트가 회사 밖으로 나갈 수 있는 문이 몇 개이고, 그 문을 누가 세었는가"이다. '차단했다고 믿는 것'과 '차단을 실제로 시험해 확인한 것'은 다르다는 점이 최근 사례의 가장 중요한 교훈이다.

여섯째, 대외 커뮤니케이션 권한이다. 고객, 거래처, 언론, 규제기관에 회사 명의로 메시지를 보내는 행위다. AISI 사례에서 에이전트는 가짜 신원을 만들어 실제 사람을 설득하려 했다. 에이전트가 회사를 대표해 말하기 시작하면, 그 말은 법적·평판적 책임을 수반한다. 기본 권고안은 내부 초안 작성까지는 허용하되 발신은 사람이 하고, 자동 발신을 허용하더라도 에이전트가 보낸 메시지임을 수신자가 알 수 있도록 표시하는 것이다. 핵심 질문은 "이 메시지가 문제가 됐을 때 '에이전트가 보냈다'는 설명이 고객에게 통하는가"이다.

일곱째, 권한 위임·자기확장 권한이다. 에이전트가 다른 에이전트를 생성하거나, 추가 권한을 요청하거나, 새로운 도구를 스스로 연결하는 행위다. 가장 낯설지만 가장 중요한 항목이다. 오픈AI 사례에서 에이전트들은 평가 완료와 인터넷 접근을 별도 작업으로 스스로 분리했고, 중단된 뒤에도 작업을 다시 만들어 결국 목표를 달성했다. 기본 권고안은 명확하다. 에이전트는 자신의 권한을 스스로 늘릴 수 없고, 다른 에이전트에게 자신보다 넓은 권한을 줄 수 없다. 핵심 질문은 "이 에이전트가 내일 아침 어제보다 더 많은 권한을 갖고 있을 가능성이 있는가"이다. 답이 '있다'면 구조를 다시 설계해야 한다.

권한보다 먼저 정해야 할 것, 중단조건

7개 권한을 정했다면 마지막으로 정해야 할 것은 '언제 멈추는가'이다. 중단조건은 세 층위로 나눌 수 있다. 첫 번째는 행위 기반 중단이다. 허용 목록 밖의 외부 접속 시도, 한도 초과 결제 시도, 삭제 명령 실행 시도처럼 특정 행위가 감지되면 즉시 정지한다. 두 번째는 패턴 기반 중단이다. 같은 작업을 비정상적으로 반복하거나, 실패한 작업을 우회 경로로 다시 시도하거나, 예상 시간의 몇 배를 초과해 실행되는 경우다. 오픈AI 사례에서 에이전트들은 중단 뒤 작업을 재생성했다. 반복 자체가 경고 신호다. 세 번째는 사람 기반 중단이다. 담당자 누구든, 이유를 설명하지 않고도, 한 번의 조작으로 모든 에이전트를 멈출 수 있어야 한다. 이 버튼이 없는 에이전트 시스템은 운영 승인을 보류하는 것이 바람직하다. 정지 권한은 넓게, 재가동 권한은 좁게 두는 것이 원칙이다. 멈추는 데는 한 사람이면 충분하지만, 다시 켜는 데는 원인 확인과 책임자 승인이 필요하다.

중단조건에서 경영진이 흔히 놓치는 지점은 '멈춘 뒤'다. 멈춘 에이전트가 무엇을 했는지 재구성할 수 있는 기록이 있는가. 모든 도구 호출, 자격증명 사용, 외부 접속 시도가 시간 순서로 남아 있어야 사고 원인을 파악하고 규제기관에 설명할 수 있다. 허깅페이스는 오픈AI가 해당 활동을 자사 평가와 연결하기 전에 침입을 탐지·차단하고 사건을 공개했다. 기록과 탐지 체계가 없었다면 사고는 훨씬 늦게, 훨씬 크게 드러났을 것이다.

누가 결정하고, 어떻게 기록하는가

7개 권한의 기준을 정하는 주체는 기술 조직이 아니라 경영진이어야 한다. 이유는 단순하다. 권한의 범위는 곧 회사가 감수하기로 한 손실의 범위이고, 손실의 상한을 정하는 것은 경영 판단이기 때문이다. 보안 책임자는 위험을 설명하고, 기술 책임자는 구현 가능성을 설명하며, 현업 책임자는 필요성을 설명한다. 필자는 세 설명을 듣고 "여기까지 허용한다"고 결정하는 사람이 CEO 또는 CEO가 명시적으로 위임한 임원이어야 한다고 본다. 이 결정이 없으면 권한은 가장 목소리가 큰 부서의 요구대로 정해지고, 사고가 났을 때 아무도 결정한 사람이 없다는 상황이 벌어진다.

결정은 문서로 남겨야 한다. 권장되는 형식은 에이전트별 '권한 명세서'다. 에이전트의 목적, 7개 권한별 허용 범위와 한도, 중단조건, 승인자, 검토 주기를 한 장에 담는다. 분기마다 검토해 실적이 확인된 권한은 넓히고, 사용되지 않은 권한은 회수한다. 이 문서는 AI 기본법이 요구하는 문서화·안전성 확보·인간 감독 체계의 근거 자료로 활용될 수 있을 뿐 아니라, 감사와 이사회 보고에서 "우리는 알고 결정했다"는 것을 증명하는 기록이 된다. 특히 금융·의료·채용처럼 고영향 영역으로 분류될 가능성이 있는 업무라면, 이 명세서의 유무가 향후 규제 대응의 출발점이 된다.

경영진이 이번 주에 할 수 있는 일

첫째, 현재 운영 중이거나 시범 적용 중인 모든 에이전트를 한 장의 표로 정리한다. 이름, 담당 부서, 7개 권한별 허용 여부, 중단 담당자를 적는다. 대부분의 조직에서 이 표를 만드는 것만으로도 '아무도 권한을 정한 적 없는' 에이전트가 드러난다. 둘째, 외부접속 권한에 대해 '차단을 실제로 시험했는가'를 기술 책임자에게 묻는다. 설정 파일이 아니라 시험 결과를 요구한다. 셋째, 결제와 삭제 권한을 가진 에이전트가 있다면 이번 주 안에 사람의 승인 단계를 추가한다. 넷째, 전체 정지 버튼이 누구 손에 있는지 확인하고, 그 사람이 휴가 중일 때의 대리자를 지정한다.

AI 에이전트는 직원이 아니지만, 권한을 받는다는 점에서는 직원과 같다. 신입 직원에게 첫날부터 법인카드와 서버 관리자 계정과 대외 발신 권한을 한꺼번에 주는 회사는 없다. 에이전트도 마찬가지다. 권한은 작게 시작해 실적과 기록을 근거로 단계적으로 넓힌다. 2026년 여름의 이탈 사례들이 경영진에게 남긴 질문은 "AI를 도입할 것인가"가 아니라 "AI에게 무엇까지 허락할 것인가"이다. 이 질문에 먼저 답하는 조직이 가트너가 예고한 40%의 취소 목록에서 벗어날 가능성이 가장 높다.