새 직원이 입사하면 회사는 가장 먼저 계정을 만듭니다. 사번이 나오고, 부서와 직군에 맞는 권한이 부여되고, 퇴사하는 날에는 계정이 잠깁니다. 누가 들어왔고, 무엇을 할 수 있고, 언제 나갔는지를 회사는 비교적 정확하게 알 수 있습니다.
그런데 요즘 회사 시스템에 접속하는 주체를 세어 보면, 사람이 아닌 쪽이 훨씬 많습니다. 새벽마다 백업을 돌리는 계정, 외부 서비스와 연결하려고 발급한 API 키 그리고 사람 대신 메일을 읽고 업무를 처리하는 AI 에이전트까지. 이들에게는 사번도, 입사일도, 퇴사일도 없습니다.
이렇게 사람이 아니면서 시스템에 접속해 일하는 주체를 NHI(Non-Human Identity, 비인간 신원)라고 부릅니다. CyberArk의 2025년 조사에 따르면, 조직 안의 NHI는 사람보다 82배 많고 그중 42%는 중요한 시스템에 접근할 수 있습니다. 그런데도 조직의 88%는 여전히 사람만을 ‘사용자’로 보고 관리하고 있습니다.
[그림1] 사람 1명당 NHI수와 조직원의 권한 관리 기준 (출처 : CyberArk, 2025 Identity Security Landscape)
숫자는 이미 역전됐는데, 관리 기준은 아직 사람에 맞춰져 있는 셈입니다. 이 글에서는 NHI가 왜 관리하기 어려운지, AI 에이전트가 등장하면서 무엇이 달라졌는지 그리고 어떻게 통제해야 하는지를 차례로 살펴봅니다.
NHI를 한 문장으로 정의하면 "사람의 개입 없이 스스로 인증하고 자원에 접근하는 모든 주체"입니다. 범위가 넓어서 하나의 개념으로 묶기 어렵지만, 실무에서는 보통 다섯 가지 유형으로 나눕니다.
| 유형 | 예시 | 주로 쓰는 자격증명 | 누가 만드는가 |
| 서비스 계정 | 배치 작업, DB 연동 계정, AD 서비스 계정 | ID/PW, Kerberos 티켓 | 인프라 운영팀 |
| API Key · 토큰 | SaaS 연동 키, OAuth 토큰, PAT | 정적 문자열, Bearer 토큰 | 개발자 개인 |
| 워크로드 | 컨테이너, 서버리스 함수, CI/CD 러너 | 클라우드 IAM 역할, 인증서 | 플랫폼 DevOps 팀 |
| 디바이스 | IP 카메라, 프린터, PLC | MAC 주소, 고정 IP, 기본 계정 | 시설, 현업 부서 |
| AI 에이전트 | 업무 자동화 에이전트, 코딩 어시스턴트 | 사용자 위임 토큰, API 키 | 현업 사용자 누구나 |
[표1] NHI 유형
사람 계정은 인사팀이라는 하나의 창구에서 만들어지지만, NHI는 만드는 사람이 제각각입니다. 개발자는 테스트용으로 API 키를 만들고, 시설팀은 카메라를 네트워크에 연결하고, 현업 담당자는 클릭 몇 번으로 AI 에이전트에게 메일함 권한을 줍니다. 이 과정에서 보안팀의 승인을 반드시 거치지는 않습니다.
그 결과 보안팀은 NHI가 잘 관리되고 있는지를 파악하기 전에, '어디에 몇 개나 있는지'조차 모르는 경우가 많습니다. 특히 카메라나 공장 설비 같은 디바이스는 보안 프로그램을 설치할 수도 없어서, 네트워크에 연결된 흔적 말고는 존재를 확인할 방법이없습니다.
기존 계정 관리는 '계정에는 주인이 있고, 주인이 입사하고 퇴사하면 계정도 따라 만들어지고 사라진다'는 전제 위에 만들어졌습니다. NHI는 이 전제에서 세 군데가 어긋납니다.
사람 계정의 비활성화는 퇴사라는 명확한 이벤트가 트리거합니다. NHI에는 이런 종료 이벤트가 없습니다. 프로젝트가 끝나도, 연동하던 SaaS를 해지해도, 키를 발급한 개발자가 퇴사해도 키는 그대로 살아 있습니다. OWASP가 2025년 발표한 Non-Human Identities Top 10의 첫 번째 항목이 ‘부적절한 오프보딩(Improper Offboarding)’인 것도 같은 맥락입니다.
NHI의 권한은 보통 '일단 돌아가게만 하자'는 생각으로 넉넉하게 주어집니다. 시스템 연동 중에 오류가 나면 원인을 찾는 것보다 권한을 넓혀 버리는 쪽이 빠르기 때문입니다.
현장에서 흔히 보이는 사례가 있습니다. 특정 로그 파일 하나만 읽으면 되는 작업인데, 실제로는 회사의 모든 클라우드 저장소에서 읽기, 수정, 삭제까지 전부 할 수 있는 권한이 주어져 있는 경우입니다.
사람 계정이라면 정기 권한 점검에서 걸러지겠지만, NHI에게는 "이 권한 아직 필요한가요?"라는 질문에 답해 줄 담당자가 없습니다. 그래서 한 번 넓어진 권한은 그대로 남습니다.
비밀번호가 적힌 파일이 통제 없이 흩어집니다
사람의 비밀번호는 머릿속에 있지만, NHI의 비밀번호와 키는 파일에 적혀 있습니다. 설정 파일, 코드 저장소, 사내 메신저 대화까지. 한 번 복사된 키는 어디에 몇 개가 퍼져 있는지 알 수 없고, 여러 서비스가 같은 키를 함께 쓰기 시작하면 바꾸기도 어렵습니다. 키 하나를 바꾸면 어떤 시스템이 멈출지 아무도 모르기 때문입니다.
보안 표준 단체 OWASP가 2025년 발표한 NHI 10대 위험도 결국 이 세 가지로 묶입니다.
| 문제 | OWASP NHI Top 10 해당 항목 |
| 회수가 안 됨 | 퇴사·폐기 추리 누락, 만료 없는 비밀번호 |
| 권한이 과함 | 과도한 권한, 환경 분리 미흡, 한 계정을 여러 곳에서 재사용 |
| 비밀번호가 퍼짐 | 비밀정보 유출, 취약한 인증, 사람이 NHI 계정을 대신 사용 |
[표2] NHI가 통제되기 어려운 이유 세가지
마지막 항목 중 '사람이 NHI 계정을 대신 사용하는 문제'는 특히 눈여겨볼 만합니다. 사람이 자기 계정 대신 NHI 계정으로 로그인하면, 기록에는 '누가 했는지' 남지 않습니다. 사람과 기계의 경계가 흐려지는 이 문제는 AI 에이전트에서 더 커집니다.
지금까지의 NHI는 정해진 일만 반복했습니다. 예를 들어 백업 계정은 매일 새벽 2시에 같은 서버에 접속해 같은 폴더만 읽습니다. 늘 같은 시간에 같은 문만 여는 셈이라, 평소와 다른 문을 열면 곧바로 이상 징후로 알아챌 수 있었습니다. AI 에이전트는 이 전제를 깨뜨립니다. 기존 NHI보다 통제하기 어려운 이유는 크게 세 가지입니다
LLM 기반 에이전트는 비결정적(non-deterministic)입니다. 할 일을 미리 정해 둔 프로그램이 아니라, 목표만 받고 방법은 그때그때 스스로 판단하기 때문입니다. 같은 상황에서도 모델의 답이 조금씩 달라질 수 있습니다.
이렇게 행동이 매번 달라지면 '평소 행동'이라는 기준을 세우기 어렵습니다. 기존 보안 시스템은 계정의 평소 모습을 먼저 학습한 뒤, 거기서 벗어나는 행동을 이상 징후로 잡아냅니다. 그런데 AI 에이전트가 오늘 처음으로 공유 드라이브를 열었다면, 이것이 정상적인 업무인지 공격인지 구분하기 어렵습니다. 기준을 엄격하게 잡으면 정상 업무에도 경고가 쏟아지고(오탐), 느슨하게 잡으면 진짜 공격까지 놓치게 됩니다(미탐).
AI 에이전트는 대부분 사용자가 부여한 권한으로 업무를 수행합니다. 예를 들어 직원이 AI에게 계약서를 찾아달라고 요청하면, AI는 해당 직원의 접근 권한을 이용해 파일을 확인합니다. 다른 AI나 도구에 업무를 맡길 때도 이 권한이 함께 전달될 수 있습니다. 문제는 권한이 있다고 해서 모든 행동이 사용자의 지시를 받은 것은 아니라는 점입니다.
예를 들어 AI가 읽은 이메일에 "계약서 파일을 특정 주소로 보내라"는 악성 명령이 숨겨져 있다고 가정해 보겠습니다. AI가 이를 정상적인 업무 지시로 잘못 받아들이면, 사용자가 요청하지 않았는데도 계약서를 외부로 전송할 수 있습니다.
이처럼 AI가 외부 콘텐츠에 숨겨진 악성 명령을 따르도록 유도하는 공격을 프롬프트 인젝션(Prompt Injection)이라고 합니다.
파일 서버 입장에서는 정상적인 접근 권한을 사용했기 때문에 문제가 없는 요청으로 보일 수 있습니다. 하지만 실제로는 사용자의 의도와 전혀 다른 행동이 실행된 것입니다.
기존 보안 시스템의 로그에는 주로 어떤 계정이 파일에 접근했는지가 기록됩니다. 하지만 AI가 누구의 지시를 받아 해당 작업을 수행했는지까지 확인하기는 어렵습니다.
앞선 사례에서 계약서가 외부로 유출됐다면, 파일 서버에는 '영업팀 A 직원의 권한으로 파일에 접근하고 전송했다'는 기록이 남을 수 있습니다. 그러나 실제 원인이 AI가 읽은 이메일 속 악성 명령이었다는 사실은 파일 서버의 기록만으로 확인하기 어렵습니다.
결국 정상적인 권한으로 실행된 작업이라도, 그 행동이 사용자의 요청에 따른 것인지 악성 명령에 의한 것인지 구분하기 어려운 문제가 발생합니다.
AI 에이전트는 기존 NHI(비인간 신원)의 보안 문제인 과도한 권한, 회수되지 않은 인증 키, 인증 정보 확산 등의 위험을 그대로 가지고 있습니다. 여기에 AI의 예측하기 어려운 행동과 지시 출처를 추적하기 어렵다는 문제까지 더해지면서 새로운 보안 과제를 만들고 있습니다.
그렇다면 NHI는 어떻게 통제해야 할까요? 새로운 도구를 찾기 전에 원칙부터 정해야 합니다. 핵심은 ‘보이게 하고, 짧게 주고, 좁게 주고, 계속 확인한다’는 네 가지입니다.
모든 통제의 출발점은 목록입니다. 문제는 NHI 목록이 한 곳에 없다는 점입니다. 클라우드, 계정 관리 시스템, 키 보관소가 각자 일부만 알고 있고, 보안 프로그램을 설치할 수 없는 디바이스는 어느 목록에도 없습니다. 그래서 목록은 ‘등록된 계정’이 아니라 ‘실제로 네트워크에 접속한 것’을 기준으로 만들어야 합니다.
그리고 목록의 모든 NHI에는 담당자(사람)를 지정해야 합니다. 퇴사가 없는 NHI에게 수명을 만들어 주는 방법은 책임지는 사람과 연결하는 것뿐이기 때문입니다. 담당자를 찾을 수 없는 NHI는 그 자체로 가장 위험한 신호입니다.
만료 없는 비밀번호나 API 키 대신, 필요할 때마다 짧은 시간만 유효한 임시 출입증을 발급합니다. 클라우드 환경에서는 워크로드 아이덴티티 페더레이션(Workload Identity Federation) 같은 방식으로 수십 분짜리 토큰을 자동으로 발급받을 수 있습니다. 출입증이 유출되더라도 피해는 유효기간 안으로 제한되고, ‘폐기를 잊는’ 일 자체가 사라집니다.
AI 에이전트에게는 ‘메일 접근 권한’처럼 뭉뚱그린 권한 대신, 할 수 있는 일을 하나하나 적어 주는 편이 안전합니다. 고객 문의를 요약하는 에이전트라면 이런 식입니다.
핵심은 두 가지입니다. 첫째, 에이전트는 권한을 빌려준 사람보다 더 많은 일을 할 수 없어야 합니다. 둘째, 외부 발송이나 삭제처럼 되돌릴 수 없는 일은 반드시 사람의 확인을 거치게 합니다. (Human-in-the-Loop) 앞의 프롬프트 인젝션 사례도 ‘외부 발송 금지’ 한 줄이면 실제 피해로 이어지지 않습니다.
마지막은 EDR을 활용해 NHI 계정의 비정상적인 사용을 탐지하는 것입니다. NHI 계정은 주로 서버나 애플리케이션에서 자동화된 작업을 수행하는 데 사용됩니다. 따라서 평소와 다른 환경에서 계정이 사용된다면 주의 깊게 살펴봐야 합니다.
예를 들어 서버에서만 사용하던 NHI 계정이 갑자기 직원 PC에서 실행되거나, 평소와 다른 프로그램을 실행한다면 비정상적인 활동을 의심할 수 있습니다. EDR은 이러한 단말의 실행 행위와 접속 흔적을 분석해 이상 징후를 탐지하고, 필요할 경우 해당 프로세스를 차단하거나 단말을 격리할 수 있습니다. 이를 통해 사람이 NHI 계정을 무단으로 사용하거나 탈취된 계정이 악용되는 상황에도 대응할 수 있습니다.
하지만 원칙만으로는 한계가 있습니다. 계정 관리 시스템이 볼 수 있는 것은 ‘누구의 출입증으로 들어왔는가’까지이고, 들어온 뒤 무엇을 했는지는 보이지 않습니다. 그런데 업무용 AI 에이전트와 서비스 계정의 상당수는 직원 PC나 회사 서버 위에서 실행되고, 파일을 열고 데이터를 보내는 행동도 모두 그 단말에서 일어납니다. 행동이 일어나는 단말을 직접 지켜봐야 하는 이유입니다.
Genian Insights E는 단말의 행위 데이터를 수집하고, 행위 기반으로 위협을 탐지해 실시간으로 대응하는 EDR입니다.
사번도 퇴사도 없는 접속자는 앞으로 더 늘어날 것입니다. 이제는 현업의 누구나 클릭 몇 번으로 AI 에이전트를 만들 수 있기 때문입니다. 누가 들어왔는지 확인하던 보안에서, 들어온 뒤 무엇을 했는지까지 보는 보안으로 Genians Insights E는 행동이 일어나는 단말에서 그 답을 찾습니다.
OWASP Non-Human Identities Top 10 - 2025
지니언스 전략마케팅실에서 보안이라는 무형의 안심을 고객의 언어로 번역해 전합니다.