AI Agent 보안은 ID에서 시작하지만, 기업에는 자격 증명 그 이상이 필요하다

Google News는 9월 2일 AI agent에 대한 경고를 부각했지만, 쟁점은 또 하나의 보안 체크리스트를 훨씬 넘어선다. 이 글은 agent가 더 널리 확산되기 전에 기업이 세 가지 질문에 답해야 한다고 주장한다. agent는 어디에 있고, 무엇에 연결할 수 있으며, 무엇을 할 수 있는가?

이러한 프레임은 Okta의 보안 제품 마케터 Ariel Zommer가 GuidePoint Security에 기고한 글에서 제시됐다. 핵심 주장은 단순하다. agent가 인증하고, 기업 시스템에 접근하거나, 지속적인 사람의 지시 없이 행동할 수 있게 되는 순간 이는 ID 문제가 된다.

시점도 중요하다. NIST는 GuidePoint 글이 공개되기 일주일도 전인 8월 27일 별도의 ID 경고를 발표했다. Microsoft, Okta 및 다른 ID 공급업체들도 agent ID를 공식 제품 객체로 전환하고 있다.

이러한 수렴은 기업 내 논의를 바꾼다. 핵심 질문은 더 이상 모델이 정확한 답변을 생성할 수 있는지가 아니다. 결과적으로 발생하는 모든 작업에 식별 가능한 수행 주체, 제한된 권한, 책임 있는 소유자, 그리고 철회 가능한 연결이 있는지다.

ID 관리가 이미 직원, 애플리케이션, 전통적인 워크로드를 관리하기 때문에 이 주장은 익숙하게 들린다. agent는 행동이 확률적이고 연결이 변하며, 하나의 요청이 여러 후속 작업을 촉발할 수 있다는 점에서 이 모델을 복잡하게 만든다.

따라서 ID는 필요하지만 충분하지는 않다. 자격 증명은 agent를 식별할 수 있지만, 현재의 행동이 안전하다는 사실까지 증명하지는 못한다. 진짜 경쟁은 책임 있는 자율성과 조직이 완전히 추적할 수 없는 편리한 접근 사이에서 벌어진다.

Google News가 실제로 부각한 내용

이번 뉴스는 새로운 취약점 공개가 아니다. agent 도입 속도가 기업의 ID 통제를 앞지르고 있다는 공동 경고다.

원래의 ID 주장은 GuidePoint Security가 2026년 9월 2일 공개했다. 이 글은 Okta 직원이 작성했으며 파트너 관점으로 제시됐다.

이 구분은 중요하다. 독자는 이 글을 하나의 상용 플랫폼이 모든 agent 보안 문제를 해결한다는 독립적 증거가 아니라, 공급업체가 뒷받침한 분석으로 받아들여야 한다. 다만 세 가지 질문은 측정 가능한 통제 공백을 설명한다는 점에서 여전히 유용하다.

첫 번째 질문은 조직의 agent가 어디에 존재하는지 묻는다. 목록에는 내부 개발 agent, SaaS 제품에 내장된 기능, 클라우드 호스팅 agent, 직원이 승인한 도구, 실험 시스템이 포함돼야 한다.

전통적인 자산 목록은 이런 범주를 놓치는 경우가 많다. 개발자는 승인된 클라우드 계정 안에서 agent를 만들면서 이를 별도 비즈니스 애플리케이션으로 등록하지 않을 수 있다. 직원 역시 OAuth를 통해 외부 도구를 승인할 수 있다.

OAuth는 한 애플리케이션이 다른 서비스에 제한된 접근 권한을 받도록 하는 인가 표준이다. 그 편의성은 기반 agent를 승인하지 않았던 팀에게 지속적인 신뢰 관계를 가릴 수 있다.

따라서 탐지는 코드 저장소 스캔 이상을 요구한다. 보안 팀은 클라우드 인벤토리, 애플리케이션 등록, OAuth 권한 부여, 서비스 계정, 브라우저 신호, API 게이트웨이 기록, Model Context Protocol 연결도 필요하다.

Model Context Protocol, 즉 MCP는 AI 애플리케이션이 공통 인터페이스를 통해 도구와 데이터에 연결할 수 있게 한다. 이는 통합을 단순화하는 동시에 접근 가능한 시스템의 범위를 넓힐 수 있다.

두 번째 질문은 발견된 각 agent가 무엇에 연결할 수 있는지를 묻는다. 이 지도는 비즈니스 애플리케이션, 내부 API, 데이터베이스, 협업 시스템, 시크릿, 서비스 계정 및 다른 agent를 포괄해야 한다.

