Okta AI Agent Security, 엔터프라이즈의 혼란에 정면 대응

Okta는 AI 에이전트 보안 강화의 이례적인 경쟁 상대로 다른 보안 업체가 아닌 고객의 혼란을 지목했다. Eric Kelleher 사장 겸 COO는 2026년 9월 9일 Goldman Sachs Communacopia + Technology Conference에서 이같이 밝혔다.

이 주장은 엔터프라이즈가 자율형 소프트웨어를 원하면서도 무엇을 보호해야 하는지 정의하는 데 어려움을 겪는 시장 현실을 반영한다. 에이전트는 이메일을 요약하고, 영업 기록을 업데이트하며, 환불을 승인하거나, 전체 금융 워크플로를 운영할 수 있다. 각 역할은 서로 다른 권한, 위험, 책임 요건을 만든다.

Okta는 ID가 이러한 혼란을 정리하는 계층이 되기를 바란다. 이 회사의 프레임워크는 세 가지를 묻는다. 에이전트는 어디에 있는가, 무엇에 연결할 수 있는가, 무엇을 할 수 있는가? Microsoft도 Entra Agent ID와 Agent 365를 통해 유사한 목표를 추구하고 있어, 엔터프라이즈 배포 역량은 보안 설계만큼 중요해지고 있다.

이 경쟁은 Okta 메시지의 의미를 바꾼다. 혼란은 독립적인 ID 제공업체에 시장 기회를 열 수 있지만, 구매를 지연시키고 번들형 플랫폼에 유리하게 작용할 수도 있다. Okta는 긴급한 보안 서사를 반복 가능한 배포, 측정 가능한 도입, 고객이 여러 공급업체에 걸쳐 활용할 수 있는 표준으로 전환해야 한다.

Okta AI Agent Security는 세 가지 질문에서 시작된다

Okta의 당면한 전략은 방대한 보안 문제를 에이전트 발견, 연결 제어, 권한 부여로 축소하는 것이다.

9월 컨퍼런스에서 Kelleher는 자율형 에이전트에 관한 우려스러운 보도를 접한 뒤 Okta에 도움을 요청하는 고객들을 설명했다. 이들 구매자는 에이전트가 위험을 초래한다는 점은 이해하지만, 해당 위험을 평가할 공통된 모델이 없는 경우가 많다.

Okta의 해답은 Blueprint for the Secure Agentic Enterprise다. 회사는 3월에 이 프레임워크를 공개했고, 2026년 4월 30일 Okta for AI Agents를 정식 출시했다. 이 제품은 익숙한 ID 제어 기능을 자율형 및 반자율형 소프트웨어로 확장한다.

첫 번째 질문인 “내 에이전트는 어디에 있는가?”는 인벤토리와 소유권에 관한 것이다. 직원은 공식 배포 절차 없이 도구를 활성화할 수 있고, 개발자는 수많은 클라우드 플랫폼에 걸쳐 에이전트를 만들 수 있다. 보안팀은 식별할 수 없는 에이전트를 관리할 수 없다.

Okta의 Agent Discovery 기능은 이러한 숨겨진 배포를 드러내도록 설계됐다. 회사의 agent discovery details에 따르면, 이 기능은 OAuth 동의 활동을 탐지하고 승인되지 않은 에이전트 플랫폼과 관련된 연결을 식별한다.

OAuth 동의는 사용자 비밀번호를 받지 않고도 애플리케이션이 다른 서비스에 접근할 수 있도록 권한을 부여한다. 하지만 직원이 알려지지 않은 에이전트에 이메일, 파일, 캘린더 또는 고객 기록을 읽을 권한을 허용하면 이러한 편의성은 위험이 된다.

Okta는 브라우저 신호를 통해 클라이언트 애플리케이션, 연결된 리소스, 요청된 권한 범위를 파악할 수 있다고 말한다. 이후 관리자는 에이전트를 등록하고, 사람 소유자를 지정하며, 기본 정책을 적용할 수 있다.

두 번째 질문인 “에이전트는 무엇에 연결할 수 있는가?”는 인벤토리에서 접근 경로로 관심을 옮긴다. 에이전트는 애플리케이션, API, 데이터베이스, 도구 또는 Model Context Protocol 서버와 상호작용할 수 있다. MCP는 AI 시스템이 외부 도구와 정보에 접근할 수 있게 하는 표준 인터페이스다.

