AI 에이전트의 human-in-the-loop 승인 절차는 대개 누가 승인하는지에 초점을 둡니다. 어느 채널에서 승인이 이뤄지는지는 아예 다루지 않거나, 다뤄도 일관성이 없습니다. 에이전트나 탈취된 토큰이 세션을 열고 검토가 필요한 명령을 실행한 뒤, 같은 자격증명과 채널로 그 검토를 승인할 수 있다면 사실상 자기 요청을 승인한 셈입니다. 해법은 두 번째 사람을 두는 데 있지 않습니다. 요청을 낸 에이전트가 접근할 수 없는 채널에서 승인하게 해야 합니다.
위협은 책임감 없는 관리자가 아닙니다
많은 팀은 이미 이런 구성을 쓰고 있습니다. AI 에이전트가 슈퍼유저 권한을 가진 자격증명으로, 단계마다 사람에게 확인받지 않고도 인프라를 직접 운영합니다. 세션을 열고 정책 엔진이 검토가 필요하다고 표시한 명령을 실행한 뒤, 같은 자격증명과 채널로 자신의 요청을 승인합니다. 이 과정에는 사람이 관여하지 않습니다.
이는 가상의 예외 사례가 아닙니다. 채널은 확인하지 않고 신원만 확인하는 AI 에이전트 승인 게이트에는 이런 취약점이 기본으로 남습니다. 신원 확인은 '이 계정에 승인 권한이 있는가'를 묻습니다. 채널 확인은 '이 승인이 에이전트의 자격증명이 접근할 수 없는 채널에서 들어오는가'를 확인합니다. 승인할 수 있는 주체를 이미 승인 권한을 가진 모든 계정으로 두고, 에이전트의 자격증명에도 그 권한이 있다면 승인 단계는 형식에 그칩니다. 유출된 API 토큰도 마찬가지입니다. 에이전트가 없어도 탈취한 자격증명 하나로 요청부터 승인까지 끝낼 수 있습니다.
이 위협 모델은 자기 판단을 남용하는 관리자를 상정하지 않습니다. 슈퍼유저가 자기 팀의 일상적인 작업을 승인하는 일은 정상이며, 옆에서 지켜보는 두 번째 사람이 필요하지 않습니다. 문제는 같은 실행 경로가 요청을 내고 그 요청을 승인하는 데 있습니다.
현재 프로덕션에서 에이전트를 운영하는 곳 대부분이 바로 이런 식으로 모니터링 사각지대에 놓여 있습니다. 그래서 승인 게이트 자체의 무결성이 중요합니다. Gravitee의 2026년 State of AI Agent Security 보고서는 영국과 미국의 시니어 기술 리더 750명을 조사한 결과, 프로덕션 AI 에이전트의 평균 모니터링 커버리지는 52%에 그쳤다고 밝혔습니다. 조직의 54%는 지난 12개월 안에 AI 에이전트 보안·데이터 프라이버시 사고를 겪었거나 의심한 적이 있다고도 밝혔습니다.
승인 경로를 분리하는 규칙
Alpacon은 에이전트나 탈취 토큰이 자기 요청을 승인하지 못하게, 2인 규칙보다 단순한 제약을 둡니다. 에이전트 CLI, API 토큰, 서비스 토큰 같은 실행 채널은 승인 채널로 등록할 수 없습니다. 따라서 에이전트나 유출된 토큰은 자신이 낸 요청을 승인할 수 없습니다. 등록된 승인 채널인 웹 콘솔과 Slack만 보류된 동작을 '승인됨' 상태로 바꿀 수 있습니다.
이 구조는 사람인지 에이전트인지를 추측하지 않고 채널을 기준으로 판단합니다. 시스템은 승인을 처리할 때 해당 자격증명이 어느 채널에서 온 것인지 자격증명에서 직접 도출합니다. 대화형 세션이라면 애플리케이션 컨텍스트를, 프로그램 방식이라면 토큰 유형을 기준으로 삼습니다. 이렇게 식별한 채널을 워크스페이스별로 설정할 수 있는 승인 채널 목록과 대조합니다. 등록되지 않은 새 채널은 승인할 수 없도록 fail-closed로 처리합니다.
채널 검사는 행동을 보고 사람이 조작하는지 추론하지 않습니다. 에이전트나 이를 조종하는 공격자가 그런 신호를 흉내 낼 수 있기 때문입니다. 시스템은 호출자가 주장한 값이 아니라 자격증명에서 채널을 도출합니다. 그래서 요청을 사람이나 스크립트가 보냈는지와 관계없이 같은 검사를 적용합니다. 동일한 자격증명 유형의 토큰을 에이전트가 여러 개 발급해도 이 배제는 유지됩니다. 한 인터페이스에서만 승인 버튼을 숨겨서는 충분하지 않습니다. 같은 자격증명을 쓰는 다른 표면에서 승인 엔드포인트를 직접 호출할 수 있기 때문입니다. 자격증명 유형에 규칙을 적용하면 그 경로도 막습니다.
승인 채널 목록에 등록됐다고 보장이 끝나는 것은 아닙니다. 채널마다 실제 사람이 개입했음을 각자의 방식으로 확인합니다. 웹 콘솔에서는 UI의 의도적인 승인 동작과 추가 존재 확인(step-up presence)을 요구하고, Slack은 서명된 요청과 워크스페이스의 아이덴티티 매핑을 이용합니다.
채널 검사는 Alpacon의 실행 제어 레이어 안에 있습니다. 런타임 위험 평가에서 명확히 안전하거나 금지된 것으로 분류되지 않은 명령은 실행 전에 사람의 확인을 받도록 보류할 수 있습니다. 보류를 실제로 강제할지 기록만 할지는 워크스페이스별 정책에서 정합니다. 위험 레인(risk lane)의 기본 동작은 monitor-and-record입니다. 승인 경로를 분리하는 규칙은 이와 별개로 작동합니다. 위험 레인의 기본값과 관계없이, 보류를 유발한 실행 자격증명은 그 보류를 직접 풀 수 없습니다.
이 규칙은 승인 경로를 분리하는 규칙입니다. 요청자와 승인자를 무조건 다른 사람으로 두는 규칙은 아닙니다. 같은 사람이 자신의 CLI에서 동작을 요청하고 Slack에서 그 요청을 승인하는 것은 허용되는 정상적인 흐름입니다. 이 덕분에 관리자가 한 명뿐인 워크스페이스도 별도 관리자를 두지 않고 승인 절차를 운영할 수 있습니다. 요청자와 승인자가 반드시 달라야 하는 2인 승인(true two-person control)은 이 규칙 위에 얹기로 확정된 설계이며, 지금 바로 켤 수 있는 기능은 아닙니다.
이 규칙이 다루지 않는 범위
이 규칙은 세션을 열거나, 세션 중간에 범위를 넓히거나, 그 순간에 권한 있는 명령을 승인하는 등 런타임 접근 결정을 다룹니다. 누가 승인할 수 있는지를 애초에 바꾸는 정책 변경은 다루지 않습니다. 관련은 있지만 별도의 영역입니다.
표준이 실제로 규정하는 것
여기서 인용한 NIST 문서 두 건은 모두 에이전트를 염두에 두고 작성되지는 않았습니다. 사람 운영자와 서비스 계정이 대상입니다. 그래도 가장 가까운 통제 항목은 정확히 짚어볼 필요가 있습니다. 이 글에서 다루는 승인 경로 분리와 겹치지 않는 부분을 보여 주기 위해서입니다.
NIST SP 800-63B-4는 2025년 7월 SP 800-63-3을 대체한 SP 800-63-4 문서군의 일부입니다. 이 문서는 out-of-band authenticator를 "a physical device that is uniquely addressable"(고유한 주소로 지정 가능한 물리 장치)로 정의하고, "an independent communications channel"(독립된 통신 채널)로 통신한다고 규정합니다. 주 채널과 섞이지 않는 별도 인증 경로를 둔다는 점에서는 이 글의 출발점과 닮았습니다. 다만 여기서 다루는 규칙은 하드웨어가 아니라 자격증명 유형을 분리하므로 더 느슨합니다.
NIST SP 800-53 AC-5(직무 분리, Separation of Duties)와 AC-3(2)("Enforce dual authorization for [Assignment: organization-defined privileged commands and/or other actions]", 조직이 정의한 권한 있는 명령 등에 대해 이중 인가를 강제한다)는 요청자와 승인자를 분리하는 통제입니다. 이 통제들은 이 글의 승인 경로 분리에는 대응하지 않습니다. 대신 위에 얹기로 확정된 2인 승인이 충족할 요건에 해당합니다. 권한 있는 동작이 실행되는 순간의 재인증에는 IA-11(재인증, Re-authentication)이 맞는 통제입니다.
OWASP Top 10 for Agentic Applications 2026은 반대 방향에서 이 문제에 접근합니다. "최소 에이전시(Least-Agency)"는 "불필요한 자율성을 피하라"는 권고입니다. 필요한 곳 이상으로 에이전트에 자율성을 부여하면 가치는 더하지 못한 채 공격 표면만 넓힌다는 이유입니다. 자율성을 줄이라는 요구일 뿐, 누가 승인을 처리하는지에 대한 규칙은 아닙니다. Cloud Security Alliance의 에이전트형 IAM 논문은 관련된 직관을 자격증명 관점에서 다룹니다. 에이전트나 이를 침해한 공격자가 조용히 재사용할 수 있는 상시 권한 대신, 필요한 순간에만 발급되고 특정 동작에만 유효하며 자동으로 만료되는 자격증명을 쓰라는 것입니다.
아직 열려 있는 부분
남은 과제는 승인 버튼을 누를 수 있는 사람의 범위를 요청별로 지정된 승인자로 좁히는 일입니다. 확정된 설계이지만 아직 구현되지 않았습니다.
사람이 에이전트에게 로그인된 브라우저 세션을 넘기면 승인 채널까지 넘긴 셈이 됩니다. 어떤 채널 규칙도 이 경우는 잡아내지 못합니다. 자격증명을 그대로 넘긴 일이므로, 다른 자격증명 공유와 다를 게 없습니다.
정리
같은 자격증명으로 요청과 승인을 모두 처리할 수 있다면, 신원만 확인하는 human-in-the-loop 통제는 단계만 늘어난 형식적 승인일 뿐입니다. 실효성 있는 해법은 승인 경로를 분리하는 데 있습니다. 실행 채널은 승인하지 못하게 막고, 채널은 행위자를 추측하지 않고 자격증명에서 직접 도출합니다. 현재의 보장은 이 규칙에 기반합니다. 요청자와 승인자를 분리하는 2인 승인은 그 위에 추가할 확정 설계일 뿐입니다.
FAQ
별도 채널 승인은 요청자와 승인자가 반드시 다른 사람이어야 한다는 뜻인가요? 아닙니다. 그것은 별도의 더 엄격한 통제입니다. 여기서 다루는 기본 원칙은 채널 분리입니다. 같은 사람이 자신의 CLI에서 동작을 요청하고 Slack에서 그 요청을 승인하는 것은 허용됩니다. 이 덕분에 관리자가 한 명뿐인 워크스페이스도 운영할 수 있습니다. 요청자와 승인자가 반드시 다른 사람이어야 하는 2인 승인은 이 위에 얹기로 확정된 설계이며, 지금 바로 쓸 수 있는 기능은 아닙니다.
이 규칙이 다루지 않는 범위는 무엇인가요? 이 규칙은 세션을 열거나, 세션 중간에 범위를 넓히거나, 그 순간에 권한 있는 명령을 승인하는 등 런타임 접근 결정을 다룹니다. 누가 승인할 수 있는지를 애초에 바꾸는 정책 변경은 다루지 않으며, 사람이 에이전트에게 이미 로그인된 브라우저 세션을 그대로 넘기는 경우도 잡아내지 못합니다. 이는 다른 자격증명 공유와 다를 게 없는 자격증명 넘김이기 때문입니다.