연결만으로는 전체 위험을 드러낼 수 없다. 보안 팀은 인가 방식, 권한 범위, 자격 증명 수명, 비즈니스 소유자, 승인 이력, 철회 경로도 파악해야 한다.

세 번째 질문은 agent가 연결 이후 무엇을 할 수 있는지를 묻는다. 읽기 접근, 레코드 수정, 코드 실행, 자금 이동, 사용자 사칭은 매우 다른 결과를 초래한다.

이러한 권한은 결합될 수도 있다. 이메일을 읽고 지원 티켓을 생성하는 agent는 각 연결을 따로 검토하면 제한적으로 보인다. 그러나 지침을 추출하고 외부 작업을 실행할 수 있다면 영향력은 더 커진다.

Google News는 이 경고를 더 넓은 독자층에 알리는 데 도움을 줬다. 그러나 중요한 변화는 집계 계층 아래에서 일어났다. ID 공급업체와 공공 표준 기구가 agent를 일급 기업 행위자로 보는 관점에 수렴하고 있다.

이 변화는 보안 리더에게 더 명확한 출발점을 제공한다. 동시에 agent의 ID를 이를 실행한 사용자, 애플리케이션 또는 서비스 계정과 구별해야 한다는 압박도 만든다.

빌려 쓴 직원 토큰은 이런 구분을 명확하게 제공할 수 없다. 여러 agent가 사용하는 하나의 공유 API 키도 마찬가지다. 두 방식 모두 감사와 사고 조사 중 책임 추적을 약화시킨다.

즉각적인 변화는 개념적이지만 운영과도 직결된다. 이제 기업은 생성, 소유권, 인가, 검토, 중단, 폐기를 포함한 agent별 별도 라이프사이클 기록이 필요하다.

ID는 AI 제어 플레인이 됐다

agent에는 고유한 ID가 필요하다. 책임 추적 없는 권한은 일상적인 자동화를 끝없이 조사해야 하는 문제로 바꾸기 때문이다.

ID 및 접근 관리, 즉 IAM은 누가 어떤 조건에서 리소스에 접근할 수 있는지를 결정한다. 기존 IAM 시스템은 이미 디렉터리, 정책 엔진, 접근 검토, 토큰 서비스, 감사 기록을 제공한다.

이 구성 요소들은 기업에 실용적인 기반을 제공한다. 기업은 agent를 등록하고, 소유자와 연결하며, 구체적인 권한을 부여하고, agent가 변경되거나 폐기될 때 해당 권한을 철회할 수 있다.

NIST도 최근 ID 기반 분석에서 이 입장을 강화했다. 이 기관은 초기 배포가 확립된 ID 관행보다 기능과 즉각적인 가치를 우선시하고 있다고 경고했다.

NIST는 자격 증명 공유 역시 핵심 문제로 지적했다. 공유 자격 증명은 조사자가 어떤 사람, 서비스 또는 agent가 거래를 수행했는지 신뢰성 있게 판단할 수 없게 하므로 책임성을 훼손한다.

agent가 작업을 위임하면 문제는 더욱 선명해진다. 사용자는 한 agent에게 영업 브리핑을 준비하라고 요청할 수 있다. 이 agent는 계정 데이터를 위해 다른 시스템을 호출하고, 경쟁사 조사를 위해 세 번째 서비스를 호출할 수 있다.

모든 전달 과정은 인가 결정을 만든다. 기업은 요청의 원래 사용자, 행동하는 agent, 요청된 리소스, 그리고 요청의 목적을 보존해야 한다.

이 연결 고리가 없으면 로그는 서비스 계정이 데이터베이스에 접근했다는 사실만 보여줄 수 있다. 어떤 agent가 작업을 시작했는지, 어떤 사용자가 요청했는지, 또는 해당 작업이 승인된 워크플로에 부합했는지는 설명하지 못한다.

일급 ID는 이 맥락의 일부를 복원할 수 있다. 각 agent는 범용 계정을 빌리는 대신 고유 식별자를 받는다. 그러면 정책은 특정 agent를 대상으로 적용될 수 있다.

이 모델은 할당된 작업에 필요한 최소한의 접근만 ID에 부여하는 최소 권한 원칙을 지원한다. 또한 관련 없는 애플리케이션이나 직원에게 영향을 주지 않고 권한을 철회할 수 있게 한다.