Okta의 청사진에는 이러한 연결을 중개하는 게이트웨이, 자격 증명 볼팅, API 접근 관리가 포함된다. 이 제어 기능들은 광범위하고 지속적인 자격 증명을 ID, 컨텍스트, 위험에 기반한 더 제한적인 결정으로 대체하기 위한 것이다.

세 번째 질문인 “에이전트는 무엇을 할 수 있는가?”는 가장 어려운 계층에 도달한다. 에이전트가 시스템에 들어갈 수 있다는 사실만으로는 정보를 읽고, 쓰고, 전송하고, 승인하거나, 삭제할 수 있는지를 알 수 없다.

Okta는 개별 도구 호출과 권한 부여 결정을 기록할 것을 제안한다. 또한 연결된 시스템 전반에서 에이전트의 접근 토큰을 취소하는 킬 스위치로 Universal Logout을 홍보한다.

이러한 구분은 에이전트가 단순히 또 하나의 직원 계정이 아니기 때문에 중요하다. 에이전트는 많은 작업을 빠르게 실행하고, 여러 시스템의 정보를 결합하며, 주변 컨텍스트가 변할 때 행동을 바꿀 수 있다.

이는 일반적으로 예측 가능한 자동화 작업을 수행하는 기존 서비스 계정과도 다르다. AI 에이전트는 도구를 선택하고, 중간 계획을 생성하며, 사용자에게 위임받은 권한을 통해 행동할 수 있다.

따라서 Okta의 세 가지 질문은 유용한 구매 구조를 만든다. 모든 기반 제어 기능이 모든 에이전트 플랫폼에서 작동한다는 것을 증명하지는 않는다. 대신 보안 리더에게 무엇을 테스트해야 하는지 결정하기 위한 공통 어휘를 제공한다.

이 어휘는 회사 전략의 토대다. Okta는 엔터프라이즈가 에이전트 보안을 고립된 AI 모니터링 범주가 아니라 ID 거버넌스의 확장으로 보기를 원한다.

혼란은 수요와 지연을 동시에 만들고 있다

고객을 Okta로 이끄는 바로 그 불확실성이 평가 기간을 늘리고 에이전트 보안이 예측 가능한 비즈니스가 되는 것을 막을 수도 있다.

Kelleher는 에이전트형 ID 시장에서 현재 회사의 가장 큰 경쟁자는 혼란이라고 말했다. 구매자는 보안 업체, 클라우드 제공업체, AI 개발사, 거버넌스 플랫폼의 상충하는 주장을 마주한다. 많은 제품이 비슷한 언어를 사용하지만 서로 다른 계층을 보호한다.

한 공급업체는 악성 지시를 찾기 위해 프롬프트를 검사할 수 있다. 다른 공급업체는 머신 ID나 노출된 자격 증명을 발견할 수 있다. 세 번째 업체는 네트워크 트래픽을 제어하는 한편, ID 제공업체는 어떤 에이전트가 특정 애플리케이션에 접근할 수 있는지를 결정한다.

이러한 기능은 서로 보완될 수 있지만, 엔터프라이즈는 여전히 소유권을 정립해야 한다. 보안팀은 접근 정책을 제어할 수 있는 반면, 개발자는 에이전트를 소유하고 사업 부서는 허용 가능한 작업을 정의한다.

조직이 배포에 관한 기본적인 질문에 답할 수 없으면 조달은 더 어려워진다. 기업은 직원들이 AI 어시스턴트를 사용한다는 사실은 알지만, 어떤 어시스턴트가 지속적인 애플리케이션 권한을 보유하는지는 모를 수 있다.

에이전트의 정의도 여전히 일관되지 않다. 어떤 시스템은 작업을 추천하는 채팅 인터페이스다. 다른 시스템은 사람의 승인 후 워크플로를 실행하며, 자율형 에이전트는 모든 단계를 검토받지 않고 행동할 수 있다.

이러한 모호성은 라이선싱과 제품 측정에 영향을 준다. Kelleher는 Okta가 현재 에이전트형 제품을 사용자당 가격에 추가 요금으로 책정한다고 말했다. 그는 이 모델이 에이전트 아키텍처에 완벽하지 않다는 점을 인정했지만, 고객이 구매하기 쉽다고 설명했다.

그의 컨퍼런스 발언에 따르면, 초기 거래 대부분은 1년 계약이다. Okta는 갱신 전에 양측이 에이전트 사용량과 운영 비용에 관한 더 나은 정보를 확보할 것으로 예상한다.

