서론
기업의 AI 활용은 챗봇이나 문서 요약 도구를 넘어 업무 시스템에 직접 접속해 행동하는 에이전트 단계로 이동하고 있다. 일정 조회, 티켓 처리, 코드 수정, 구매 승인 보조, 고객 응대, 보안 경보 분류 같은 작업은 더 이상 사람의 화면 안에서만 끝나지 않는다. AI 에이전트가 API 토큰, 서비스 계정, OAuth 권한, 클라우드 역할, SaaS 커넥터를 통해 여러 시스템을 오가며 업무를 수행한다.
이 변화가 던지는 질문은 단순하다. AI 에이전트에도 사번이 필요한가. 표현은 비유적이지만 보안 관점에서는 매우 현실적인 질문이다. 어떤 에이전트가 누구의 승인으로 만들어졌는지, 어떤 권한을 갖는지, 어떤 업무를 대신 수행하는지, 사고가 났을 때 누구에게 책임을 물을 수 있는지 식별할 수 있어야 한다. 그렇지 않으면 AI 에이전트는 생산성 도구가 아니라 추적되지 않는 비인간 ID, 즉 Non-Human Identity의 새로운 사각지대가 된다.
본론
1. AI 에이전트는 새로운 서비스 계정이지만 위험은 더 크다
기존의 비인간 ID는 오래전부터 존재했다. 배치 작업 계정, CI/CD 토큰, 서버 간 API 키, 클라우드 역할, 데이터베이스 서비스 계정이 대표적이다. 문제는 AI 에이전트가 이 계정들과 유사한 권한을 갖지만 행동 방식은 훨씬 더 동적이라는 점이다.
전통적인 자동화는 대체로 정해진 스크립트와 일정에 따라 반복 작업을 수행한다. 반면 AI 에이전트는 목표를 입력받고, 중간 판단을 내리고, 여러 도구를 조합해 다음 행동을 선택한다. 같은 권한이라도 위험의 질이 달라진다. 읽기 권한만 가진 에이전트가 민감 정보를 과도하게 수집할 수 있고, 쓰기 권한을 가진 에이전트가 잘못된 프롬프트나 오염된 입력에 반응해 의도하지 않은 변경을 실행할 수 있다.
기업이 특히 주의해야 할 지점은 권한의 상속이다. 많은 조직은 에이전트를 실제 사용자 계정에 붙여 실행하거나, 범용 서비스 계정 하나를 여러 에이전트가 공유하게 한다. 이 방식은 초기 도입에는 빠르지만 감사와 책임 추적을 무너뜨린다. 로그에는 "automation-service"만 남고, 어떤 에이전트가 어떤 업무 맥락에서 행동했는지 확인하기 어렵다. 사고 조사 시점에는 권한이 너무 넓었는지, 입력이 조작됐는지, 승인 절차가 우회됐는지 구분하기 힘들어진다.
2. 사번의 핵심은 이름이 아니라 수명주기와 책임이다
AI 에이전트에 사번을 부여한다는 말은 사람처럼 급여 시스템에 등록하자는 뜻이 아니다. 핵심은 조직 내 정식 신원으로 등록하고, 생성부터 폐기까지 전 과정을 관리하자는 것이다. 최소한 다음 질문에 답할 수 있어야 한다.
- 이 에이전트의 소유 부서는 어디인가
- 업무 책임자는 누구인가
- 접근 가능한 시스템과 데이터 범위는 무엇인가
- 권한은 언제 승인됐고 언제 재검토되는가
- 비정상 행동이 탐지되면 누가 중지할 수 있는가
- 더 이상 쓰지 않을 때 어떤 절차로 폐기되는가
OWASP Non-Human Identities Top 10은 비인간 ID의 주요 위험으로 부적절한 오프보딩, 시크릿 유출, 취약한 서드파티 NHI, 불안전한 인증, 과도한 권한, 장기 지속 시크릿, 환경 격리 실패, NHI 재사용, 사람이 NHI를 직접 사용하는 문제 등을 제시한다. AI 에이전트는 이 항목 대부분에 동시에 걸릴 수 있다. 특히 에이전트가 여러 SaaS와 클라우드를 연결할수록 토큰과 권한은 빠르게 늘어나며, 개발·검증 단계에서 만든 권한이 운영 환경까지 남는 경우가 많다.
따라서 기업은 AI 에이전트를 "도구"가 아니라 "행동 가능한 신원"으로 다뤄야 한다. 생성 시점에는 목적, 소유자, 데이터 등급, 승인자, 만료일을 등록해야 한다. 운영 중에는 권한 사용 내역과 행동 로그를 수집해야 한다. 변경 시에는 권한 확대와 도구 추가를 별도 승인 대상으로 분리해야 한다. 폐기 시에는 토큰, 세션, 커넥터, 캐시된 자격증명까지 함께 회수해야 한다.
3. 가장 위험한 조합은 과도한 권한과 약한 감사로그다
AI 에이전트 보안 사고는 대개 하나의 취약점만으로 발생하지 않는다. 광범위한 권한, 장기 토큰, 불충분한 입력 검증, 부실한 로그가 함께 쌓일 때 피해가 커진다. 예를 들어 고객지원 에이전트가 CRM, 결제, 메일 발송, 파일 저장소에 모두 접근할 수 있다고 가정해 보자. 공격자가 티켓 본문이나 첨부파일에 악성 지시를 숨기면 에이전트는 이를 업무 지시로 오인할 수 있다. 이때 권한이 세분화되어 있지 않으면 단순 조회 업무가 데이터 반출이나 계정 변경으로 이어질 수 있다.
또 다른 위험은 사람과 에이전트의 활동이 구분되지 않는 로그다. 사용자의 세션을 그대로 빌려 에이전트가 작업하면 로그에는 사용자 본인이 수행한 것처럼 보인다. 실제로는 사용자가 직접 누른 버튼인지, 에이전트가 대신 실행한 작업인지, 외부 입력에 의해 유도된 행동인지 확인할 수 없다. 금융, 의료, 공공, 제조 운영망처럼 내부통제와 감사가 중요한 산업에서는 "누가 승인했는가"와 "누가 실행했는가"가 분리되어야 한다.
감사로그는 단순히 API 호출 내역을 남기는 수준을 넘어야 한다. 에이전트 ID, 인간 소유자, 입력 출처, 사용한 도구, 접근한 데이터 등급, 실행 결과, 승인 여부, 예외 처리 사유를 연결해 남겨야 한다. 민감 작업은 사전 승인 또는 사후 승인 큐를 거치게 하고, 대량 조회·권한 변경·외부 전송 같은 행동은 별도 탐지 규칙을 적용해야 한다.
4. 실무 대응은 IAM, PAM, 시크릿 관리, AI 거버넌스를 연결해야 한다
AI 에이전트 보안은 특정 솔루션 하나로 끝나지 않는다. IAM은 신원 등록과 권한 부여를 담당하고, PAM은 고위험 권한 사용을 통제하며, 시크릿 관리 시스템은 토큰 발급과 회전을 담당한다. 여기에 AI 거버넌스는 어떤 업무를 에이전트에게 맡길 수 있는지, 어떤 데이터는 금지해야 하는지, 어떤 수준의 인간 검토가 필요한지 기준을 제공해야 한다.
첫 번째 원칙은 에이전트별 고유 ID다. 여러 에이전트가 하나의 서비스 계정을 공유하지 않도록 하고, 최소한 업무 목적별로 ID를 분리해야 한다. 두 번째 원칙은 최소권한과 시간 제한이다. 초기 편의를 위해 광범위한 관리자 권한을 주는 방식은 피하고, 단기 토큰과 Just-in-Time 권한 상승을 우선 적용해야 한다. 세 번째 원칙은 도구 단위 권한 분리다. 이메일 읽기, 고객정보 조회, 결제 취소, 파일 삭제는 같은 수준의 권한이 아니다. 에이전트가 호출할 수 있는 도구와 파라미터를 정책으로 제한해야 한다.
네 번째 원칙은 중지 가능성이다. 에이전트가 오작동하거나 조작된 입력에 반응하는 경우 즉시 권한을 정지하고 세션을 끊을 수 있어야 한다. 이는 단순한 "킬 스위치" 버튼만 의미하지 않는다. 토큰 폐기, 커넥터 비활성화, 메시지 큐 정지, 외부 전송 차단이 함께 동작해야 한다. 다섯 번째 원칙은 주기적 재인증이다. 사람이 부서를 이동하면 권한을 재검토하듯, 에이전트도 업무 범위 변경과 사용 빈도에 따라 권한을 줄이거나 폐기해야 한다.
운영 우선순위
AI 에이전트 보안을 시작할 때 모든 통제를 한 번에 완성하려고 하면 현업 도입 속도와 충돌한다. 우선순위는 위험이 큰 신원부터 줄이는 방식이 현실적이다.
가장 먼저 관리자급 권한을 가진 에이전트와 공유 서비스 계정을 식별해야 한다. 이 계정들은 사고 시 피해 범위가 크기 때문에 소유자, 목적, 접근 시스템, 만료일을 즉시 확인하고 불필요한 권한을 회수해야 한다. 동시에 장기 API 키, OAuth 토큰, 클라우드 역할처럼 회전되지 않는 자격증명을 찾아 단기 토큰과 자동 회전 체계로 옮겨야 한다.
다음 단계는 에이전트별 고유 ID와 로그 표준을 적용하는 것이다. 에이전트가 어떤 입력을 받았고 어떤 도구를 호출했으며 어떤 결과를 만들었는지 추적 가능해야 한다. 고위험 작업에는 승인 큐를 붙이고, 대량 조회·삭제·외부 전송·권한 변경은 탐지 규칙을 별도로 둔다.
장기적으로는 AI 에이전트 생성·변경·폐기 절차를 IAM/PAM 워크플로우와 연결해야 한다. 신규 에이전트를 만들 때 목적과 소유자를 등록하고, 권한 확대는 별도 승인으로 처리하며, 사용 빈도가 낮거나 소유자가 불명확한 에이전트는 자동으로 재검토 대상에 올리는 방식이다. 이 절차가 정착되면 AI 도입 속도를 늦추지 않으면서도 감사와 책임 추적을 유지할 수 있다.
체크리스트
- AI 에이전트 목록, 소유자, 업무 목적, 접근 시스템을 인벤토리로 관리하는가
- 에이전트마다 고유 ID가 있으며 공유 서비스 계정 사용을 제한하는가
- 권한 부여 시 데이터 등급, 업무 범위, 만료일을 함께 기록하는가
- 장기 시크릿 대신 단기 토큰, 자동 회전, 비밀 저장소를 사용하는가
- 에이전트 행동 로그가 사람의 행동 로그와 구분되는가
- 프롬프트, 외부 문서, 티켓, 이메일 등 입력 출처를 로그에 남기는가
- 대량 조회, 외부 전송, 삭제, 권한 변경에 별도 승인 또는 탐지를 적용하는가
- 에이전트 폐기 시 토큰, 커넥터, 세션, 캐시 자격증명까지 회수하는가
- 사고 발생 시 에이전트 권한을 즉시 중지할 수 있는 절차가 있는가
결론
AI 에이전트 도입의 본질은 "사람이 하던 일을 더 빠르게 처리한다"가 아니라 "시스템 안에서 행동하는 새로운 주체가 생긴다"는 데 있다. 이 주체를 식별하지 못하면 권한은 쌓이고, 로그는 흐려지고, 책임은 사라진다. 반대로 에이전트를 정식 신원으로 등록하고 수명주기를 관리하면 생산성과 통제는 함께 갈 수 있다.
기업이 지금 해야 할 일은 거창한 AI 보안 선언이 아니다. 먼저 에이전트가 어디에 있는지 찾고, 누가 책임지는지 지정하고, 어떤 권한을 쓰는지 줄이고, 언제 폐기할지 정하는 것이다. AI 에이전트에 사번을 준다는 것은 결국 조직이 자동화된 행동에도 책임을 부여하겠다는 선언이다. 비인간 ID 보안은 AI 시대의 주변 과제가 아니라 기업 계정관리의 중심 과제가 되고 있다.
참고자료
- OWASP Non-Human Identities Top 10 - 2025: https://owasp.org/www-project-non-human-identities-top-10/2025/introduction/
- Cloud Security Alliance, The Non-Human Identity Governance Vacuum: https://labs.cloudsecurityalliance.org/research/csa-whitepaper-nonhuman-identity-agentic-ai-governance-v1-cs/
- Identity Defined Security Alliance, Non-human identities and AI-era security: https://www.idsalliance.org/blog/non-human-identities-the-unseen-workforce-driving-ai-era-security/
- World Economic Forum, Non-human identities and agentic AI cybersecurity risk: https://www.weforum.org/stories/2025/10/non-human-identities-ai-cybersecurity/
본 콘텐츠는 AI 기술로 생성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하시면 댓글을 통해 소중한 의견 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.