수명이 짧은 토큰은 설계를 강화한다. 토큰은 제한된 범위와 기간에 대해 부여된 권한을 나타내는 서명된 자격 증명이다. 짧은 만료 시간은 탈취된 자격 증명의 가치를 낮춘다.

연합 자격 증명은 또 다른 개선책이다. 이는 신뢰할 수 있는 워크로드가 코드, 구성 파일 또는 agent의 메모리에 재사용 가능한 시크릿을 저장하지 않고 토큰을 요청할 수 있게 한다.

소유권은 기본 기록을 완성한다. 모든 프로덕션 agent에는 목적, 권한, 검토, 폐기에 대해 책임지는 지정된 사람 또는 책임 팀이 필요하다.

소유자가 최초 프로토타입을 만든 개발자에 그쳐서는 안 된다. 누군가는 해당 agent의 접근이 여전히 필요한지 판단해야 하므로 비즈니스 소유권이 중요하다.

라이프사이클 상태도 중요하다. 실험용 agent는 테스트가 끝난 뒤에도 프로덕션 권한을 유지해서는 안 된다. 교체된 agent는 API 키가 여전히 작동한다는 이유로 활성 상태로 남아서는 안 된다.

이 구조는 직원과 애플리케이션을 위한 거버넌스와 유사하다. 그러나 agent는 도구, 지침, 모델, 위임 작업이 독립적으로 바뀔 수 있으므로 더 자주 평가해야 한다.

따라서 기업은 ID 디렉터리를 정적인 주소록이 아니라 제어 플레인으로 다뤄야 한다. 등록은 거버넌스의 시작일 뿐이며, 지속적인 정책 집행이 이를 의미 있게 만든다.

이 구분은 정당한 실험도 보호한다. 개발자는 배포 후 대규모 보안 검토를 기다리는 대신, agent를 등록할 수 있는 명확한 경로를 제공받을 수 있다.

사용하기 쉬운 등록 절차는 목적, 소유자, 환경, 도구, 데이터 분류, 권한, 예상 운영 경계를 포착해야 한다. 또한 만료일 또는 검토일을 지정해야 한다.

승인된 경로가 등록되지 않은 agent를 만드는 것보다 느리다면 팀은 이를 우회할 것이다. 따라서 ID 프로그램은 안전한 온보딩이 숨겨진 배포보다 쉬워지도록 해야 한다.

여기서 지식 관리 관행이 거버넌스를 지원할 수 있다. 팀에는 의사결정, 소유자, 요구사항, 승인, 이후 변경 사항을 연결하는 검색 가능한 기록이 필요하다.

인벤토리만으로는 agent가 어디에 등록됐는지 알 수 있다. 연결된 운영 지식은 그것이 왜 존재하는지, 그리고 현재 행동이 여전히 그 목적에 부합하는지를 설명한다.

세 가지 질문은 서로 다른 세 가지 실패를 드러낸다

탐지, 연결 통제, 행동 거버넌스는 별개의 분야이며, 하나를 통과했다고 해서 다른 하나의 실패를 보완할 수는 없다.

“내 agent는 어디에 있는가?”는 가시성을 검증한다. 보안 팀은 개발자의 계정, 직원의 브라우저 또는 SaaS 관리자의 구성 안에만 존재하는 agent를 거버넌스할 수 없다.

유용한 인벤토리에는 승인된 배포와 승인되지 않은 배포가 모두 포함돼야 한다. 또한 활성 agent와 템플릿, 방치된 실험, 비활성 인스턴스, AI 기능을 사용하는 일반 애플리케이션을 구별해야 한다.

인벤토리는 모든 agent의 환경과 운영 상태를 식별해야 한다. 개발, 테스트, 프로덕션 agent가 같은 승인 전제를 공유해서는 안 된다.

보안 팀은 무엇을 agent로 간주할지도 결정해야 한다. 텍스트만 반환하는 챗봇은 도구를 호출하거나 레코드를 변경하는 시스템과 다른 권한 프로필을 가진다.

정의는 행동에 초점을 맞춰야 한다. 소프트웨어가 제한된 사람의 검토 아래 행동을 선택하고, 연결된 도구를 호출하거나, 작업을 위임한다면 거버넌스 대상에 속한다.

“무엇에 연결할 수 있는가?”는 조직의 신뢰 그래프를 검증한다. 신뢰 그래프는 ID, 자격 증명, 애플리케이션, 리소스, 위임 서비스 간의 관계를 기록한다.