이 접근 방식은 즉각적인 구매 마찰을 낮춘다. 동시에 시장이 얼마나 초기 단계인지를 보여준다. 성숙한 보안 범주에는 일반적으로 사용자, 기기, 워크로드, 거래 또는 보호되는 데이터 규모처럼 더 명확한 단위가 있다.

에이전트 활동은 이 모든 단위에 걸칠 수 있다. 한 직원은 여러 에이전트를 사용할 수 있고, 하나의 에이전트는 임시 작업자를 생성하거나 수천 번의 도구 호출을 수행할 수 있다. 사용자당 모델은 보호 대상 워크로드와 분리될 수 있다.

Okta의 장점은 엔터프라이즈 ID팀과의 기존 관계다. Kelleher는 2만 곳 이상의 기업이 이미 사람 및 비인간 ID를 Okta에 맡기고 있다고 말했다. 이 설치 기반은 보안 논의로 직접 진입할 경로를 제공한다.

그러나 신뢰가 구현 작업을 없애지는 않는다. 고객은 에이전트를 발견하고, 목적을 분류하며, 소유자를 식별하고, 과도한 권한을 줄이며, 관련 애플리케이션을 시행 지점에 연결해야 한다.

보안 리더는 어떤 작업에 사람의 승인이 필요한지도 결정해야 한다. 요약 에이전트와 quote-to-cash 에이전트는 둘 다 같은 ID 플랫폼을 사용하더라도 동일한 제어를 받아서는 안 된다.

후자는 가격 책정, 계약, 청구 시스템, 매출 기록을 다룰 수 있다. 실수는 불편한 답변이 아니라 재무 또는 규정 준수 사건이 될 수 있다.

이 차이는 Okta가 배포를 안내할 수 있을 때에만 혼란을 제품 기회로 바꾼다. 청사진은 고객이 더 나은 질문을 하도록 도울 수 있지만, 운영 템플릿과 통합 기능이 답을 제공해야 한다.

이 요건은 Okta의 영업 및 전문 서비스 활동에 부담을 준다. 구매자는 회사가 추상적인 ID 프레임워크를 실제 워크플로를 위한 제어 기능으로 전환하기를 기대할 것이다.

개발자도 관련된 과제에 직면한다. 모든 고객의 ID 시스템에 맞춰 에이전트를 매번 재구축하지 않아도 되는 안전한 접근 패턴이 필요하다. 이것이 Okta의 표준 전략이 제품 논리의 중심에 가까이 자리하는 이유다.

Cross App Access는 개방형 제어 계층을 향한 Okta의 승부수다

Okta는 개방형 권한 부여 표준이 ID 제공업체를 중앙 정책 시행자로 유지하면서 에이전트 접근의 이식성을 높일 수 있다고 보고 있다.

Cross App Access, 즉 XAA는 표준화된 권한 부여를 통해 에이전트를 애플리케이션에 연결하기 위해 Okta가 제안한 방식이다. 이는 OAuth의 개념을 확장하며, 에이전트가 도구를 발견하고 호출할 공통 방식을 제공하는 MCP와 함께 작동한다.

이 구분은 중요하다. MCP는 사용 가능한 도구를 설명하고 상호작용을 지원할 수 있지만, 엔터프라이즈는 여전히 특정 에이전트가 이를 사용해도 되는지를 결정해야 한다. XAA는 ID 및 권한 부여 컨텍스트를 해당 연결로 전달하기 위한 것이다.

Kelleher는 Okta가 Cross App Access를 독점적인 Okta 형식이 아니라 개방형 표준으로 제안했다고 말했다. 또한 이것이 MCP 확장으로 채택됐으며, 폭넓은 업계 관심을 끌고 있다고 밝혔다.

Okta는 2026년 8월 Agent SSO를 정식 출시했다. Agent SSO를 통해 관리자는 에이전트를 워크로드 프린시펄, 즉 독립적으로 관리되는 비인간 ID로 등록할 수 있다.

지원되는 에이전트가 애플리케이션에 연결하면 Okta는 다른 관리 대상 ID와 함께 이를 Universal Directory에 배치할 수 있다. 이후 관리자는 기존 ID 프로세스를 통해 소유권, 연결, 적용 가능한 정책을 확인할 수 있다.

이 접근 방식은 에이전트 배포에서 반복적으로 나타나는 약점을 해결하려 한다. 초기 에이전트 다수는 사용자의 접근 토큰을 빌리거나 워크플로 안에 저장된 정적 자격 증명에 의존한다.

