Okta Showcase 2026 발표
Okta for AI Agents, 보안이 없으면 에이전트도 없습니다
AI 에이전트가 회사 시스템 안에서 자율적으로 움직이고 있습니다. 문제는 그 에이전트 중 얼마나 많은 수를 IT팀이 파악조차 못 하고 있느냐입니다.
Okta가 2026년 3월 16일 발표하고 4월 30일 정식 출시하는 Okta for AI Agents는,
AI 에이전트를 사람처럼 ID를 가진 주체로 등록하고 통제하는 첫 번째 전용 보안 플랫폼입니다.
AI 에이전트 보안, 왜 지금 이슈인가
결론부터 말씀드리면, 이미 많은 기업의 내부 시스템 안에서 통제되지 않은 AI 에이전트가 살아 움직이고 있습니다.
Gravitee가 2026년 2월 3일 발표한 State of AI Agent Security 2026 보고서에 따르면,
조사 대상 기업의 88%가 AI 에이전트 관련 보안 사고를 겪었거나 의심 상황에 처한 것으로 나타났습니다.
(출처: Gravitee, State of AI Agent Security 2026, 2026.02.03)
더 충격적인 수치는 그 다음입니다. 같은 보고서에서 에이전트를 독립적인 ID 주체로 취급하는 기업은 고작 22%에 불과했습니다.
나머지 78%는 에이전트가 어떤 시스템에 접근하는지, 어떤 권한을 갖는지 파악조차 못하고 있다는 뜻입니다.
보안 사고는 88%가 겪는데, 관리는 22%만 하고 있는 셈입니다.
최근 등장한 ‘OpenClaw’ 같은 수퍼에이전트는 사용자 PC에서 직접 터미널 명령을 실행하고,
파일 시스템에 접근하며, 애플리케이션 간 데이터를 자율 전송합니다.
에이전트 스스로가 또 다른 임시 에이전트를 생성해 작업을 분산하기도 합니다.
Okta 공식 발표문은 이를 두고 “전통적인 ID 보안 관행에 정면으로 도전하는 구조”라고 표현했습니다.
(출처: Okta Newsroom, Showcase 2026 보도자료, 2026.03.16)
Okta for AI Agents가 답하는 3가지 질문
Okta가 이 플랫폼의 설계 원칙으로 삼은 것은 딱 세 가지 질문입니다.
“내 에이전트가 어디 있나? 무엇에 연결되나? 무엇을 할 수 있나?”
CEO Todd McKinnon은 2026년 3월 16일 Showcase 발표 현장에서 “이 세 질문에 동시에 답하는 벤더가 없었다”고 밝혔습니다.
(출처: The Register, 2026.03.18)
💡 공식 발표문과 실제 에이전트 배포 흐름을 나란히 놓고 보니, Okta가 이 세 질문을 구조화한 방식이 기존 IAM 프레임워크와 근본적으로 다르다는 것이 보였습니다.
기존 ID 관리는 “누가 로그인하는가”에서 시작합니다. 그런데 에이전트는 로그인하지 않습니다.
API 키를 갖고 백그라운드에서 조용히 실행됩니다. 그래서 기존 도구로는 아예 감지가 안 됩니다.
이 플랫폼은 거버넌스의 출발점을 “로그인”에서 “등록”으로 바꿉니다.
첫 번째 질문 — 어디 있나?
Okta의 Shadow AI Agent Discovery 기능은 직원이 AI 에이전트를 엔터프라이즈 앱에 연결하는 순간 자동으로 탐지합니다.
IT팀이 승인하지 않은 ‘섀도 에이전트’도 실시간으로 잡아냅니다.
탐지된 에이전트는 Universal Directory에 비인간 ID(NHI, Non-Human Identity)로 등록되고, 담당 인간 오너가 배정됩니다.
두 번째 질문 — 무엇에 연결되나?
Agent Gateway가 중앙 컨트롤 플레인 역할을 합니다.
에이전트가 어떤 MCP 서버, 툴, API, 데이터베이스에 접근하는지 모든 경로를 이곳에서 로깅합니다.
자격 증명(크리덴셜)은 Privileged Credential Management를 통해 암호화 저장되고 자동 교체됩니다.
평문이나 로그에 노출되지 않도록 설계됐습니다.
세 번째 질문 — 무엇을 할 수 있나?
API Access Management가 최소 권한 원칙을 동적으로 적용합니다.
에이전트의 ID, 컨텍스트, 위험도를 실시간으로 평가해 각 툴 호출 단위까지 승인 여부를 결정합니다.
여기에 더해 Universal Logout 기능이 문제 발생 시 에이전트 접근 토큰 전체를 즉시 폐기합니다.
핵심 기능 해부 — 킬 스위치까지
이 플랫폼에서 가장 주목할 기능은 단연 Universal Logout for AI Agents입니다.
에이전트가 허가된 범위를 벗어나거나 민감 데이터에 예기치 않게 접근할 경우,
Okta는 해당 에이전트의 모든 액세스 토큰을 즉시 폐기하고 기업 생태계 전체에서 접근을 차단합니다.
| 기능 | 역할 | 현재 상태 |
|---|---|---|
| Shadow AI Agent Discovery | 미승인 에이전트 자동 탐지 | Early Access |
| AI Agent Registration | Universal Directory에 NHI로 등록 | Early Access |
| API Access Management | 최소 권한 동적 평가 | Early Access |
| Privileged Credential Management | 자격 증명 암호화 저장 및 자동 교체 | Early Access |
| Governance for Agents | 인증 워크플로우에 에이전트 포함 | Early Access |
| Universal Logout for AI Agents | 이탈 에이전트 즉시 전체 접근 차단 | 4월 30일 GA |
| Agent Gateway | MCP 서버 집계 및 전체 접근 로깅 | Coming Soon |
Boomi, DataRobot, Google Vertex AI, Salesforce, ServiceNow, AWS 등이 Okta Integration Network(OIN)에 전용 Agent Integration으로 추가됩니다.
팀은 클릭 한 번으로 에이전트를 임포트하고 거버넌스가 적용된 ID로 등록할 수 있습니다.
(출처: Okta Newsroom, Showcase 2026 보도자료, 2026.03.16)
System Logs 기능은 에이전트의 모든 툴 호출, 권한 결정, 접근 시도를 기록하고 기업 SIEM으로 전송합니다.
어떤 에이전트가 어떤 명령을 언제 실행했는지 감사 추적이 가능해집니다.
기존 도구로 에이전트를 못 막는 구조적 이유
솔직히 말하면, 기존의 모든 IAM(ID 및 접근 관리) 도구는 에이전트를 위해 만들어진 게 아닙니다.
Okta의 공식 블로그(2026.03.16)에서 이 문제를 아주 직접적으로 밝히고 있습니다.
💡 공식 블로그와 보안 전문가 인터뷰를 교차해서 보면, 기존 도구가 에이전트에 무력한 이유가 기술 문제가 아니라 설계 철학의 문제임을 알 수 있습니다.
에이전트는 이메일을 읽지 않습니다. HR 이벤트도 없습니다. 로그인 패턴도, 지역 정보도 없습니다.
기존 거버넌스 워크플로우는 이 전제 아래 설계됐기 때문에, 에이전트에게는 처음부터 작동하지 않습니다.
① 탐지 불가: 기존 SaaS 탐지 도구는 승인되지 않은 앱과 비정상 네트워크 트래픽을 감지합니다.
그런데 에이전트는 개발 환경에서 스크립트로 실행되고 유효한 API 키를 갖고 있습니다.
정상 트래픽과 구별이 안 됩니다.
② 제로 트러스트 우회: 제로 트러스트 아키텍처는 동적 자격 증명과 지속적 검증을 전제합니다.
하지만 대부분의 에이전트는 최신 보안 제어가 도입되기 훨씬 전부터 사용되던 장기 정적 API 키로 인증합니다.
최신 보안 체계를 우회하는 구멍이 이미 뚫려 있는 셈입니다.
(출처: Okta Blog, “Every AI Agent Needs an Identity”, 2026.03.16)
③ 거버넌스 맹점: 접근 검토는 이메일 응답을 기다립니다. 수명 주기 관리는 HR 시스템의 입사·퇴사 이벤트를 트리거로 씁니다.
위험 점수는 로그인 패턴과 지리 정보를 분석합니다.
에이전트는 이 중 어느 것도 충족하지 않습니다.
더 현실적인 문제도 있습니다. 개발자가 퇴사하면, 그 개발자가 만든 에이전트는 계속 실행될 수 있습니다.
에이전트의 목적이 바뀌어도 권한은 그대로입니다. 에이전트가 이상한 접근을 시작해도 차단할 방법이 없습니다.
Dell Technologies CTO John Roese는 Showcase 현장에서 “에이전트를 블랙박스 뒤에 숨겨두는 벤더들은 우리 생태계에서 더 이상 에이전트로 취급하지 않겠다”고 공언했습니다.
(출처: The Register, 2026.03.18)
Okta만으로 충분한가 — 한계와 고려사항
이 부분이 기존 블로그에서 잘 안 다루는 내용입니다.
Okta for AI Agents 자체는 인상적이지만, 도입 전에 반드시 확인해야 할 구조적 한계가 있습니다.
Okta Identity Governance 전체 플랫폼이 그렇듯, Okta for AI Agents 역시 Okta Workforce Identity를 기반 인증 레이어로 쓰고 있는 조직에 최적화되어 있습니다.
Microsoft Entra ID, Google Workspace, Ping Identity 등 다른 IdP를 쓰는 곳에서는 통합 깊이가 달라집니다.
(출처: ConductorOne, Okta IGA Alternatives 가이드, 2025.11.24)
Agent Gateway가 아직 미출시입니다. 4월 30일 GA에서 핵심 기능으로 소개되는 Agent Gateway는 현재 “Coming Soon” 상태입니다.
MCP 레지스트리 집계, 에이전트-리소스 간 전체 접근 로깅 등 제어 플레인의 핵심이 실제 사용 가능한 시점은 공식적으로 아직 확정되지 않았습니다.
(출처: Okta Blog, “Every AI Agent Needs an Identity”, 2026.03.16)
가격 구조가 복잡합니다. Okta IGA는 대기업 규모에서 합리적이지만, 중소·중견 기업에는 per-user 모델과 기능별 add-on 구조가 도입 비용을 빠르게 높입니다.
에이전트 ID가 수백 개 단위로 늘어날 경우 비용 계산을 사전에 충분히 해봐야 합니다.
“에이전트 정의”에 업계 합의가 없습니다. Dell CTO John Roese가 Showcase 현장에서 직접 말했습니다.
“솔직히 말하면, 업계가 에이전트가 무엇인지 아직 완전히 합의하지 못했습니다.”
API 뒤에 숨어있는 에이전트, 특정 제공사 방화벽 안에 갇힌 에이전트는 아직 Okta의 프레임워크로 완전히 잡아내기 어렵습니다.
(출처: The Register, 2026.03.18)
그럼에도 불구하고 현재 시장에서 AI 에이전트 보안에 특화된 전용 플랫폼은 Okta for AI Agents가 사실상 처음입니다.
Microsoft Entra ID나 ConductorOne 같은 경쟁사들은 IGA 영역에서 대안이 되지만,
에이전트 ID 라이프사이클 전체를 통합 관리하는 단일 플랫폼은 아직 이 제품이 유일합니다.
실제 도입 시 따져봐야 할 체크리스트
Okta의 공식 블로그에서 권장하는 자가 점검 항목이 있습니다.
현재 우리 조직에 아래 질문에 답할 수 없다면, 에이전트 보안 사각지대가 이미 존재하는 상태입니다.
💡 이 체크리스트를 Okta가 공개한 도입 전제 조건과 함께 놓고 보면, “AI 에이전트 도입 성숙도”를 스스로 측정하는 기준으로 쓸 수 있습니다.
| 점검 항목 | 파악 여부 |
|---|---|
| 현재 조직 내 운영 중인 AI 에이전트 목록을 갖고 있다 | ☐ |
| 각 에이전트의 담당 오너(인간)가 지정되어 있다 | ☐ |
| 에이전트가 어느 시스템에 접근 권한을 갖고 있는지 알고 있다 | ☐ |
| 에이전트 자격 증명(API 키 등)을 평문이 아닌 방식으로 저장하고 있다 | ☐ |
| 에이전트가 이탈 행동을 보일 때 즉시 접근을 차단할 수 있다 | ☐ |
| 현재 기반 IdP가 Okta Workforce Identity인지 확인했다 | ☐ |
위 항목 중 절반 이상을 확인할 수 없다면, 현재 에이전트가 어디서 무엇을 하는지 파악이 안 된다는 뜻입니다.
Okta for AI Agents의 Early Access는 현재 신청 가능하며,
4월 30일 GA 전에 Shadow AI Agent Discovery와 AI Agent Registration 기능을 미리 테스트해볼 수 있습니다.
(출처: Okta 공식 페이지)
자주 묻는 질문
마치며 — 에이전트 시대, 보안은 선택이 아닙니다
Okta for AI Agents를 검토하면서 가장 인상 깊었던 건 기능 목록이 아니라 이 문장이었습니다.
“보안 팀은 경보만 원하는 게 아니라, 동시에 여러 시스템에서 즉각 조치할 수 있는 능력이 필요합니다.”
솔직히 말하면 AI 에이전트는 이미 기업 내부에 있습니다. 허가를 받고 들어온 것도 있고, 아무도 모르게 돌아다니는 것도 있습니다.
기업의 88%가 이미 보안 사고를 경험했다는 수치가 그걸 증명합니다.
문제는 “도입할까 말까”가 아니라 “이미 있는 에이전트를 어떻게 통제하느냐”입니다.
Okta for AI Agents는 4월 30일 GA를 앞두고 있지만, 벤더 종속성 문제와 Agent Gateway 미완성이라는 현실적 제약이 있습니다.
Okta를 이미 쓰고 있다면 Early Access부터 시작해보는 게 자연스러운 수순입니다.
다른 IdP 기반 조직이라면 도입 전 아키텍처 검토가 필수입니다.
에이전트 보안의 핵심은 결국 이 하나입니다. 눈에 안 보이는 것은 통제할 수 없습니다.
보이게 만드는 것, 그게 이 플랫폼이 하려는 일입니다.
- Okta 공식 보도자료, “New Blueprint for the Secure Agentic Enterprise” — okta.com/newsroom/press-releases/showcase-2026 (2026.03.16)
- Okta 공식 블로그, “Every AI Agent Needs an Identity” — okta.com/blog/ai/okta-ai-agents-early-access-announcement (2026.03.16)
- Gravitee, State of AI Agent Security 2026 — gravitee.io/state-of-ai-agent-security (2026.02.03)
- The Register, “Okta made a nightmare micromanager for your AI agents” — theregister.com (2026.03.18)
- MSSP Alert, “Okta Wants AI Agents Treated Like Identities” — msspalert.com (2026.03.24)
⚠️ 본 포스팅은 2026년 4월 1일 기준 공개된 공식 자료를 바탕으로 작성되었습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. Okta for AI Agents는 2026년 4월 30일 GA 예정이며, 현재 Early Access 단계의 기능은 GA 전 변경될 수 있습니다. 공식 문서에서 최신 정보를 확인하시기 바랍니다.
댓글 남기기