이 그래프는 직접적 접근과 간접적 접근을 모두 보여야 한다. agent에 데이터베이스 접근 권한은 없지만 동일한 데이터베이스를 조회할 수 있는 서비스를 호출할 권한은 있을 수 있다.

agent 간 연결은 매핑을 더 어렵게 만든다. 한 agent가 다른 agent에 맥락이나 권한을 전달하면서 플랫폼과 관리 경계를 넘는 체인을 만들 수 있다.

기업은 각 연결이 상시 접근을 사용하는지, 작업별 인가를 사용하는지 기록해야 한다. 상시 접근은 작업 사이에도 유지되므로 agent가 침해됐을 때 노출을 늘린다.

“그들은 무엇을 할 수 있는가?”라는 질문은 런타임 통제를 검증한다. 그 답은 애플리케이션 등록에서 복사한 API 범위 목록일 수 없다.

어떤 범위는 파일 수정을 허용할 수 있지만, 정책은 일상적인 편집과 리포지토리 삭제를 여전히 구분해야 한다. 동일한 기술적 권한이 서로 다른 비즈니스 결과를 초래하는 작업을 포괄할 수 있다.

런타임 권한 부여는 제안된 작업이 발생하는 시점에 이를 평가한다. 여기에는 작업을 수행하는 에이전트, 요청을 시작한 사용자, 리소스의 민감도, 요청된 작업, 위치, 현재 위험 신호 등을 고려할 수 있다.

일부 결정은 자동으로 유지되어야 한다. 모든 저위험 조회에 사람의 승인을 요구하면 에이전트가 약속하는 생산성 가치는 사라진다.

영향이 큰 작업에는 더 강한 마찰 장치가 필요하다. 프로덕션 시스템 변경, 자금 이체, 규제 대상 정보 공개, 되돌릴 수 없는 삭제에는 명시적인 안전장치가 필요하다.

휴먼 인 더 루프 승인은 하나의 선택지다. 이는 에이전트가 민감한 작업을 완료하기 전에, 정의된 의사결정 지점에서 사람이 개입하도록 한다.

승인은 의미 있는 맥락을 제공해야 한다. 리소스, 데이터, 목적, 예상 효과를 명시하지 않은 채 “작업 허용”이라고만 표시하는 프롬프트는 형식적인 체크박스가 된다.

조직에는 신뢰할 수 있는 비활성화 기능도 필요하다. 킬 스위치는 눈에 보이는 인터페이스만 비활성화하는 것이 아니라, 연결된 시스템 전반에서 에이전트의 활성 접근 권한을 철회해야 한다.

이 기능은 자격 증명 아키텍처에 달려 있다. 에이전트가 흩어진 API 키, 캐시된 토큰, 외부 서비스에 복사된 자격 증명을 사용할 때 중앙 철회는 제대로 작동하지 않는다.

따라서 세 가지 질문은 하나의 순서를 이룬다. 탐색은 주체를 확립하고, 연결 매핑은 잠재적 도달 범위를 정의하며, 작업 거버넌스는 실제로 행사되는 권한을 통제한다.

이 순서를 건너뛰면 잘못된 확신이 생긴다. 조직은 완전한 에이전트 디렉터리를 유지하면서도, 목록에 있는 모든 에이전트에 과도한 권한을 부여한 채로 둘 수 있다.

또한 직원이 만든 에이전트를 놓치면서도 범위를 좁힌 토큰을 발급할 수 있다. 혹은 에이전트의 작업을 기록하면서도 이를 귀속할 만큼 충분한 신원 맥락을 보존하지 않을 수 있다.

이 프레임워크의 가치는 바로 이러한 실패 경계에 있다. 각 질문은 감사 담당자와 보안 리더에게 “책임 있는 AI”에 대한 포괄적 보증이 아니라 검증할 수 있는 구체적인 주장을 제공한다.

신원 통제만으로는 작업이 현명한지 판단할 수 없다

유효한 신원은 누가 작업하는지를 알려주지만, 에이전트가 요청을 이해했거나 안전한 작업을 선택했음을 보장하지는 않는다.

이 한계는 이 글의 핵심적인 트레이드오프를 규정한다. 기업에는 신원 기반 통제가 필요하지만, 에이전트는 동일한 자격 증명을 사용하는 전통적 애플리케이션보다 여전히 예측 가능성이 낮다.

전통적인 서비스는 알려진 워크플로를 위해 작성된 코드를 실행한다. 에이전트는 지시를 해석하고, 도구를 선택하며, 매개변수를 생성하고, 반환된 정보에 따라 경로를 조정할 수 있다.