빌린 접근 권한은 책임 추적을 불분명하게 만들 수 있다. 에이전트가 직원의 ID를 사용해 기록을 변경하면, 감사 로그는 소프트웨어의 행동과 사람이 직접 수행한 행동을 구분하지 못할 수 있다.

정적 자격 증명은 또 다른 문제를 만든다. 필요 이상으로 오래 활성 상태를 유지할 수 있으며, 구성 파일, 로그 또는 개발 환경에 나타날 수 있다. 노출된 시크릿은 공격자에게 지속적인 접근 권한을 제공할 수 있다.

전용 에이전트 ID는 행위자를 후원자와 분리한다. 비즈니스 소유자는 계속 책임을 지지만, 보안 시스템은 에이전트와 사람에게 서로 다른 정책을 적용할 수 있다.

이러한 분리는 할당된 작업에 필요한 최소한의 접근만 ID에 허용하는 최소 권한 원칙을 지원한다. 또한 더 짧은 기간의 토큰과 에이전트 폐기 시 더 명확한 해제를 지원할 수 있다.

Okta는 Auth0 for AI Agents가 개발자가 XAA와 함께 작동하는 에이전트를 구축하도록 도울 수 있다고 말한다. 이러한 에이전트는 Okta 전용 환경을 요구하지 않고도 서로 다른 ID 제공업체에 자격 증명을 저장할 수 있다.

개방성은 플랫폼 종속을 우려하는 고객에게 Okta의 제안을 강화한다. 엔터프라이즈는 동일한 환경에서 Microsoft, Google, Salesforce, 자체 개발팀 및 소규모 공급업체의 에이전트를 사용할 수 있다.

휴대 가능한 권한 부여 계층이 마련되면 이러한 에이전트들은 일관된 접근 결정 체계를 접하게 된다. 또한 서로 다른 ID 시스템을 사용하는 엔터프라이즈 고객에게 제품을 판매하는 개발자의 맞춤형 통합 작업도 줄일 수 있다.

그러나 표준이 공개되었다고 해서 자동으로 상호운용성이 확보되는 것은 아니다. 애플리케이션은 이를 구현해야 하고, 에이전트 프레임워크는 필요한 컨텍스트를 전달해야 하며, ID 제공업체는 요청을 일관되게 해석해야 한다.

보안팀은 각 결정에 사용되는 메타데이터도 신뢰할 수 있어야 한다. 에이전트가 유효한 ID를 보유하더라도 조작된 지시를 받거나 안전하지 않은 행동을 선택할 수 있다.

ID는 누가 또는 무엇이 접근을 요청하는지 답한다. 하지만 생성된 계획이 정확하고 윤리적이며 비즈니스 의도에 부합하는지를 독립적으로 판단하지는 않는다.

따라서 Okta의 메커니즘은 중요하지만 범위에는 한계가 있다. XAA는 권한 부여를 더 명시적이고 감사 가능하게 만들 수 있다. 하지만 모델 안전장치, 데이터 거버넌스, 네트워크 통제 또는 애플리케이션 수준의 검증을 대체할 수는 없다.

XAA가 중립적인 연결 표준으로 자리 잡으면 회사는 이점을 얻는다. 반대로 에이전트 플랫폼이 자체 번들형 제어 플레인 내부에 ID 집행을 계속 유지한다면 더 큰 압박에 직면하게 된다.

이러한 압박은 Microsoft가 확장하는 에이전트 ID 스택에서 이미 드러나고 있다.

Microsoft, ID 보안을 유통 경쟁으로 전환하다

Okta가 직면한 핵심 경쟁 과제는 Microsoft가 기업이 이미 사용 중인 애플리케이션, 클라우드 서비스 및 관리 도구에 에이전트 ID를 번들로 제공할 수 있다는 점이다.

Microsoft Entra Agent ID는 2026년 4월 정식 출시됐다. 이는 AI 에이전트를 위해 설계된 ID 구성 요소, 인증, 권한 부여, 거버넌스 및 보안 통제를 제공한다.

그 기반 논리는 Okta의 주장과 매우 유사하다. 에이전트에는 식별 가능한 소유자가 있어야 하고, 수명 주기가 관리돼야 하며, 접근 권한은 제한되고 활동은 감사 가능해야 한다. Microsoft 역시 OAuth, MCP 및 에이전트 간 프로토콜을 지원한다.

