AI 에이전트에게도 신분증이 필요하다 — 기계가 일하는 시대, 보안은 준비됐나
회사에서 슬랙 메시지를 보내고, 고객 데이터를 조회하고, 결재를 올리는 주체가 더 이상 사람만이 아닙니다. AI 에이전트가 사람의 계정을 빌려 시스템 곳곳을 돌아다니는 지금, 한 가지 근본적인 질문이 부상하고 있습니다. 이 에이전트는 누구인가, 그리고 어디까지 접근해도 되는가. Okta CEO가 최근 공개 인터뷰에서 “에이전트 아이덴티티"에 회사의 미래를 걸겠다고 선언하면서 이 주제가 본격적으로 수면 위로 올라왔습니다.
사람에겐 사번이 있는데, AI 에이전트에겐 뭐가 있나
기업 보안의 기본 원칙은 단순합니다. 누가 접근하는지 확인하고, 권한이 있는 만큼만 허용하는 것. 사람에게는 사번, 이메일, MFA 같은 인증 체계가 잘 갖춰져 있습니다. 그런데 AI 에이전트는 어떨까요.
현재 대부분의 AI 에이전트는 사람의 API 키나 서비스 계정을 빌려서 작동합니다. 문제는 이 에이전트가 어떤 작업을 했는지 감사 로그에 남길 때, 실제로는 사람의 이름으로 기록된다는 점입니다. 에이전트가 10개의 시스템에 걸쳐 데이터를 조회했는데, 로그상으로는 마치 김과장이 직접 한 것처럼 보이는 겁니다. 사고가 터지면 책임 소재가 불분명해지고, 과잉 권한 문제도 드러나지 않습니다.
Okta가 꺼내든 카드, Identity Security Fabric
Okta의 CEO 토드 매키넌은 이 문제에 대해 꽤 명확한 입장을 내놓았습니다. AI 에이전트도 사람처럼 고유한 신원을 가져야 한다는 것입니다. Okta가 2025년 하반기부터 밀고 있는 개념이 바로 Identity Security Fabric인데요. 핵심은 이렇습니다.
첫째, 에이전트에게 독립적인 아이덴티티를 부여합니다. 사람의 계정을 빌리는 게 아니라, 에이전트 자체가 하나의 인증 주체가 됩니다. 둘째, 에이전트의 생애주기를 관리합니다. 생성, 권한 부여, 권한 회수, 폐기까지 사람 계정과 동일한 수준으로 다루겠다는 겁니다. 셋째, 앱 간 접근 권한을 세밀하게 제어합니다. Okta가 Cross App Access라고 부르는 이 기능은, 에이전트가 A 앱에서 B 앱으로 넘어갈 때마다 권한을 다시 검증하는 방식입니다.
제로 트러스트, 이제 기계에게도 적용되는 시대
제로 트러스트(Zero Trust)라는 개념은 이미 업계 표준이 됐습니다. 네트워크 안에 있다고 무조건 신뢰하지 말고, 매 요청마다 검증하라는 원칙이죠. 그런데 이걸 AI 에이전트에게 적용하려면 이야기가 복잡해집니다.
2025년 12월 AWS re:Invent에서 Okta와 Auth0 팀이 발표한 세션 제목이 인상적입니다. 제로 트러스트 AI 에이전트 구축하기. 이 세션에서는 에이전트가 AWS 서비스에 접근할 때마다 토큰 기반 인증을 거치고, 작업 범위를 최소 권한으로 제한하는 아키텍처를 소개했습니다. 에이전트가 “나 이 데이터 좀 볼게"라고 할 때마다 “너 누구야, 왜 필요해, 어디까지 볼 수 있어"를 매번 확인하는 구조입니다.
이건 단순히 Okta 하나의 전략이 아닙니다. MCP(Model Context Protocol) 같은 새로운 프로토콜과 결합되면서, 에이전트가 여러 앱을 넘나들 때의 보안 표준이 만들어지고 있는 과정입니다.
왜 지금인가 — 에이전트가 폭발적으로 늘고 있으니까
이 이슈가 갑자기 뜨거워진 배경은 단순합니다. AI 에이전트 도입 속도가 예상보다 빠릅니다. 고객 응대, 내부 업무 자동화, 코드 리뷰, 데이터 파이프라인 관리까지 — 기업 안에서 사람 대신 움직이는 에이전트가 기하급수적으로 늘고 있습니다.
Okta의 CTO는 “에이전트 수가 곧 사람 직원 수를 넘어설 것"이라고 전망했습니다. 에이전트 하나가 문제를 일으키면 피해는 사람 한 명이 실수한 것과는 차원이 다릅니다. 에이전트는 24시간 쉬지 않고, 수십 개 시스템을 동시에 건드릴 수 있으니까요. 보안 사고의 폭발 반경이 완전히 달라지는 겁니다.
아직 풀리지 않은 숙제들
물론 장밋빛 비전만 있는 건 아닙니다. 현실적으로 몇 가지 어려운 문제가 남아 있습니다.
표준의 부재가 가장 큽니다. 에이전트 아이덴티티를 어떤 형식으로 발급하고, 어떤 프로토콜로 검증할지에 대한 업계 합의가 아직 없습니다. Okta가 Verifiable Credentials(검증 가능한 자격증명) 방식을 밀고 있지만, 이게 표준이 될지는 미지수입니다.
책임 소재 문제도 여전합니다. 에이전트가 잘못된 판단으로 민감 데이터를 유출했을 때, 그 책임은 에이전트를 만든 개발사에 있는 건지, 배포한 기업에 있는 건지, 권한을 승인한 관리자에 있는 건지. 기술만으로 풀 수 없는 거버넌스 영역의 논의가 필요합니다.
그리고 현실적 복잡성의 문제가 있습니다. 대기업에서 수백, 수천 개의 에이전트가 돌아갈 때 각각의 라이프사이클을 사람 계정처럼 관리하는 건 운영 부담이 만만치 않습니다. 자동화된 거버넌스 도구 없이는 사실상 불가능에 가깝습니다.
AI 에이전트가 우리 대신 일을 해주는 미래는 이미 오고 있습니다. 그런데 그 에이전트가 회사 시스템을 자유롭게 돌아다니는데, 신분증도 없고 출입 기록도 제대로 안 남는다면 — 이건 편리함이 아니라 시한폭탄입니다. “AI를 잘 쓰려면 아이덴티티를 먼저 잡아야 한다"는 Okta의 메시지가 단순한 마케팅 슬로건으로만 들리지 않는 이유입니다. 여러분의 회사에서 돌아가는 AI 에이전트는 지금 누구의 권한으로, 무엇에 접근하고 있나요?