이러한 유연성은 가치를 만든다. 동시에 인증 성공만으로는 다음 결정이 사용자의 의도와 일치한다는 증거가 될 수 없음을 의미한다.

프롬프트 인젝션은 그 간극을 보여준다. 에이전트는 문서, 이메일, 웹페이지 또는 검색된 레코드 내의 악의적인 지시를 접하고 이를 작업의 일부로 취급할 수 있다.

공격자는 에이전트의 신원을 탈취할 필요가 없다. 적법하게 인증된 에이전트가 정당한 권한을 오용하도록 조작하려 할 수 있다.

OWASP는 신원 및 권한 오용을 에이전틱 보안 위험 중 하나로 분류한다. 이 범주는 위임 체인, 상속된 역할, 캐시된 자격 증명, 에이전트 컨텍스트의 조작을 포괄한다.

도구 오용은 또 다른 문제를 만든다. 에이전트는 승인된 도구를 안전하지 않은 인수로 호출하거나 워크플로의 잘못된 단계에서 호출할 수 있다.

신원 통제는 승인되지 않은 도구에 대한 접근을 거부할 수 있다. 그러나 허용된 모든 호출이 사용자의 실제 목표를 뒷받침하는지는 독립적으로 판단할 수 없다.

따라서 보안 아키텍처는 모델을 신뢰할 수 없는 의사결정 구성 요소로 취급해야 한다. 결과가 중요한 곳에서는 결정론적 통제가 모델 외부에 남아 있어야 한다.

결정론적 통제는 확률적 응답을 생성하는 대신 명시적인 규칙을 따른다. 예로는 권한 검사, 스키마 검증, 거래 한도, 필수 승인 게이트가 있다.

정책 엔진은 에이전트가 스스로를 통제하도록 의존하지 말고, 에이전트가 제안하는 내용을 평가해야 한다. 에이전트는 자신의 권한을 통제하는 규칙을 다시 작성할 수 없어야 한다.

입력 및 출력 검증은 여전히 중요하다. 도구 매개변수는 예상 스키마, 리소스 한도, 데이터 분류, 승인된 목적지에 부합해야 한다.

네트워크 통제는 도달 범위를 더 줄일 수 있다. 공개 인터넷 접근이 전혀 필요하지 않은 에이전트에는 이를 기본적으로 부여해서는 안 된다.

신원은 승인된 수신자에게 부적절하게 정보를 공개하는 일을 막지 못하므로 데이터 통제도 중요하다. 정책은 데이터 민감도, 목적, 보존 기간도 고려해야 한다.

모니터링은 로그인뿐 아니라 행동에도 초점을 맞춰야 한다. 인증 성공 후 비정상적인 열거, 대량 다운로드 또는 반복적인 거부 작업이 이어지면 조사가 필요하다.

이 지점에서 신원 우선 주장은 신중하게 표현되어야 한다. 신원은 책임성, 철회, 정책을 위한 기반을 제공한다. 그러나 완전한 에이전트 안전 시스템은 아니다.

상용 신원 플랫폼은 등록과 토큰을 중앙화할 수 있다. 하지만 연결된 모든 모델이 조작에 저항하거나 모호한 목표를 올바르게 해석한다고 보장할 수는 없다.

벤더 중립성 역시 불확실한 상태다. 에이전트는 Microsoft, Google Cloud, Amazon Web Services, Salesforce, ServiceNow, 내부 프레임워크, 특화 SaaS 제품 전반에 걸쳐 운영될 것이다.

각 플랫폼은 에이전트를 서로 다르게 표현할 수 있다. 크로스 플랫폼 신원 체계에는 상호운용 가능한 토큰, 일관된 클레임, 신뢰할 수 있는 발급자, 그리고 인계 과정에서도 유지되는 정책이 필요하다.

MCP는 또 다른 경계를 추가한다. 기업은 에이전트를 관리하면서도 외부 서버가 도구를 정확히 노출하고 자체 자격 증명을 보호하는 데 의존할 수 있다.

신원 계층 역시 침해로부터 보호해야 한다. 중앙화된 디렉터리와 토큰 서비스는 한 번에 많은 에이전트에 영향을 미칠 수 있으므로 가치 있는 공격 표적이 된다.

기업은 관리 업무를 분리하고, 고권한 변경을 보호하며, 비정상적인 정책 수정을 모니터링해야 한다. 에이전트 거버넌스가 광범위한 권한을 가진 콘솔 계정 하나에 의존해서는 안 된다.