차이는 유통에 있다. Microsoft는 방대한 비즈니스 애플리케이션, 개발자 서비스, 클라우드 인프라, 데이터 플랫폼 및 보안 제품군을 통제한다.

Microsoft의 agent identity documentation에 따르면 Agent 365는 회사의 통합 카탈로그 및 관리 계층 역할을 한다. Entra는 그 아래에서 ID 기반을 제공한다.

Microsoft는 에이전트 ID를 Conditional Access, Identity Protection, Microsoft Graph 및 더 광범위한 거버넌스 환경과 연결할 수 있다. 이미 해당 스택 내에서 운영되는 고객은 통합된 관리 경험을 선호할 수 있다.

실질적인 사례는 Microsoft의 Dataverse 통합에서 확인할 수 있다. 영업 개발 에이전트는 리드 조회, 아웃리치 기록, 허용된 레코드 업데이트를 위한 전용 ID와 제한된 역할을 부여받을 수 있다.

관리자는 관련 없는 테이블이나 민감한 필드를 제외할 수 있다. 작업은 공유 직원 계정이나 애플리케이션 계정으로 표시되는 대신 해당 에이전트에 귀속된다.

이 시나리오는 Okta가 마주한 전략적 위험을 보여준다. Microsoft는 업무가 이루어지는 애플리케이션에 거버넌스를 내장할 수 있으므로 에이전트 ID를 별도 카테고리로 판매할 필요가 없다.

Okta의 대응은 독립성이다. 기업이 여러 클라우드, 에이전트 빌더 및 소프트웨어 생태계를 사용할수록 그 가치는 커진다. 중립적인 ID 계층은 이러한 경계 전반에서 일관된 정책을 제공할 수 있다.

Kelleher는 에이전틱 ID가 인간 ID와 비인간 ID의 특성을 결합한다고 강조했다. Okta는 이미 두 범주를 모두 관리하고 있어 수명 주기 거버넌스, 애플리케이션 접근 및 보안 신호에 대한 경험을 갖추고 있다.

통합 카탈로그 역시 회사에 상당한 출발점을 제공한다. Okta는 3월 자사 네트워크에 8,200개 이상의 통합이 포함돼 있으며, 에이전트 지원에는 Boomi, DataRobot 및 Google Vertex AI가 포함된다고 밝혔다.

이러한 폭넓은 범위는 통합이 실질적인 집행을 제공할 때만 의미가 있다. 에이전트를 등록하는 카탈로그 항목과 개별 도구 호출을 권한 부여하고 신속한 권한 철회를 지원하는 항목은 다르다.

Microsoft 역시 자체 생태계에서 같은 시험대에 오른다. 중앙집중식 ID는 권한을 설명할 수 있지만, 애플리케이션은 빠른 다단계 워크플로에서 그러한 권한을 정확히 집행해야 한다.

다른 보안 벤더도 경쟁을 한층 복잡하게 만든다. 권한 접근 관리 기업은 민감한 자격 증명을 관리할 수 있고, 엔드포인트 및 클라우드 보안 제공업체는 에이전트 주변의 행동을 분석할 수 있다.

AI 보안 전문업체는 프롬프트 인젝션, 안전하지 않은 도구 선택, 데이터 유출 및 모델 행동에 집중할 수 있다. 이러한 위협은 에이전트가 전용 ID를 부여받은 뒤에도 사라지지 않는다.

향후 엔터프라이즈 아키텍처에는 여러 통제 계층이 포함될 가능성이 높다. 경쟁이 벌어지는 핵심 질문은 어느 플랫폼이 소유권, 정책 및 조사의 중심지가 되느냐이다.

Okta는 그 자리가 ID 보안 패브릭이어야 한다고 본다. Microsoft는 특히 Microsoft 애플리케이션 전반에서 Agent 365와 Entra가 통합 제어 플레인을 제공하기를 원한다.

고객은 혼합 환경에서 이러한 주장을 판단하게 될 것이다. 자사 네이티브 에이전트만 관리하는 플랫폼은 보안팀에 분절된 인벤토리와 정책을 남길 것이다.

Okta의 독립성은 파편화에 대한 신뢰할 만한 해답을 제시한다. Microsoft의 통합 깊이는 운영 복잡성에 대한 신뢰할 만한 해답을 제시한다.

