접근 제어만으로는 AI 에이전트 거버넌스가 안 됩니다

AI 네이티브 PAM 대부분은 누가 접근할지만 다룹니다. 거버넌스는 그다음에 벌어지는 일까지 판단해야 합니다.

2026년 1월, Aembit가 의뢰하고 Cloud Security Alliance가 실시한 IT·보안 담당자 228명 대상 조사에서 68%는 AI 에이전트의 활동과 사람의 활동을 명확히 구분할 수 없다고 답했습니다. 74%는 에이전트가 필요 이상의 권한을 받는 경우가 많다고 답했고, 52%는 에이전트가 사람이나 다른 시스템에 부여됐던 권한을 그대로 물려받는 일이 적어도 때때로 있다고 답했습니다(Cloud Security Alliance, 2026-03-24).

이 문제는 접근 제어만으로 풀리지 않습니다. 접근 제어는 에이전트가 무엇을 가질 수 있는지를 정할 뿐, 그 권한으로 무엇을 하는지는 구조적으로 판단할 수 없습니다. 문제는 권한을 부여한 다음부터 시작됩니다. 필요한 권한만 정확히 가진 에이전트도 명령을 내릴 때마다 무엇을 할지 스스로 결정하는데, 대부분의 스택은 그 순간을 거의 지켜보지 않습니다.

'AI 에이전트 거버넌스'라는 말은 이 공백을 채워야 합니다. 다만 이 단어가 정확히 무엇을 가리켜야 하는지는 따져볼 필요가 있습니다. 저희가 본 바로는, 이 이름을 달고 나온 제품 대부분이 로고만 바뀐 접근 제어였기 때문입니다.

거버넌스가 하는 세 가지 별개의 일

AI 에이전트 거버넌스란 에이전트가 이미 가진 권한으로 무엇을 하는지 판단하는 일입니다. 처음에 무엇을 가질 수 있는지 정하는 데서 끝나지 않고, 일어난 일을 바탕으로 규칙을 조입니다. 마케팅 표현을 걷어내면, AI 에이전트를 위한 거버넌스 프로그램은 서로 다른 세 시점에 서로 다른 세 가지 일을 해야 합니다.

1. 에이전트가 무엇을 가질 수 있는지 정합니다. 이 신원은 누구인지, 어떤 역할과 연결되는지, 이 세션의 범위 상한(scope ceiling)은 어디까지인지를 정합니다. 이것이 접근 제어이며, 레거시든 AI 네이티브든 PAM 벤더가 이미 다루는 영역입니다.
2. 그 권한으로 실제로 무엇을 하는지, 하는 동안 판단합니다. "이 에이전트가 이 데이터베이스를 건드려도 되는가"가 아니라 "지금 이 명령이 이 세션을 연 목적에 여전히 맞는가"를 묻습니다. 이것이 실행 시점 판단이며, 접근 제어와는 다른 순간에 던지는 다른 질문입니다.
3. 일어난 일을 학습해 다음 세션을 규율할 규칙을 조입니다. 세션을 한 번도 돌려보지 않은 상태에서 쓴 정책은 추측일 뿐입니다. 에이전트가 시도한 새로운 패턴, 너무 느슨했던 규칙, 더 빨리 발동했어야 할 승인처럼 실제로 일어난 일로 정책이 수정돼야 비로소 개선되는 시스템입니다.

접근 제어만 하는 프로그램은 '거버넌스'라는 이름을 아직 얻지 못한 채 달고 있는 셈입니다. 실행 시점 판단까지 더한 프로그램은 그보다 가깝지만, 저희가 본 바로는 마케팅이 말하는 것보다 드뭅니다. 세 가지를 모두 하는 프로그램이 '거버넌스'라는 말에 맞는 실체입니다. 다만 이를 끝까지 입증한 벤더는 저희도 아직 보지 못했고, 지금은 카테고리가 그 방향으로 가고 있다는 편이 더 정확합니다.

1번: 이미 모두가 파는 부분

접근 제어는 저희를 포함해 AI 네이티브 PAM에 뛰어든 모든 업체가 이미 다루는 영역입니다. 반드시 필요하고, 최소한의 자격 조건이기도 합니다. 하지만 권한을 제대로 부여했다고 해서, 세션이 세 단계쯤 진행된 뒤 그 권한이 잘못된 용도로 쓰이는 일까지 막지는 못합니다.