감사 로그도 같은 수준의 회의적인 시각으로 다뤄야 한다. 많은 양의 이벤트가 자동으로 유용한 증거를 만들어내는 것은 아니다.

조사 담당자에게는 사용자 요청, 에이전트 신원, 위임된 에이전트, 선택된 도구, 권한 부여 결정, 영향을 받은 리소스, 최종 결과를 연결하는 기록이 필요하다.

보존 정책은 조사와 규제 검토를 위해 그 체인을 충분히 오래 보존해야 한다. 민감한 프롬프트와 출력에는 최소화 또는 제한된 접근이 필요할 수 있다.

올바른 결론은 벤더 메시지보다 더 제한적이다. 통제에는 알려진 주체가 필요하므로 신원은 에이전트 보안의 출발점이다.

보안에는 그 주체를 둘러싼 다층 방어가 여전히 필요하다. 이러한 계층에는 제약된 도구, 외부 정책, 보호된 자격 증명, 데이터 통제, 모니터링, 사람의 검토가 포함된다.

Microsoft와 Okta는 모델을 제품으로 전환하고 있다

신원 우선이라는 개념은 컨퍼런스의 언어에서 디렉터리, 토큰 흐름, 탐색 시스템, 철회 통제로 옮겨가고 있다.

Microsoft Entra Agent ID는 주요 플랫폼이 이제 에이전트를 직접 표현하는 방식을 보여준다. Microsoft는 에이전트 신원을 고유 식별자를 가진 특수 서비스 주체로 설명한다.

서비스 주체는 신원 테넌트 내에서 애플리케이션이나 워크로드를 나타낸다. 에이전트 버전은 정책과 로그가 에이전트를 그 기반 블루프린트와 구분할 수 있게 한다.

Microsoft의 자율 인증 흐름은 에이전트 신원을 재사용 가능한 프로덕션 비밀과 분리한다. 문서는 클라이언트 비밀 대신 관리형 ID 또는 인증서를 권장한다.

자율 에이전트는 자신의 신원을 위한 애플리케이션 토큰을 요청할 수 있다. 대화형 에이전트는 인증된 사용자를 대신해 작업할 때 위임 흐름을 사용할 수 있다.

이 차이는 필수적이다. 자율적으로 작동하는 야간 보고 에이전트는 로그인한 직원 대신 단일 작업을 수행하는 어시스턴트와 동일하게 보이면 안 된다.

OBO(On-behalf-of) 권한 부여는 위임 과정에서도 사용자 관계를 보존한다. 결과 토큰은 사용자를 주체로, 에이전트를 행위자로 식별할 수 있다.

이 설계는 리소스 서버에 권한 부여를 위한 더 많은 맥락을 제공한다. 시스템은 해당 에이전트를 통해 작업하는 그 사용자가 요청된 작업을 수행할 수 있는지 물을 수 있다.

Microsoft는 사용자와 유사한 객체가 필요한 리소스를 위한 특수 에이전트 사용자 계정도 문서화하고 있다. 이러한 계정은 일반 사람 자격 증명을 사용하지 않고도 메일함이나 협업 기능을 지원할 수 있다.

이 계정에는 제한이 포함된다. Microsoft는 이들이 권한 있는 관리자 역할을 받을 수 없다고 밝히며, 일부 권한 상승 형태에 대한 경계를 만든다.

Okta는 플랫폼 중립적인 신원 관점에서 동일한 시장을 공략하고 있다. 4월 에이전트 신원 출시에서는 탐색, 등록, 관리형 연결, 거버넌스, 비활성화를 설명했다.

회사는 자사 디렉터리가 외부 플랫폼에서 에이전트를 가져오고 맞춤형 에이전트를 등록할 수 있다고 말한다. 또한 OAuth 동의 신호를 통해 섀도 에이전트를 탐지한다고 설명한다.

Okta는 GuidePoint 게스트 기고문에서 반복된 동일한 세 가지 질문을 중심으로 제품을 구성한다. 이러한 중복은 이 글의 상업적 맥락을 확인해 준다.

제품 메시지는 면밀히 검토할 필요가 있지만, 구현 범주는 구체적이다. 기업에는 에이전트용 디렉터리, 연결을 위한 범위가 좁은 토큰, 작업을 위한 정책 집행이 필요하다.