이것이 이 글의 핵심 경쟁 구도다. 중립적인 ID 계층과 번들형 애플리케이션·클라우드 제어 플레인의 대결이다. 혼란은 Okta가 대화를 시작하는 데 도움이 되지만, 누가 이를 통제할지는 상호운용성이 결정할 것이다.

ID 통제로는 에이전트의 의도를 판단할 수 없다

Okta는 에이전트가 접근할 수 있는 대상을 제한할 수 있지만, 유효한 자격 증명이 안전한 추론이나 올바른 행동을 보장하지는 않는다.

에이전트는 인증에 성공하고 승인된 권한 범위 내에 머물면서도 피해를 초래할 수 있다. 요청을 잘못 해석하거나, 악의적인 지시를 따르거나, 허용된 행동을 결합해 의도하지 않은 결과를 만들 수 있다.

프롬프트 인젝션은 이 간극을 잘 보여준다. 공격자는 에이전트가 읽는 콘텐츠 안에 숨겨진 지시나 오도하는 지시를 삽입할 수 있다. 에이전트는 그러한 지시를 자신의 작업 일부로 간주할 수 있다.

ID 통제는 그로 인한 피해 범위를 제한할 수 있다. 하지만 에이전트의 의사결정 과정이 조작됐다는 사실을 항상 식별할 수는 없다.

같은 한계는 잘못된 계획 수립에도 적용된다. 권한을 부여받은 재무 에이전트가 잘못된 계정을 선택하거나, 작업을 중복 수행하거나, 잘못된 거래에 승인 규칙을 적용할 수 있다.

킬 스위치는 의심스러운 행동이 탐지된 후에 유용해진다. 그러나 자율 에이전트는 사람이 패턴을 인지하고 접근 권한을 철회하기 전에 많은 작업을 실행할 수 있다.

런타임 권한 부여는 이 시간을 줄이려 한다. 광범위한 상시 접근 권한을 부여하는 대신, 시스템은 ID, 컨텍스트, 위험 및 의도된 행동을 바탕으로 개별 요청을 평가한다.

이 평가의 품질은 신뢰할 수 있는 컨텍스트에 달려 있다. 정책은 정당한 워크플로를 막지 않으면서 일반적인 변동과 안전하지 않은 행동을 구분해야 한다.

조직에는 신뢰할 수 있는 로그도 필요하다. 에이전트의 도구 호출을 기록하면 조사자가 사건을 재구성하는 데 도움이 되지만, 로그는 에이전트, 인간 후원자, 지시, 권한 부여 결정 및 그에 따른 변경 사항을 연결해야 한다.

성공한 API 호출만 보여주는 기록은 책임성을 제한적으로만 제공한다. 보안팀은 에이전트가 왜 API를 호출했는지, 그리고 어떤 데이터가 해당 결정을 형성했는지 알아야 한다.

Okta의 시스템 로그 및 거버넌스 기능은 이 연결 고리의 일부를 다룬다. 회사는 도구 호출, 접근 시도 및 권한 부여 결정이 보안 정보 및 이벤트 관리 시스템으로 흘러갈 수 있다고 말한다.

이러한 기능은 고객이 다양한 에이전트 프레임워크와 애플리케이션 전반에서 검증하기 전까지는 회사의 주장에 불과하다. Okta의 자체 발표 역시 미출시 기능이 늦게 제공되거나 아예 제공되지 않을 수 있다고 경고한다.

엔터프라이즈 에이전트 배포는 아직 초기 단계이므로 독립적인 증거는 제한적이다. 학계에서는 에이전틱 시스템의 ID 관리를 검토하기 시작했지만, 프로덕션 벤치마크는 여전히 발전 중이다.

추가적인 우려는 소유권의 질이다. 인간 후원자를 지정하면 문서상 책임성은 생기지만, 그 사람은 에이전트의 데이터, 권한, 종속성 및 폐기 조건을 이해해야 한다.

조직이 관리자가 검토할 수 있는 속도보다 빠르게 에이전트를 배포하면 소유권은 형식적인 절차가 될 수 있다. 그렇게 되면 접근 인증은 충분한 컨텍스트가 없는 또 하나의 승인 대기열이 될 위험이 있다.

에이전트 확산은 문제를 더 악화시킨다. 주 에이전트는 조사, 분석 또는 실행을 위해 임시 하위 에이전트를 만들 수 있다. 보안 정책은 이러한 임시 ID가 권한을 상속받는지 결정해야 한다.

