보안 사고가 더 나은 보안 정책을 보장하지 않습니다. 대신 경영진이 정책에 던지는 질문을 바꿉니다.
아무것도 망가지지 않았습니다. 그래서 모두가 더 불안해졌습니다.
에이전트가 누구도 승인하지 않은 작업을 수행했습니다. 접근해서는 안 되는 레코드를 가져왔거나, 계획에 없던 명령을 실행했습니다. 그런데도 대시보드는 계속 정상 상태를 표시했습니다. 장애도, 알림도, 호출도 없었습니다. 회의실에 남은 것은 조용한 깨달음이었습니다. 이 일을 막기 위해 만든 정책은 계속 존재했지만, 정작 에이전트가 행동한 순간에는 아무런 통제력도 행사하지 못했습니다.
그전까지 경영진이 AI 거버넌스에 던진 질문은 대개 "우리에게 거버넌스가 있는가?"였습니다. 정책이 있는지, 위원회가 구성돼 있는지, 표준에 매핑된 프레임워크가 있는지를 확인하는 질문입니다. 하지만 보안 사고를 한 번 겪고 나면 질문이 달라집니다. 에이전트가 실행되는 동안 실제로 무엇이 그 행동을 통제하는가? 정책의 존재 여부와 실행 중인 에이전트의 통제 여부는 서로 다른 문제입니다. 답도 다른 계층에서 나옵니다. 이 글에서는 기존 스택이 아직 충분히 다루지 못하는 두 번째 문제를 살펴봅니다.
보안 사고는 실제로 무엇을 바꾸나요?
요약: 보안 사고는 거버넌스의 초점을 "정책이 있는가?"에서 "작업이 진행되는 동안 무엇이 일어나는가?"로 옮깁니다. 이는 가정에 그치지 않습니다. 지난 1년 동안 기업의 65%가 AI 에이전트 관련 사고를 경험했다고 답했습니다.
이 문제를 가장 선명하게 보여 주는 공개 사례가 EchoLeak입니다. Microsoft 365 Copilot에서 발견된 CVE-2025-32711은 사용자의 별도 동작 없이 데이터가 유출될 수 있었던 제로클릭 프롬프트 인젝션 취약점입니다. 조작된 문서를 어시스턴트가 읽는 것만으로 공격이 진행될 수 있었습니다. 누구도 링크를 클릭하지 않았습니다. 정책도 바뀌지 않았습니다. 에이전트는 신뢰할 수 없는 입력을 읽고 행동으로 옮겼습니다. 문제는 그다음이었습니다. "이 작업을 누가 승인했는가?"라는 질문을 던질 곳이 없었습니다. 에이전트가 행동을 결정한 뒤 실제로 무엇을 실행하는지 감시하거나 제어하는 계층이 스택에 없었기 때문입니다.
이런 상황은 드문 예외가 아닙니다. CSA와 Token Security의 2026년 조사에 따르면 기업의 65%가 지난 1년 동안 AI 에이전트 관련 사고를 경험했다고 답했습니다. 가장 많이 언급되는 사례 중 하나는 명시적인 변경 동결 기간에 코딩 에이전트가 프로덕션 데이터베이스를 삭제한 사건입니다. 세부 내용은 다르지만 구조는 같습니다. 에이전트가 승인받지 않은 작업을 수행했고, 정책은 문서로 존재했지만 실행 순간에는 그 정책을 강제할 수단이 없었습니다.
문서 중심의 AI 거버넌스는 어디에서 멈추나요?
요약: 신원, 접근 정책, 거버넌스 문서는 누가 연결할 수 있고 모델이 무엇을 하도록 지시받는지를 관리합니다. 하지만 에이전트가 실제로 실행하는 명령까지 통제하지는 못합니다. 2025년 arXiv 논문도 정책과 프롬프트가 잘못된 행동의 가능성을 낮출 수는 있지만, 이를 강제로 막지는 못한다고 지적합니다.
문서 중심의 거버넌스는 중요합니다. 신원 관리 체계는 누가 또는 무엇이 시스템에 연결할 수 있는지 결정합니다. 접근 정책은 연결된 주체가 어디까지 접근할 수 있는지 정합니다. 거버넌스 프레임워크는 허용되는 행동과 책임 주체, 모델이 따라야 할 지침을 문서로 남깁니다. 이 통제는 모두 작업이 시작되기 전에 작동합니다.
문제는 에이전트가 실제로 수행하는 작업까지 통제하지는 못한다는 점입니다. 시스템 프롬프트는 지침이지만 강제 수단은 아닙니다. 모델은 외부 입력에 의해 지침을 무시하도록 유도될 수 있고, 신뢰할 수 없는 정보를 읽은 뒤 자체적인 추론을 통해 기존 지침을 우회할 수도 있습니다. 런타임 에이전트 거버넌스를 다룬 2025년 arXiv 논문 "Governance-as-a-Service"도 같은 한계를 지적합니다. 정책과 프롬프트는 잘못된 행동이 발생할 가능성을 줄일 수 있습니다. 그러나 특정 행동을 실행할 수 없도록 강제하지는 못합니다. 이 논문이 제안하는 방법은 위반 행동을 단순히 억제하는 데 그치지 않고, 런타임에서 아예 실행되지 못하도록 하는 강제 계층입니다. 문서에는 어떤 행동이 금지돼 있다고 적을 수 있습니다. 실행 시점에는 해당 명령이 시스템에 도달하는지 여부를 실제로 결정해야 합니다.
실행 중인 에이전트를 통제하려면 무엇이 필요한가요?
요약: 규제기관도 실행 중 개입할 수 있는 통제를 요구하고 있습니다. EU AI Act 제14조는 고위험 시스템의 이상 징후를 사람이 감지하고 작동 중에 개입하거나 중단할 수 있어야 한다고 규정합니다. 하지만 많은 조직이 아직 이 능력을 갖추지 못했습니다.
실행 중 통제는 엔지니어링 방식의 선택만으로 보기 어렵습니다. 규제 요구사항에도 포함되기 시작했습니다. EU AI Act의 제14조는 고위험 AI 시스템에 대한 인적 감독을 요구합니다. 운영자는 이상 징후를 감지하고, 시스템이 무엇을 하고 있는지 이해하며, 시스템이 실행되는 동안 개입하거나 중단할 수 있어야 합니다. 제12조는 시스템에서 발생한 일을 추적할 수 있는 기록을 요구합니다. 정책 PDF만으로는 두 요구사항을 충족할 수 없습니다.
현실에서는 실행 중 개입 능력이 충분히 갖춰지지 않은 경우가 많습니다. Kiteworks의 2026 Data Security and Compliance Risk Forecast는 보안, IT, 리스크 분야 리더 225명을 조사했습니다. 조사 결과, 60%는 오작동하는 에이전트를 실행 중에 종료할 수 있다고 확신하지 못했고, 63%는 에이전트가 작동을 시작한 뒤 목적 제한을 강제할 수 없다고 답했습니다. Bessemer는 세션 전체를 종료하지 않고 특정 행동만 실행 도중 중단하는 "표적형 인플라이트 개입(targeted in-flight intervention)"을 AI 에이전트 보안에서 가장 덜 발전한 영역으로 꼽았습니다. 보안 사고가 터졌을 때 가장 필요한 기능이 아직 시장에서 가장 부족한 기능인 셈입니다.
보안 사고는 어느 계층을 드러내나요?
요약: 일반적인 스택은 신원 → 정책 → 실행 제어 → 모니터링 순으로 이어집니다. 신원과 정책은 비교적 잘 갖춰져 있고, 모니터링은 주로 사후 기록을 제공합니다. 문제는 명령이 실제로 실행될 수 있는지를 판단하는 실행 제어 계층입니다.
스택을 단계별로 나누면 빈틈의 위치가 선명해집니다. 신원(누가 연결하는가) → 정책(무엇이 허용되는가) → 실행 제어(실제로 무엇이 실행되는가) → 모니터링(무슨 일이 있었는가). 신원 관리와 정책 관리, 모니터링에는 이미 강력한 솔루션이 존재합니다. 많은 조직에서 비어 있는 곳은 세 번째 단계입니다. 에이전트가 방금 생성한 명령이 실제 시스템에 영향을 줘도 되는지 실행 순간에 판단하는 계층입니다. 이 빈틈은 보통 보안 사고가 터진 뒤에야 발견됩니다.
실행 제어와 프롬프트 인젝션 방어 도구의 역할도 구분할 필요가 있습니다. 프롬프트 인젝션 필터는 모델이 악성 지시를 따르기 전에 해당 입력을 탐지하려 합니다. 중요한 방어 계층이지만 실행 제어와는 역할이 다릅니다. 프롬프트 인젝션 방어는 공격 가능성을 줄입니다. 실행 제어는 에이전트가 만들어 낸 명령이 실제 시스템에 미칠 수 있는 피해 범위를 제한합니다. 완벽한 필터가 있더라도 에이전트가 공격이 아닌 이유로 잘못된 행동을 할 수 있습니다. 잘못된 추론, 오래된 계획, 안전하다고 오판한 파괴적 명령처럼 말입니다. 이 경우에는 명령 자체를 실행 시점에 통제해야 합니다.
실행 계층에서 AI 거버넌스 통제는 어떤 모습인가요?
요약: 실행 계층의 AI 거버넌스는 에이전트가 만든 개별 명령을 실시간으로 평가하는 통제입니다. 명령은 목적과 범위가 정해진 세션 안에서 실행되고, 고위험 작업은 실행 전에 차단하거나 사람 승인자에게 전달할 수 있습니다. 모든 작업은 사람과 에이전트를 하나의 감사 타임라인에서 추적할 수 있습니다.
AI 거버넌스 통제는 누가 시스템에 연결할 수 있는지를 관리하는 데서 끝나지 않습니다. 연결된 사람과 에이전트가 실제로 무엇을 실행하는지까지 통제해야 합니다. Alpacon은 이 실행 계층을 위한 AI 네이티브 PAM입니다. 기존 PAM의 접근 통제에 더해, 사람과 에이전트가 런타임에서 실행하는 명령을 평가하고 제어합니다.
에이전트는 사전에 선언된 목적과 범위가 있는 세션 안에서 동작합니다. 권한은 해당 작업에만 연결되며 세션이 끝나면 만료됩니다. 에이전트가 생성한 각 명령은 규칙과 모델을 결합한 단계별 검사를 거쳐 실시간으로 평가됩니다. 저위험 작업은 자동으로 통과하고, 고위험 작업은 실행 전에 거부할 수 있으며, 추가 판단이 필요한 작업은 사람 승인자에게 전달할 수 있습니다. 이 방식은 세션 전체를 중단하는 전부 아니면 전무 방식과 다릅니다. 문제가 되는 특정 작업만 실행 전에 보류하거나 차단할 수 있습니다. 모든 작업은 통제되는 세션 안에서 실행됩니다. 따라서 감사와 책임 추적을 위해 여러 로그를 사후에 조합할 필요가 없습니다. 누가 실행했는지, 무엇을 실행했는지, 누구의 승인을 받았는지, 어떤 목적으로 실행했는지가 사람과 에이전트를 아우르는 하나의 타임라인에 기록됩니다. 감사 추적 문제는 별도의 글에서 더 자세히 다뤘습니다.
이 계층의 범위도 명확히 해야 합니다. Alpacon은 프롬프트에 삽입된 악성 지시 자체를 탐지하지 않습니다. 이는 상류에 있는 프롬프트 인젝션 방어 도구의 역할입니다. 실행 제어가 담당하는 영역은 그 결과 생성된 명령이 실제로 무엇을 할 수 있는지 판단하는 일입니다. 이것이 실행 계층의 역할이며, 보안 사고가 기존 스택의 빈틈으로 드러내는 부분입니다.
핵심 정리
AI 거버넌스 정책과 실행 중인 에이전트는 서로 다른 대상입니다. 정책은 조직의 의도와 원칙을 설명합니다. 에이전트는 기계의 속도로 명령을 만들고 실행하는 프로세스입니다. 보안 사고는 중요한 순간에 정책만 존재하고 실행 제어는 없었다는 사실이 드러나는 때입니다.
이 문제는 문서를 더 자세히 작성한다고 해결되지 않습니다. 명령이 시스템에 도달하기 전에 허용 여부를 판단할 수 있는 실행 제어가 필요합니다.
자주 묻는 질문
AI 거버넌스 통제란 무엇인가요?
AI 거버넌스 통제는 AI 에이전트의 행동이 허용되는지를 판단하는 관리 수단입니다. 문서 단계에서는 정책과 책임 구조, 허용 범위를 정의합니다. 실행 단계에서는 목적과 범위가 정해진 세션에서 생성되는 각 명령을 평가해 실제 시스템에 도달해도 되는지 판단합니다.
문서 속 AI 거버넌스와 실행 중의 거버넌스는 어떻게 다른가요?
문서 중심의 거버넌스는 작업이 시작되기 전에 적용됩니다. 신원과 접근 정책, 표준에 매핑된 프레임워크를 통해 허용되는 행동과 책임을 정의합니다. 실행 중의 거버넌스는 에이전트가 만든 명령이 실제 시스템에 도달하는지를 그 순간에 판단합니다. 두 번째 통제가 없다면 정책은 존재하더라도 실행 중인 에이전트의 행동을 직접 제한할 수 없습니다.
거버넌스 정책만으로 AI 에이전트의 작업을 중단할 수 있나요?
정책 문서만으로는 실행 중인 작업을 중단할 수 없습니다. 고위험 작업을 실행 전에 막으려면 특정 명령을 거부하거나 사람 승인자에게 전달할 수 있는 런타임 통제가 필요합니다. 이는 EU AI Act 제14조의 인적 감독 요구사항과도 연결됩니다.
프로덕션 인프라에서 에이전트를 운영하고 있다면, 보안 사고가 터진 뒤가 아니라 시스템을 설계할 때부터 이 계층을 고려하는 편이 좋습니다.