플랫폼이 상호운용 가능한 통제를 제공한다면 경쟁은 구매자에게 이익이 될 것이다. Microsoft의 모델은 Entra와 Microsoft Graph를 중심으로 운영되는 조직에 적합할 수 있다.

Okta는 여러 클라우드, 애플리케이션, 에이전트 프레임워크 전반의 거버넌스를 강조한다. 클라우드 제공업체는 당연히 기존 워크로드 신원 시스템과 에이전트 서비스를 통합할 것이다.

위험은 파편화다. 기업은 클라우드별 에이전트 인벤토리 하나, 신원 제공업체 내부의 또 하나, SaaS 관리 포털 내부의 여러 개를 갖게 될 수 있다.

조직이 표준 소유권 및 수명주기 프로세스를 정의하지 않으면 이러한 인벤토리는 서로 일치하지 않을 것이다. 탐색 도구는 병렬적인 진실의 원천을 만드는 대신 그 프로세스에 정보를 제공해야 한다.

토큰 호환성도 또 다른 문제다. OAuth는 권한 부여 메커니즘을 표준화할 수 있지만, 벤더마다 신원 클레임, 위임 증거, 런타임 정책 통제는 다를 수 있다.

에이전트 간 통신은 위험도를 높인다. 첫 번째 에이전트는 사용자의 위임된 권한을 지닐 수 있는 반면, 다운스트림 에이전트는 애플리케이션 권한 아래에서 자율적으로 작동한다.

권한 부여 체인은 권한이 어디에서 변경되었는지 보여줘야 한다. 그렇지 않으면 승인된 사용자 요청이 눈에 보이는 권한 상승 없이 광범위한 기계 작업으로 바뀔 수 있다.

조달 팀은 실제 워크플로를 기준으로 제품을 시험해야 한다. 세련된 디렉터리 인터페이스보다 중요한 것은 플랫폼이 영향을 받는 모든 커넥터에서 접근 권한을 철회할 수 있는지다.

또한 내보내기 가능성도 시험해야 한다. 감사 데이터는 하나의 독점적 조사 화면에 의존하지 않고 사고 대응, 규정 준수, 마이그레이션을 위해 계속 접근할 수 있어야 한다.

보안 팀은 가시성을 높이기 위해 새 에이전트 플랫폼에 무제한 접근 권한을 부여하는 일을 피해야 한다. 탐색 아키텍처에도 자체적인 최소 권한 검토가 필요하다.

따라서 시장은 신원을 공유 인프라로 향하고 있다. 승자는 단지 에이전트를 등록하는 데 그치지 않을 것이다.

그들은 플랫폼 전반에서 출처를 유지하고, 상시 자격 증명을 줄이며, 세분화된 권한 철회를 지원하고, 외부 도구가 평가할 수 있는 기록에 정책 결정을 드러낼 것이다.

기업이 에이전트를 확장하기 전에 확인해야 할 사항

다음 단계는 얼마나 많은 공급업체가 “first-class identity”라는 표현을 반복하는지가 아니라, 실제 배포 증거로 평가될 것이다.

첫 번째 신호는 기업이 섀도 에이전트까지 포함한 완전한 인벤토리를 구축하는지 여부다. 공식 온보딩만으로 채워진 디렉터리는 가장 위험한 배포를 놓치게 된다.

조직은 ID 기록을 OAuth 권한 부여, 클라우드 리소스, 브라우저 텔레메트리, API 사용량, SaaS 구성과 비교해야 한다. 큰 격차가 있다면 identity-first 약속은 설득력을 잃을 수 있다.

두 번째 신호는 짧은 수명과 범위가 제한된 권한 부여가 정적 시크릿을 대체하는지 여부다. 신규 에이전트에 최신 토큰을 발급하는 플랫폼의 기능보다, 실제 마이그레이션 수가 더 중요하다.

팀은 내장된 API 키, 공유 서비스 계정, 장기 갱신 토큰을 사용하는 기존 에이전트를 파악해야 한다. 이어 그러한 자격 증명이 얼마나 빠르게 사라지는지 측정해야 한다.

Microsoft의 문서는 기업에 하나의 기술적 기준점을 제공한다. 이 회사의 프로덕션 가이드는 저장된 클라이언트 시크릿보다 페더레이션 자격 증명과 관리형 ID를 선호한다.

세 번째 신호는 런타임 제어가 크로스 플랫폼 위임 상황에서도 유지되는지 여부다. 이는 에이전트 ID가 진정한 인프라가 될지, 아니면 또 하나의 고립된 제품 범주가 될지를 결정할 것이다.