광범위한 상속은 관리하기 쉽지만 노출을 늘린다. 단기 에이전트마다 별도 승인을 요구하면 에이전틱 워크플로의 매력인 속도가 약화될 수 있다.

이것이 Okta AI 에이전트 보안의 핵심 트레이드오프다. 기업은 에이전트가 시스템 전반에서 신속히 작동하기를 원하지만, 보안팀은 모든 행동이 제한되고, 추적 가능하며, 되돌릴 수 있기를 원한다.

통제가 너무 적으면 감당할 수 없는 위험이 발생한다. 마찰이 너무 크면 자율 워크플로는 다시 느린 일련의 인간 승인 절차로 돌아간다.

가장 강력한 배포는 좁은 업무와 명시적인 데이터 경계에서 시작될 것이다. 지원 에이전트는 크레딧 발행이나 고객 기록 변경 권한을 받기 전에 티켓을 분류할 수 있다.

팀은 성공적인 데모뿐 아니라 실패 경로도 테스트해야 한다. 소유권 만료, 조작된 입력, 과도한 권한 및 사용할 수 없는 집행 서비스에 시스템이 어떻게 대응하는지를 보여주는 증거가 필요하다.

검색 가능한 knowledge base는 팀이 소유자, 정책 및 사고 결정을 문서화하는 데 도움이 될 수 있다. 이는 접근 통제를 대체하지는 않지만, 검토자가 필요로 하는 컨텍스트를 보존한다.

고객이 ID 결정을 축소된 권한 및 더 빠른 사고 차단과 연결할 수 있을 때 Okta의 전략은 더욱 설득력을 얻는다. 제품 발표만으로는 그러한 결과를 입증할 수 없다.

Okta의 추진력이 효과를 내는지 보여줄 세 가지 신호

표준 채택, 고객 확장 및 크로스플랫폼 집행이 Okta가 혼란을 지속 가능한 ID 보안 카테고리로 전환하는지를 결정할 것이다.

첫 번째 신호는 Okta의 자체 제품을 넘어선 Cross App Access의 채택이다. 에이전트 개발자, 애플리케이션 벤더 및 경쟁 ID 제공업체가 이 프로토콜을 구현해야 의미 있는 인프라가 될 수 있다.

Okta는 9월 콘퍼런스에서 더 광범위한 발표가 다가오고 있다고 말했다. 중요한 세부 사항은 이름이 언급된 파트너 수가 아니다. 구매자는 이러한 통합이 실제로 어떤 행동을 권한 부여할 수 있는지 살펴봐야 한다.

등록 지원은 인벤토리를 제공한다. 범위가 지정되고 컨텍스트를 고려한 권한 부여 지원은 통제를 제공한다. 신속한 권한 철회 지원은 에이전트가 의도된 역할에서 벗어날 때 차단 수단을 제공한다.

작동하는 통합이 늘어나면 Okta의 중립 플랫폼 주장이 강화될 것이다. 제한적인 채택에 그친다면 XAA는 업계 제어 계층이 아니라 Okta 환경 안에서 유용한 기능으로 남게 된다.

두 번째 신호는 고객 갱신과 확장의 양상이다. Kelleher는 초기 에이전틱 거래 대부분이 1년 계약을 사용하므로 고객과 Okta가 사용 사례를 이해할 시간을 얻는다고 말했다.

이러한 갱신은 기업이 평가 단계를 넘어서는지를 보여줄 것이다. 구매자는 고립된 데모가 아니라 여러 비즈니스 프로세스 전반에서 프로덕션 에이전트를 관리하는 배포 사례를 찾아야 한다.

추가 에이전트 플랫폼으로의 확장은 ID가 공통 제어 플레인을 제공한다는 주장을 뒷받침할 것이다. 실험적 프로젝트에만 연계된 성장은 혼란이 여전히 판매 장벽으로 남아 있음을 시사할 것이다.

가격 정책도 또 다른 단서를 제공할 것이다. Okta의 사용자당 추가 요금은 초기 구매를 단순화하지만, 에이전트 규모와 활동량은 반드시 직원 수와 비례하지는 않는다.

모델은 보호된 에이전트, 연결, 거래 또는 권한 부여 이벤트 쪽으로 발전할 수 있습니다. 어떤 변화든 고객이 무엇을 가치 있게 여기며 어떤 운영 비용이 가장 중요한지를 드러낼 것입니다.

