한눈에 보기
Okta가 Okta for AI Agents를 일반 제공한다고 발표했습니다. Okta의 설명에서 핵심은 AI agent를 first-class identity로 보고, 기업의 identity security fabric 안에서 discover, onboard, protect, govern하는 것입니다.
이번 발표가 중요한 이유는 기능 이름보다 질문이 선명하기 때문입니다. Okta는 secure agentic enterprise를 위해 세 가지를 물어야 한다고 말합니다. 우리 환경에 어떤 agent가 있는가. 그 agent는 무엇에 연결할 수 있는가. 문제가 생기면 어떻게 통제하고 회수할 것인가.
결국 AI agent 보안은 모델 성능 경쟁이 아니라 권한, 감사, 소유자, 수명주기 관리의 문제로 들어오고 있습니다.
이번 발표 뭐가 나왔나
Okta for AI Agents는 AI agent를 기업 보안 체계 안의 정식 신원으로 등록하고 관리하려는 제품입니다. Okta는 AI agent가 사용자를 대신해 민감한 시스템에 연결하고 자율적으로 결정을 내릴 수 있기 때문에, 기존 human identity 중심 보안만으로는 빈틈이 생긴다고 봅니다.
공식 블로그에서 Okta는 AI agent에 first-class identity를 부여해 agent framework, cloud, SaaS 환경 전반에서 discover, onboard, protect, govern할 수 있다고 설명합니다. 여기서 중요한 표현은 first-class identity입니다. agent를 임시 스크립트나 앱의 부속 기능이 아니라, 소유자와 권한, 로그, 회수 절차를 가진 관리 대상으로 본다는 뜻입니다.
파트너와 연동 맥락도 함께 언급됐습니다. Okta 블로그는 Salesforce Agentforce, Amazon Bedrock AgentCore, ServiceNow AI Platform 연동을 이야기하고, newsroom 발표는 Google Vertex AI, Boomi, DataRobot 같은 agent platform 지원과 협업 맥락을 소개합니다.
핵심 변화 3가지
1. 섀도우 AI agent를 찾아내는 흐름이 중요해졌다
AI agent 보안의 첫 문제는 "어디에 있는지 모른다"입니다. 직원이 SaaS 앱에 AI 도구를 연결하거나, 팀별로 agent를 만들거나, 외부 agent platform을 쓰기 시작하면 중앙 보안팀이 모든 연결을 즉시 알기 어렵습니다.
Okta는 Universal Directory를 통해 AI agent를 등록하고 검색 가능한 first-class identity로 다루겠다고 설명합니다. known agent는 외부 플랫폼 연동으로 가져오고, unmanaged agent는 OAuth consent grant 같은 신호를 통해 shadow AI agent로 탐지하는 방식입니다.
다만 shadow AI agent discovery는 공식 블로그 기준으로 managed Chrome browser의 OAuth consent grant 식별을 포함하고, 추가 브라우저 지원은 추후 제공 예정이라고 되어 있습니다. 따라서 모든 브라우저와 모든 SaaS 연결을 같은 수준으로 볼 수 있다고 단정하면 안 됩니다.
2. agent access를 표준화하려는 시도다
두 번째 질문은 agent가 무엇에 연결할 수 있는가입니다. agent는 API, app, service account, secret, MCP server 같은 여러 자원에 접근할 수 있습니다. 이 접근이 하드코딩된 credential이나 오래 살아 있는 token에 기대면, agent가 흔들릴 때 피해 범위도 같이 커집니다.
Okta는 scoped, short-lived token, authorization server, vaulted secret, service account governance, managed consent flow, Secure Token Storage, MCP server governance 같은 구성을 제시합니다.
표현은 제품별로 다르지만 핵심은 하나입니다. agent가 필요한 범위만, 필요한 시간 동안, 추적 가능한 방식으로 접근하게 하겠다는 것입니다. 개발자 입장에서는 agent 배포 시 "이 agent가 어떤 tool을 호출할 수 있는가"와 "그 권한은 어디서 발급되고 어떻게 만료되는가"가 더 중요해집니다.
3. 통제와 회수, 감사 로그가 제품 중심으로 들어왔다
세 번째 질문은 agent가 무엇을 할 수 있고, 문제가 생겼을 때 어떻게 멈출 수 있는가입니다. Okta는 automated access review, structured approval workflow, rogue agent deactivation, kill switch, audit logs, telemetry를 핵심 기능으로 제시합니다.
newsroom 발표에서는 Universal Logout for AI Agents를 통해 agent가 의도한 임무에서 벗어나거나 민감한 데이터에 예상 밖으로 접근할 때 access token을 즉시 revoke할 수 있다고 설명합니다. 또한 tool call, authorization decision, access attempt 같은 agent activity를 system log로 남기고 SIEM으로 보낼 수 있다는 내용도 포함됐습니다.
이 부분은 현실적입니다. AI agent 사고는 나쁜 답변으로만 끝나지 않을 수 있습니다. 이미 부여된 권한으로 여러 SaaS와 내부 시스템을 건드릴 수 있기 때문에, 로그와 revoke가 없으면 사고 대응이 늦어집니다.
실제로 뭐가 달라지나
일반 사용자가 Okta for AI Agents 콘솔을 직접 볼 일은 많지 않을 수 있습니다. 대신 회사에서 승인되지 않은 AI agent 연결이 줄고, 승인된 agent만 업무 앱에 접근하는 흐름이 강화될 가능성이 있습니다.
개발자에게는 agent 배포 체크리스트가 달라집니다. 이제는 agent가 잘 동작하는가뿐 아니라 agent identity가 등록되어 있는가, human owner가 있는가, scope가 과하지 않은가, tool call과 authorization decision이 로그로 남는가를 봐야 합니다.
B2B SaaS나 agent platform을 만드는 팀에게는 Okta 같은 identity provider와의 연동이 점점 중요해질 수 있습니다. 기업 고객은 agent 기능을 좋아하더라도 누가 접근했고 어떤 권한을 가졌고 어떻게 회수되는지 설명할 수 없으면 도입을 미룰 가능성이 높습니다.
좋은 점
가장 좋은 점은 질문이 구체적이라는 것입니다. "AI agent를 안전하게 쓰자"는 말은 넓지만, Okta가 제시한 세 질문은 운영자가 바로 체크리스트로 바꿀 수 있습니다. 어떤 agent가 있는가, 무엇에 접근하는가, 어떻게 통제하고 회수하는가. 이 세 가지가 정리되면 보안 대화가 훨씬 실무적으로 바뀝니다.
또 하나는 shadow AI agent를 전면에 놓았다는 점입니다. 기업의 진짜 위험은 공식 도입된 agent보다 누가 연결했는지 모르는 agent에서 시작될 수 있습니다. 이를 discovery, registration, owner assignment, baseline policy로 묶겠다는 방향은 현실적인 접근입니다.
감사 로그와 revoke가 핵심 기능으로 들어간 점도 긍정적입니다. AI agent는 자율성이 강할수록 나중에 추적 가능한가와 바로 끊을 수 있는가가 중요해집니다. 화려한 데모보다 이런 기본기가 기업 도입에서는 더 오래 갑니다.
아쉬운 점
아직 확인 필요인 부분도 있습니다. Okta는 agent framework, cloud, SaaS 환경 전반을 이야기하지만, 실제 고객 환경에서 모든 agent framework, cloud, SaaS가 같은 수준으로 지원되는지는 별도 확인이 필요합니다.
라이선스, 지원 지역, 관리자 설정, 감사 로그의 세부 범위도 확인해야 합니다. 어떤 로그가 기본 제공이고 어떤 로그가 별도 설정이나 SIEM 연동을 요구하는지, 특정 기능이 어떤 플랜에 포함되는지는 실제 도입 전 봐야 합니다.
또 vendor-neutral, full lifecycle 같은 설명은 방향성으로는 의미가 있지만, 실제 환경에서는 기존 IdP, SaaS 설정, 브라우저 관리, agent platform별 API 지원 수준에 따라 체감이 달라질 수 있습니다.
내 생각
이번 발표에서 가장 크게 보이는 변화는 AI agent가 이제 기능이 아니라 신원으로 다뤄지기 시작했다는 점입니다. 사람에게 계정이 있고, 앱에 OAuth client가 있고, service account에 소유자와 권한이 있듯이 agent에도 그런 관리 단위가 필요해졌습니다.
AI agent는 편리하지만 기존 자동화보다 더 예측하기 어렵습니다. 여러 시스템을 오가고, 도구를 호출하고, 사용자를 대신해 결정을 내릴 수 있습니다. 이때 agent가 어떤 권한을 갖고 있는지 모르면 사고가 났을 때 원인을 찾기도 어렵고 멈추기도 어렵습니다.
그래서 Okta for AI Agents GA는 "Okta가 AI 제품을 냈다"보다 "identity 시장이 agent 시대에 맞춰 범위를 넓히고 있다"로 보는 쪽이 더 맞습니다. 앞으로 기업용 AI agent 도입 논의는 모델 성능보다 권한, 감사, 소유자, revoke 같은 단어를 더 자주 포함하게 될 가능성이 큽니다.
결론
Okta for AI Agents GA의 핵심은 AI agent를 first-class identity로 다루는 것입니다. agent를 discover하고, Universal Directory 같은 신원 체계에 onboard하고, access를 표준화하고, 문제가 생기면 revoke와 audit trail로 통제하는 방향입니다.
이번 발표가 모든 환경에서 곧바로 같은 수준으로 작동한다고 단정할 수는 없습니다. 실제 도입에서는 지원되는 agent platform, browser, SaaS, cloud, region, license, admin policy, audit log 범위를 확인해야 합니다.
그래도 큰 방향은 분명합니다. AI agent가 많아질수록 기업은 좋은 agent를 만드는 법만큼이나 그 agent를 누가 소유하고, 무엇에 접근하고, 어떻게 끊을 수 있는가를 관리해야 합니다.
한 줄 평
Okta for AI Agents는 AI agent 시대의 핵심 보안 질문을 성능이 아니라 신원, 권한, 회수로 바꿔 놓는 발표입니다.