유용한 테스트는 여러 에이전트와 도구를 촉발하는 하나의 사람 요청에서 시작된다. 조사자는 서로 무관한 로그를 수동으로 연계하지 않고도 전체 체인을 재구성할 수 있어야 한다.

기록에는 요청을 시작한 사람, 참여한 모든 에이전트, 각 토큰 교환, 적용된 정책, 영향을 받은 모든 리소스가 식별되어야 한다.

권한 철회도 동일한 체인 전반에서 작동해야 한다. 시작 에이전트를 비활성화했는데도 위임된 자격 증명이나 다운스트림 세션이 활성 상태로 남아 있어서는 안 된다.

기업은 적대적 테스트도 실시해야 한다. 레드팀은 권한을 가진 에이전트가 가져오도록 예상된 콘텐츠 안에 악성 지시문을 삽입할 수 있다.

이 테스트는 모델이 지시문을 받아들인 뒤에도 외부 정책이 위험한 작업을 차단하는지 보여줘야 한다. ID만으로는 그러한 결과를 만들 수 없다.

비즈니스 리더에게는 허용 가능한 자율성을 판단할 의사결정 프레임워크가 필요하다. 결과의 범위가 크게 다르므로 모든 에이전트에 동일한 검토가 필요한 것은 아니다.

공개 문서를 읽는 리서치 어시스턴트는 프로덕션 코드를 수정하는 에이전트와 다른 위험을 수반한다. 매입채무 에이전트는 또 다른 범주를 만든다.

액세스 검토는 이러한 차이를 반영해야 한다. 영향력이 큰 에이전트에는 더 짧은 인증 주기, 더 엄격한 제한, 더 강력한 모니터링, 그리고 명확히 정의된 사람 승인 지점이 필요하다.

사고 대응 계획에는 행위자로서의 에이전트가 포함되어야 한다. 팀은 ID를 중단하고, 토큰을 무효화하며, 커넥터를 격리하고, 로그를 보존하고, 영향을 받은 데이터를 식별하는 방법을 알고 있어야 한다.

계획은 침해된 타사 에이전트도 다뤄야 한다. 기업 내부 코드가 침해되지 않았더라도, 사전에 부여된 OAuth 신뢰는 여전히 위험할 수 있다.

보안팀은 공급업체에 커넥터 침해 사실을 얼마나 신속히 공개하고 발급된 액세스를 철회하는지 물어야 한다. 계약 문구에는 로그, 통지, 조사 지원을 다뤄야 한다.

개발자에게는 설계 단계에서 더 명확한 기준이 필요하다. 모든 신규 에이전트는 소유자, 도구, 데이터 등급, 권한 부여 패턴, 그리고 허용되는 최대 결과 범위를 선언해야 한다.

이 정보는 내부 AI workflow 기록의 일부가 될 수 있다. 이후 제품, 보안, 엔지니어링 팀은 원래 목적을 기준으로 변경 사항을 검토할 수 있다.

Google News 항목은 유용한 점검 지점을 제공하지만, 반복이 해결로 오인되어서는 안 된다. ID 공급업체들은 기업이 해답을 구현한 수준보다 문제를 더 명확히 정의해 왔다.

세 가지 질문은 실용적인 첫 검토를 만든다. 조직은 모든 에이전트를 식별할 수 있는가? 연결 가능한 모든 시스템을 매핑할 수 있는가? 모든 중요한 작업을 제한하고 재구성할 수 있는가?

“예”라는 답에는 디렉터리, 토큰, 정책, 로그의 증거가 필요하다. 감사 목적으로 유지하는 스프레드시트는 런타임 제어를 증명하지 못한다.

하나의 프로덕션 워크플로부터 시작해 사람의 의도에서 최종 효과까지 추적하라. 공유 자격 증명을 제거하고, 모든 연결의 범위를 좁히며, 자동 작업이 멈춰야 하는 지점을 정의하라.

그런 다음 압박 상황에서 권한 철회와 재구성을 테스트하라. 둘 중 하나라도 실패한다면, 해당 에이전트는 조직이 안전하게 설명할 수 있는 수준보다 더 큰 자율성을 갖고 있는 것이다.

Google News는 또 다른 헤드라인으로 옮겨갈 것이다. 기업이 모든 에이전트 작업을 제한된 권한, 명확한 소유권, 집행 가능한 정책과 연결할 수 있게 될 때까지 ID 격차는 남아 있을 것이다.