2026년에 나온 에이전틱 AI 보안 논문도 연구 쪽에서 같은 전환을 주장합니다. 보안은 행위자를 인증하는 데서 행위를 평가하는 쪽으로 옮겨가야 하고, 능력 있는 에이전트는 신원 확인을 통과했다고 신뢰할 대상이 아니라 기본적으로 의심할 대상으로 다뤄야 한다는 주장입니다(Zafar 외, arXiv 2605.16436). Gartner는 평균적인 글로벌 포춘 500대 기업이 2028년까지 15만 개 이상의 에이전트를 운용하게 될 것으로 전망합니다. 2025년 기준으로는 15개도 되지 않습니다(Gartner, 2026-04-28). 응답자 중 자사 조직이 에이전틱 AI에 성숙한 거버넌스 모델을 갖췄다고 답한 비율은 **21%**뿐입니다(Deloitte, 2026-04-24). 규모가 커질수록 접근 제어만으로 버티는 계산은 쉬워지지 않습니다. 오히려 더 나빠집니다.

2번: 행위자만이 아니라 행위를 판단합니다

실행 시점 판단이 거버넌스가 적용된 세션과 접근 제어만 적용된 세션을 가르는 지점입니다. 각 명령을 세션이 선언한 목적에 대조해 점수를 매기며, 세션을 연 아이덴티티에만 대조하는 게 아닙니다. Alpacon 안에서 Work Session은 선언된 아이덴티티, 선언된 목적, 그리고 범위 상한(scope ceiling)을 갖고 열립니다. sudo의 경우 이 상한은 세션이 선언한 범위로 묶입니다. 세션이 선언하지 않은 권한 상승은 superuser 여부와 무관하게 MFA를 거치기도 전에 거부됩니다. 이 검사는 로드맵이 아니라 지금 작동합니다.

Alpacon은 에이전트가 command API로 보내는 모든 명령에 위험도 점수를 매깁니다. 규칙은 명백히 괜찮은지 명백히 금지된 것인지를 판정하고, 회색 지대에 걸리는 명령은 명령어 텍스트뿐 아니라 세션이 선언한 목적과도 대조합니다. 이 대조는 명령이 사람의 승인으로 넘어갈 수 있게 되기 전에 이뤄집니다. 넘어간 뒤에 이뤄지는 게 아닙니다. 이 판정에 따라 Alpacon이 조치할지 기록만 할지는 워크스페이스 설정으로 정하며, 기본값은 강제입니다. 판정을 먼저 지켜보고 싶은 팀을 위한 monitor-and-record 모드도 있습니다.

실행 시점 판단은 접근 제어가 구조적으로 답할 수 없는 질문에 답합니다. 자격증명을 정확히 갖춘 에이전트도 그 목적에 맞지 않는 명령을 만들어낼 수 있습니다. 보안·IT·리스크 책임자 **63%**는 에이전트에게 허용된 목적 범위를 강제할 수 없다고 답했고, **60%**는 문제를 일으키는 에이전트를 종료시킬 수 없다고 답했습니다(Kiteworks, 2026 Data Security and Compliance Risk Forecast). 접근 제어만으로는 이 두 수치 중 어느 것도 움직이지 못했을 것입니다. 행위를 판단한다는 것은 명령이 실행되려는 그 순간, 세션이 선언한 목적과 그 명령을 대조해 점수를 매기는 일입니다. 세션이 존재하기 전에 정해진 역할이나 자격증명을 보는 일이 아닙니다. 이는 권한 부여와는 다른 방식이며, 에이전트 자신의 판단 안이 아니라 바깥에 서도록 만들어졌습니다.

이 실행 시점 판단이 미치는 범위에는 경계가 있습니다. Alpacon의 거버넌스 대상 Work Session을 통해 실행되는 것에만 적용되고, 서비스 토큰에는 적용되지 않습니다. CI/CD나 벤더 통합용으로 발급된 자격증명은 필요한 순간에 발급되는(just-in-time) 세션이 아니라 사전에 관리자가 승인해 둔 고정된 ACL로 인가를 충족합니다. 이 ACL이 허용하는 토큰 명령은 사람에게 넘겨 승인받는 대신 자동으로 승인됩니다. 판단 자체는 여전히 이뤄지고, 위험 상한을 넘는 명령은 거부됩니다. 에이전트가 일부는 서비스 토큰으로, 일부는 세션 안에서 돌아간다면 이는 하나의 거버넌스 모델이 아니라 서로 다른 두 모델이 함께 있는 셈입니다. 저희를 포함한 벤더에게 어느 경로가 어느 모델을 따르는지 물어봐야 합니다.

