AI 에이전트는 답변만 생성하는 챗봇이 아니다. 데이터를 읽고 의사결정을 내리며 여러 업무 시스템에서 직접 작업하는 소프트웨어다. 사람에게 위임받은 권한으로 여러 시스템에 영향을 줄 수 있기 때문에, 문제가 발생하면 피해 범위도 빠르게 커질 수 있다.1
2026년 6월 직원 100명 초과 조직 107곳을 대상으로 한 설문에서 18%는 확인된 AI 에이전트 보안 사고를, 36%는 피해 전에 차단한 근접 사고를 경험했다고 답했다. 그런데 107곳 중 74곳(69%)에서는 에이전트 간 자격 증명 공유가 이뤄지고 있었다.2
이 수치는 AI 에이전트 보안의 핵심 문제가 모델 자체만이 아니라, 에이전트에 부여된 신원과 권한을 어떻게 관리하느냐에 있음을 보여준다.
공유 자격 증명은 책임 추적을 어렵게 만든다
여러 에이전트가 같은 계정이나 자격 증명을 사용하면 어떤 에이전트가 어떤 작업을 수행했는지 구분하기 어렵다. 한 에이전트가 침해됐을 때 공유 계정에 연결된 권한 전체가 노출될 수 있으며, 특정 에이전트만 차단하거나 감사를 수행하기도 힘들어진다.
따라서 각 에이전트에는 별도의 고유 신원을 부여해야 한다. 그래야 작업 주체를 명확히 기록하고, 에이전트별로 접근 권한을 제한하거나 회수할 수 있다.1 권한은 필요한 데이터와 도구로 한정하고, 소유자와 사용 목적, 운영 기간, 폐기 시점도 함께 정해야 한다.
이는 새로운 원칙이라기보다 기존의 최소 권한과 수명주기 관리를 비인간 사용자에게 확장하는 일이다.
가드레일과 격리는 서로 다른 통제다
조사 대상 조직의 51%는 OpenAI 가드레일을 사용했지만, 최고위험 AI 에이전트를 샌드박스에 격리한 곳은 30%에 그쳤다.2
가드레일은 에이전트의 출력이나 행동을 제한하는 데 도움을 줄 수 있다. 그러나 에이전트가 이미 과도한 시스템 권한을 가지고 있다면 가드레일만으로 접근 범위와 사고 영향을 충분히 통제하기 어렵다. 특히 위험도가 높은 에이전트에는 최소 권한뿐 아니라 샌드박스 같은 격리 조치가 필요하다.
핵심은 하나의 방어책에 의존하지 않는 것이다. 신원, 권한, 격리, 행동 정책, 모니터링을 서로 다른 통제 계층으로 운영해야 한다.
먼저 모든 에이전트를 파악해야 한다
통제의 출발점은 중앙 에이전트 레지스트리다. 레지스트리는 각 에이전트의 소유자, 목적, 플랫폼, 접근 범위를 기록하는 인벤토리다.1 자체 개발 에이전트뿐 아니라 사내 플랫폼에서 만든 에이전트와 서드파티 에이전트도 같은 정책 아래 포함해야 한다.
등록되지 않은 섀도 에이전트는 보안 위험과 비용 위험을 동시에 만든다. 조직이 존재를 모르면 권한을 검토하거나 활동을 감사할 수 없고, 토큰 소비량·컴퓨팅 사용량·API 호출량도 제대로 관리하기 어렵다.1
등록은 일회성 작업으로 끝나지 않는다. 에이전트의 사용 방식과 행동이 달라지면 위험도 함께 변하므로 활동, 접근 패턴, 정책 준수를 지속적으로 관찰해야 한다.
배포 전에 확인할 다섯 가지
조직은 모든 AI 에이전트에 대해 다음 질문에 답할 수 있어야 한다.
소유권: 누가 이 에이전트의 운영과 사고 대응을 책임지는가?
신원: 다른 에이전트와 분리된 고유 신원을 사용하는가?
접근 범위: 어떤 데이터와 시스템에 접근하며, 권한은 필요한 수준으로 제한됐는가?
수명주기: 언제 생성됐고, 언제 검토·중지·폐기되는가?
관찰 가능성: 수행 작업과 접근 패턴, 정책 준수를 추적할 수 있는가?
AI 에이전트 보안 격차는 기술 부족만의 문제가 아니다. 에이전트를 독립된 신원과 수명주기를 가진 관리 대상 자산으로 다루지 않은 결과이기도 하다. 중앙 등록, 고유 신원, 최소 권한, 위험 기반 격리, 지속적인 관찰을 갖춰야 자동화의 속도를 안전하게 따라갈 수 있다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.