규정은 누가 명령을 실행했는지 남기라고 요구합니다. 계약직의 BYOD 환경에서는 계정 주인과 실제로 명령을 고른 주체가 다를 수 있습니다.
Vanta, Drata, Secureframe 같은 GRC 플랫폼을 포함해 'AI 컴플라이언스 소프트웨어'로 불리는 도구들은 컴플라이언스 의무를 추적합니다. 일부는 관리 대상 SaaS 안에서 에이전트의 동작을 표시하거나 차단하기도 합니다. 하지만 개인 기기와 프로덕션 호스트 사이에 들어가 셸 명령을 판단하는 도구는 아닙니다. 이 글의 출발점은 단순합니다. 이 명령을 실제로 실행한 주체는 누구인가입니다.
모든 규정이 행위자를 요구하지만, 에이전트를 행위자로 적어 둔 규정은 없습니다
특권 실행을 다루는 규정은 AI 에이전트를 별도 범주로 적어 두지 않았습니다. 대신 명령을 실행한 주체를 식별할 수 있어야 한다고 요구합니다. '사용자', '개인', '주체' 같은 말은 에이전트가 등장하기 전에 만들어졌습니다.
NIST SP 800-53 Rev. 5 AU-3은 감사 기록에 "해당 이벤트와 연관된 개인, 주체, 객체/개체의 신원"을 포함하도록 요구합니다. AU-10은 여기서 한 단계 더 나아갑니다. 부인 방지를 위해서는 "개인(또는 개인을 대신해 동작하는 프로세스)이 해당 행위를 수행했다"는 반박 불가능한 증거가 있어야 한다는 것입니다. 이 통제는 사람을 대신해 동작하는 프로세스를 이미 상정하고 있었습니다. 다만 그 프로세스를 스크립트로 가정했을 뿐, LLM은 염두에 두지 않았습니다.
다른 규정도 같은 지점을 봅니다
PCI DSS v4.0.1은 같은 지점을 세 방향에서 조입니다. Req. 10.2.2는 감사 로그에 이벤트별 사용자 식별을 요구하고, Req. 8.2.2는 공유 계정과 범용 계정을 문서화되고 관리되는 예외로만 제한하며, Req. 8.6은 비인간 아이덴티티를 별도 범주로 다룹니다. HIPAA Security Rule §164.312(a)(2)(i)는 사용자 신원을 추적할 고유 식별자를 요구합니다. NYDFS 23 NYCRR 500.7은 적용 대상 기업이 특권 계정을 해당 역할에 필요한 범위로 제한하도록 요구하고, Class A 기업에는 특권 접근 관리(PAM) 솔루션 운영까지 요구합니다. 둘 다 2025년 5월 1일부터 시행 중입니다. EU AI Act의 Annex III 고위험 시스템 적용 시한은 Digital Omnibus에 따라 2027년 12월 2일로 미뤄졌습니다. 이때 Art. 12(1)의 자동 이벤트 로깅 의무와 Art. 26(6)에 따른 배포자의 최소 6개월 보관 의무도 함께 도래합니다. 이 의무는 자사 프로덕션 호스트에서 셸 명령을 실행하는 인프라 운영 에이전트가 애초에 Annex III 고위험 시스템으로 분류된다는 전제 위에 있고, 이 분류를 두고는 아직 공식 가이드가 없습니다. 지금 시행 중인 것은 Art. 50의 투명성 의무와 Art. 4의 AI 리터러시 의무뿐이고, 둘 다 행위자 귀속 문제에는 닿지 않습니다.
NIST AU-3, PCI 10.2.2, HIPAA §164.312(a)(2)(i)는 모두 명령마다 실행 주체를 기록하라고 요구합니다. 이 의무는 이미 시행 중입니다. NIST AU-10과 NYDFS 500.7은 시스템이 스스로 적어 넣은 값이 아니라, PAM 솔루션 같은 증명 가능한 출처에서 나온 기록을 요구합니다. EU AI Act의 Art. 12와 Art. 26(6)은 2027년부터 기록의 보관과 재구성에 초점을 둘 뿐, 행위자를 지목하는 문제는 다루지 않습니다. 어느 규정도 행위자가 사람인지 AI인지에 따라 통제를 다르게 적용하라고 요구하지는 않습니다. 이 구분은 컴플라이언스 항목이 아니라 제품이 내려야 할 판단입니다. 누가 명령을 실행했는지 알 수 없다면 뒤의 통제도 의미가 없습니다.
계약직 직원의 BYOD 환경에서 기록이 어긋나는 방식
상황을 하나 가정해 보겠습니다. 계약직 직원이 개인 노트북에서 자기 이름으로 발급받은 계정에 로그인합니다. 그 계정으로 프로덕션 데이터베이스를 대상으로 에이전트 자동화를 실행합니다. 감사 로그에는 계약직 이름이 남지만, 명령을 고른 쪽은 에이전트입니다. 기존 규정은 계정 주인과 실행 주체가 같거나, 예측 가능한 스크립트가 사람을 대신한다고 가정합니다. 스스로 명령을 고르는 에이전트는 이 전제 밖에 있습니다. 계정이 사람에게 연결돼 있다는 것은 행위자 칸이 비어 있다는 뜻이 아닙니다. 틀린 이름이 적혀 있다는 뜻입니다.
기기도 관리 대상이 아닐 수 있습니다. 계약직은 같은 시스템을 다루는 정규직보다 느리고 오래된 장비를 받는다고 개발자 포럼에서 말합니다. 문서상 BYOD를 금지해도 지급 장비 성능이 업무 수준에 못 미치면 개인 노트북은 업무에 들어옵니다. 이때 로그는 에이전트가 아니라 계약직이 명령을 실행했다고 기록합니다.
이는 계약직만의 결함이라기보다, 계약직과 BYOD에서 가장 먼저 드러나는 문제에 가깝습니다. 개인 기기와 무인 자동화가 맞물리면 계약직 본인의 계정이 본인이 입력한 적 없는 명령을 실행하기 시작합니다. 그 접근 권한 위에 올라탄 AI 에이전트는 악의가 아니라 구조 때문에 보이지 않게 됩니다. 드문 시나리오도 아닙니다. 82%의 기업이 이미 환경 어딘가에서 정체를 알 수 없는 AI 에이전트가 돌아가고 있다고 답했고, 65%는 지난 1년 사이 AI 에이전트 관련 사고를 겪었습니다. 공식적인 폐기 절차를 갖춘 곳은 21%뿐입니다.
기록은 명령이 실행되는 구간에서 남아야 합니다
GRC 플랫폼이 명령 실행 구간 밖에 있다는 말은 이 뜻입니다. SaaS 안에서 무엇을 표시하더라도 기기와 호스트 사이에서 명령을 실행할지 결정하지는 않습니다. 세션이 Alpacon을 거치는 경우, Alpacon이 바로 이 구간에 자리합니다. Work Session에는 사용자 신원, 선언한 작업 목적, 세션이 넘을 수 없는 허용 범위를 함께 기록합니다. 따라서 계정 이름뿐 아니라 누가 어떤 작업을 하려 했는지도 남습니다. exec lane에서는 에이전트가 실행하는 명령이 세션에 선언된 목적을 벗어난다고 AI가 판단하면 자동 승인 대신 사람에게 넘깁니다.
'AI 컴플라이언스 소프트웨어'를 검토하고 있다면, 검색창이 던지는 질문보다 더 좁혀서 벤더에게 물어보세요. '컴플라이언스를 추적하느냐'가 아니라, '계약직의 에이전트가 명령을 실행하면 그 기록에는 누구의 이름이 남고, 그 이름은 사실이냐'라고 말입니다.