3번: 세션에서 배워 다음 세션을 조입니다

3번 일은 피드백 루프입니다. 감사 기록이 다시 정책으로 흘러들어가, 다음 달 규칙이 미리 누군가 추측한 내용이 아니라 이번 달 실제로 일어난 일을 반영하게 만드는 일입니다. 업계에서 언급이 가장 적은 일입니다.

관찰된 행동으로 정책을 조이는 루프는 아이덴티티 거버넌스의 다른 영역에서 이미 나와 있습니다. Veza는 부여됐지만 쓰이지 않은 권한에 점수를 매기고, Okta의 관리자 대상 검토 캠페인은 활동 이력을 기준으로 관리자를 표시합니다. AI 네이티브 PAM 벤더 중 에이전트에 맞춘 버전은 아직 보지 못했습니다. 어떤 권한이 안 쓰였는지가 아니라, 에이전트의 명령이 실제로 무엇을 했는지로 정책이 수정되는 버전 말입니다. 이는 스스로 갱신되지 않는 정책 문서와는 종류가 다르고, 만들기도 더 어려운 일이며, 어느 벤더의 주장이든 '앞으로 그렇게 될 방향'과 '지금 작동 중'을 구분해서 봐야 합니다.

'AI 에이전트 거버넌스'를 파는 벤더에게 실제로 물어볼 것

벤더의 설명에서 '거버넌스'라는 말이 실제로 의미가 있다면, 기능 목록이 아니라 특정 시점에 대응해야 합니다.

• 권한 부여 시점: 이 에이전트가 무엇을 가질 수 있고, 얼마나 좁게 범위가 정해져 있는가? (1번 일입니다. AI 네이티브 PAM 벤더라면 모두 답이 있습니다.)
• 실행 시점: 에이전트가 특정 명령을 만들 때, 대상 시스템에 도달하기 전에 그 명령을 세션이 실제로 열린 목적과 대조하는 무언가가 있는가? (2번 일입니다. 여기에 실제 답을 가진 벤더는 더 적고, 그 판정이 실제로 무언가를 막는지 아니면 기록만 되는지도 물어볼 필요가 있습니다.)
• 세션 종료 후: 에이전트의 명령이 실제로 한 일이 다음 세션을 규율할 정책을 바꾸는가, 아니면 어떤 권한이 안 쓰였는지만 바꾸는가? (3번 일입니다. 이 질문에 에이전트 전용 버전을 내놓은 AI 네이티브 PAM 벤더는 아직 보지 못했습니다.)

프로토콜 계층조차 허가와 판단 사이에 같은 경계선을 긋습니다. 2026년 7월 28일 공개된 MCP 스펙은 클라이언트 아이덴티티를 함께 전달하고, 도구가 호출 중간에 확인을 요청할 수 있게 합니다(MCP spec release, 2026-07-28). 이 스펙의 권한 부여 챕터는 호출자가 방금 시도한 작업에 필요한 범위를 갖고 있는지를 판단하고, 부족하면 단계적 인증을 요구합니다. 그 작업이 세션이 열린 목적에 맞는 일인지는 애초에 묻지 않습니다. '이 호출자가 맞는 범위를 갖고 있는가'와 '지금 이 일을 하는 게 맞는가'를 서로 다른 문제로 다루는 것입니다.

올해 AI 네이티브 PAM을 평가하는 CISO는 사실 한 단어 아래 쌓인 세 가지 별개의 주장을 평가하는 셈입니다. 1번 일은 필요하지만 대부분 이미 상품화됐습니다. 2번 일은 지금 실질적인 차별점이 갈리는 지점에 가깝습니다. 3번 일, 즉 아이덴티티 거버넌스 도구가 사람의 권한에 대해 이미 하고 있는 것처럼 AI 에이전트에 맞춰 루프를 닫는 일은 카테고리가 향해 가는 방향으로 보입니다. 저희도 그 에이전트 전용 버전을 내놓은 AI 네이티브 PAM 벤더는 아직 보지 못했습니다. '거버넌스'를 판다는 벤더에게는 기능 목록에 이름을 올려놓았는지가 아니라 이 세 가지 중 실제로 어디에 답하는지를 물어봐야 합니다.