안정적이고 이해하기 쉬운 모델은 이 분야의 성숙에 도움이 될 것입니다. 복잡한 사용량 기반 요금제는 Okta의 청사진이 제거하려는 불확실성을 다시 불러올 수 있습니다.

세 번째 신호는 Microsoft 및 기타 ID 제공업체의 경쟁 대응입니다. Microsoft의 Agent 365 모델은 이미 통합 인벤토리와 Entra 기반 ID 및 거버넌스를 결합하고 있습니다.

Microsoft가 타사 에이전트를 위한 단순한 거버넌스를 확장한다면, Okta의 독립성 주장은 직접적인 시험대에 오를 것입니다. Microsoft가 자사 환경 내에서만 가장 강력한 위치를 유지한다면, Okta는 이기종 환경의 기업에서 더 많은 기회를 얻게 됩니다.

고객은 Microsoft 365, Google Workspace, Salesforce, 클라우드 플랫폼 및 맞춤형 애플리케이션 전반의 정책 집행을 비교해야 합니다. 승자는 중앙 에이전트 목록 이상의 기능을 제공해야 합니다.

애플리케이션 경계를 넘어 에이전트 ID를 유지하고, 최소 권한 원칙을 적용하며, 소유권을 명확히 드러내고, 일관되게 액세스를 종료할 수 있어야 합니다. 또한 보안팀이 조사와 감사 과정에서 활용할 수 있는 증거를 제공해야 합니다.

공통 표준에 대한 경쟁사의 지원은 제품 차별화를 줄이더라도 Okta의 더 큰 논지를 검증할 것입니다. 독점적 접근 방식은 에이전트 ID를 또 하나의 플랫폼 경계로 만들 것입니다.

Okta의 컨퍼런스 메시지는 AI 에이전트 보안을 단일 탐지 기능으로 취급하지 않는다는 점에서 주목할 만합니다. 이 회사는 에이전트의 수명 주기 전반에 걸친 책임성과 액세스를 중심으로 문제를 규정하고 있습니다.

이러한 관점은 운영상 과제와 부합합니다. 기업은 누가 에이전트를 만들었는지, 왜 존재하는지, 어떤 리소스에 접근할 수 있는지, 그리고 어떻게 중지할 수 있는지를 알아야 합니다.

그러나 ID는 여러 제어 영역 중 하나일 뿐입니다. 모델 보호장치, 애플리케이션 검증, 네트워크 모니터링, 데이터 거버넌스 및 사람의 검토는 여전히 필요합니다.

따라서 보안 구매자는 Okta의 청사진을 테스트 프레임워크로 여겨야 합니다. 실제 워크플로 전반에서 각 공급업체에 검색, 권한 부여, 소유권, 로깅 및 권한 철회를 입증하도록 요구할 수 있습니다.

가장 설득력 있는 증거는 의도적으로 범위를 제한한 프로덕션 배포에서 나올 것입니다. 팀은 제한된 정보만 읽고 사람이 승인할 조치를 제안하는 에이전트부터 시작할 수 있습니다.

그런 다음 과도한 권한 요청, 정책 거부, 조사 소요 시간 및 운영 종료 정확도를 측정할 수 있습니다. 이러한 결과는 정교하게 꾸며진 자율형 데모보다 더 많은 것을 보여 줍니다.

Okta AI 에이전트 보안은 궁극적으로 기업이 흩어진 자격 증명과 분리된 제어 수단으로 자율 소프트웨어를 관리하지 않을 것이라는 데 거는 베팅입니다. 시장은 전용 ID, 명시적 소유권 및 지속적인 권한 부여로 이동하고 있습니다.

해결되지 않은 질문은 혼합 환경 전반에서 누가 그 계층을 제공할 것인지입니다. 먼저 XAA 통합을, 다음으로 프로덕션 갱신을, 세 번째로 Microsoft의 타사 확장성을 지켜보십시오.

Okta가 이 세 가지 모두에서 진전을 이룬다면, 혼란은 지속 가능한 ID 비즈니스 기회가 될 것입니다. 도입이 계속 파편화된다면, 번들형 플랫폼이 우위를 유지할 것입니다.

기업 팀의 다음 단계는 실용적입니다. 에이전트 하나를 선택하고, 모든 연결을 매핑하며, 허용된 모든 작업을 문서화하십시오. 그런 다음 현재 ID 시스템이 별도 맞춤 작업 없이 해당 에이전트를 확인하고, 제한하고, 감사하고, 권한을 철회할 수 있는지 물어보십시오.