Agentic AI가 Zero Trust를 정체성 위기에 직면하게 하다

Agentic AI가 강렬한 주장과 함께 Google News에 등장했다. 자율 시스템이 Zero Trust 사이버 보안을 “완전히 뒤집고 있다”는 것이다. 해당 Breaking Defense 헤드라인은 근본적인 세부 내용이 독립적으로 검증되기 어렵다는 점에도 불구하고, 실제 충돌 지점을 짚고 있다. 보안 팀은 사람, 기기, 예측 가능한 애플리케이션을 중심으로 액세스 제어를 구축해 왔다. 이제 AI 에이전트는 위임받은 권한으로 행동하면서 이 세 범주의 경계를 모두 흐리고 있다.

그렇다고 Zero Trust가 시대에 뒤떨어진 것은 아니다. 조직이 무엇을 검증해야 하는지, 얼마나 자주 검증해야 하는지, 그리고 각 작업을 어떤 정체성이 수행했는지가 달라졌다는 뜻이다. 에이전트는 목표를 해석하고, 도구를 선택하며, 외부 콘텐츠를 읽고, API를 호출하고, 데이터를 수정할 수 있다. 그 행동은 인간 소유자에게 할당된 권한만으로는 완전히 포착되지 않는다.

그 결과 불편한 역전이 발생한다. Zero Trust는 모든 요청이 평가를 거쳐야 한다고 전제하지만, agentic 워크플로는 기계 속도로 긴 요청 사슬을 생성한다. 따라서 핵심 경쟁 구도는 agentic AI 대 Zero Trust가 아니다. 정적 액세스 제어와 자율 행동에 대한 지속적 제어의 대립이다.

Google News의 주장은 실제 보안 전환을 가리킨다

중요한 변화는 AI가 엔터프라이즈 시스템에 접근할 수 있다는 사실이 아니라, 접근 권한을 얻은 뒤 무엇을 할지 스스로 결정할 수 있다는 점이다.

전통적인 소프트웨어는 개발자가 미리 정의한 경로를 따른다. 버그를 포함하거나, 악의적인 입력을 받아들이거나, 취약한 인터페이스를 노출할 수 있다. 하지만 방어자는 일반적으로 그 의도된 기능을 확립된 계정, 프로세스, 네트워크 연결에 매핑할 수 있다.

Agentic AI는 사용자의 지시와 그에 따른 행동 사이에 의사결정 계층을 추가한다. 에이전트는 광범위한 목표를 작은 작업으로 나누고, 사용 가능한 도구 중에서 선택하며, 한 경로가 실패하면 적응할 수 있다. NIST는 현대의 에이전트를 범용 모델과, 텍스트 생성 너머에서 도구를 조작할 수 있게 하는 소프트웨어의 결합으로 설명한다.

이러한 도구에는 브라우저, 데이터베이스, 캘린더, 코드 인터프리터, 로컬 파일, 관리 인터페이스가 포함될 수 있다. NIST의 도구 사용 분류 체계는 읽기 전용 접근과 제한적 또는 무제한 쓰기 접근을 구분한다. 또한 신뢰된 환경과 신뢰되지 않은 환경도 분리한다.

이 구분이 중요한 이유는 하나의 에이전트가 단일 작업을 수행하는 동안 여러 범주를 넘나드는 경우가 많기 때문이다. 이메일을 읽고, 고객 번호를 추출하고, 내부 데이터베이스를 조회한 뒤 지원 기록을 업데이트할 수 있다. 각 단계는 개별적으로 검토하면 허용된 것처럼 보일 수 있다.

그러나 결합된 워크플로는 여전히 안전하지 않은 결과를 낳을 수 있다. 공격자는 이메일 안에 숨겨진 지시를 넣을 수 있다. 에이전트는 이를 작업의 일부로 해석한 뒤, 합법적인 권한을 사용해 데이터를 유출할 수 있다.

이 공격은 간접 프롬프트 인젝션이라고 하며, 악의적인 지시가 에이전트가 처리하는 콘텐츠를 통해 도달하는 것을 의미한다. 공격자는 직원의 비밀번호를 알 필요가 없다. 대신 신뢰된 정보와 신뢰되지 않은 정보를 해석하는 에이전트의 방식을 노린다.

Google News 헤드라인은 “완전히 뒤집고 있다”는 표현을 통해 이 변화를 포착한다. 이전에는 보안 팀이 사람이 소프트웨어를 오용하거나 자격 증명을 넘겨줄 것을 우려했다. 이제는 사람의 권한을 해석하고 그 범위 안에서 독립적으로 행동하는 소프트웨어도 고려해야 한다.

이는 단순히 네트워크에 추가되는 또 하나의 엔드포인트가 아니다. 엔드포인트는 일반적으로 비교적 안정적인 기능, 상태, 소유 모델을 가진다. 반면 에이전트는 동일한 정체성, 자격 증명, 연결을 유지하면서도 즉각적인 계획을 바꿀 수 있다.

이는 가시성 문제를 만든다. 로그에는 유효한 서비스 계정이 데이터베이스에 접근한 사실이 표시될 수 있다. 하지만 어떤 사용자가 작업을 시작했는지, 어떤 에이전트가 계획을 세웠는지, 어떤 외부 입력이 그 결정에 영향을 미쳤는지는 드러나지 않을 수 있다.

이 헤드라인은 여전히 특정 침해 사고의 증거가 아니라 하나의 논지로 다뤄야 한다. 제공된 Google News 항목에는 검증된 사고 세부 정보가 수반되지 않는다. 다만 더 광범위한 보안 문제는 공개 연구와 현재 진행 중인 표준 작업으로 뒷받침된다.

보안 팀은 더 이상 사람-애플리케이션 및 애플리케이션-애플리케이션 접근만 보호하는 것이 아니다. 사람, 에이전트, 모델, 여러 도구, 다수의 데이터 소스를 연결하는 사슬을 보호해야 한다. 신뢰는 모든 인계 지점에서 새어 나갈 수 있다.

Zero Trust는 요청을 위해 설계됐지, 열린 목표를 위해 설계된 것은 아니다

Zero Trust는 여전히 유효하지만, 기존의 제어 단위는 자율적 작업을 다루기에는 지나치게 좁다.

NIST는 2020년에 핵심 Zero Trust 아키텍처를 발표했다. 이 모델은 네트워크 위치나 자산 소유권에 근거한 암묵적 신뢰를 거부한다. 인증과 권한 부여는 세션이 엔터프라이즈 리소스에 도달하기 전에 이뤄진다.

이 아키텍처는 전통적인 네트워크 세그먼트가 아니라 리소스에 초점을 맞춘다. 네트워크가 이미 침해됐을 수 있다고 가정한다. 따라서 접근은 특정 임무에 필요한 최소 권한 집합으로 제한돼야 한다.

이 접근 방식은 기존의 경계 모델에 대응한다. 경계 보안에서는 인증된 사용자가 신뢰된 네트워크에 들어온 뒤 광범위한 접근 권한을 받는 경우가 많았다. 공격자는 하나의 계정이나 기기를 침해한 뒤 시스템 간 수평 이동을 할 수 있었다.

Agentic AI는 이러한 원칙을 무효화하지 않는다. 오히려 기계가 많은 작업을 빠르게 수행할 수 있게 되면서 최소 권한과 지속적 평가는 더 중요해진다. 어려움은 광범위한 사용자 목표를 집행 가능한 단기 권한으로 변환하는 데 있다.

분기별 고객 위험 보고서를 작성하라는 지시를 받은 에이전트를 생각해 보자. 이 작업은 정보 제공처럼 들리지만, 완료하려면 여러 기능이 필요할 수 있다. 에이전트는 기록을 찾고, 데이터를 결합하고, 추세를 계산하고, 문서를 생성해야 한다.

에이전트가 작업 전체 기간 동안 모든 고객 기록에 접근할 수 있어야 할까? 이후에도 그 권한을 유지해야 할까? 보고서를 이메일로 보낼 수 있어야 할까, 아니면 배포에는 별도 승인이 필요할까?

기존 액세스 시스템은 사용자의 기존 역할을 통해 이러한 질문에 답할 수 있다. 직원이 데이터베이스를 읽고 이메일을 보낼 수 있다면, 에이전트는 두 권한을 모두 상속받는다. 이 상속은 단순하지만 과도한 권한을 만든다.

에이전트는 직원이 한 번도 의도하지 않은 행동 조합을 수행할 수 있다. 또한 수동 워크플로에서는 좀처럼 도달하지 않는 규모로 이를 반복할 수 있다. 작은 해석 오류가 수백 건의 데이터베이스 쿼리나 메시지로 확대될 수 있다.

열린 목표는 정책 설계를 더 어렵게 만든다. “관련 증거를 찾아라”는 어떤 저장소를 검색해야 하는지 명시하지 않는다. “문제를 해결하라”는 에이전트가 환불을 처리하거나, 계정을 수정하거나, 코드를 실행할 수 있는지를 정의하지 않는다.

Zero Trust는 전통적으로 정체성, 기기 상태, 리소스 민감도, 환경적 맥락을 사용해 액세스 요청을 평가한다. Agentic 시스템은 또 다른 질문을 더한다. 이 행동은 접근을 정당화한 작업과 여전히 일치하는가?

이 질문에는 의도 인식 제어가 필요하다. 이러한 제어는 행동을 에이전트의 할당된 목적, 현재 계획, 승인된 정책과 비교한다. 단순히 계정이 기술적으로 권한을 보유하는지에만 의존할 수 없다.

다중 에이전트 작업에서는 보안 경계도 이동한다. 한 에이전트가 다른 에이전트에게 조사를 위임할 수 있다. 두 번째 에이전트는 새 지시가 포함된 콘텐츠를 반환하는 타사 서비스를 호출할 수 있다.

각 인계는 겉보기 권한 부여를 유지하면서도 맥락을 바꿀 수 있다. 정적 정책은 승인된 정체성이 데이터를 전달하는 것으로 본다. 행동 정책은 전체 사슬이 여전히 원래 목표에 부합하는지 판단해야 한다.

이 때문에 agentic AI 보안은 네트워크 세분화에서 멈출 수 없다. 제어 평면은 정체성, 작업, 도구, 데이터 계보, 행동 이력을 이해해야 한다. 또한 이후 조사를 위해 이 관계들을 보존해야 한다.

Zero Trust의 원래 약속은 여전히 유효하다. 무언가가 이미 내부에 있다는 이유만으로 신뢰를 부여해서는 안 된다. Agentic 워크플로는 단지 “내부”가 컨텍스트 윈도우, 위임된 작업, 도구 체인을 뜻할 수 있음을 드러낸다. 이는 더 이상 네트워크만을 가리키지 않는다.

AI 에이전트에는 소유자와 분리된 정체성이 필요하다

모든 행동이 사람 또는 공유 서비스 계정으로 나타난다면 조직은 자율 에이전트를 관리할 수 없다.

정체성은 엔터프라이즈 보안 팀이 처음 마주하는 압박 지점이다. 사람에게는 고용 기록, 관리자, 직무 역할, 퇴사 절차가 있다. 애플리케이션에는 소유자, 릴리스 프로세스, 서비스 계정이 있다.

에이전트는 두 그룹의 특성을 결합한다. 사람에게서 목표를 받을 수 있지만, 소프트웨어를 통해 실행한다. 하나의 작업을 위해 잠시 작동할 수도 있고, 지속적으로 실행되는 디지털 작업자로 남을 수도 있다.

에이전트를 애플리케이션 내부의 숨겨진 기능으로 취급하면 책임 소재가 흐려진다. 일반 직원처럼 취급하는 것 역시 잘못된 확신을 만든다. 에이전트에는 소유자, 목적, 배포와 연결된 일급 머신 정체성이 필요하다.

그 정체성은 작업을 시작한 사용자의 정체성을 대체해서는 안 된다. 두 정체성 모두 워크플로 전반에 걸쳐 유지돼야 한다. 조사 담당자는 누가 행동을 요청했고 어떤 에이전트가 이를 실행했는지 알아야 한다.

유용한 감사 기록은 관련된 모델, 도구, 정책, 데이터 소스도 포착해야 한다. 이런 맥락이 없다면 데이터베이스 로그에는 최종 접근만 표시된다. 에이전트가 왜 해당 접근이 적절하다고 판단했는지는 설명할 수 없다.

보안 팀은 에이전트 배포에 공유 자격 증명을 사용하지 않아야 한다. 공유 계정은 신뢰할 수 있는 추적을 막고 권한 회수를 복잡하게 만든다. 또한 원래 프로젝트가 끝난 뒤에도 방치된 에이전트가 활성 상태로 남게 할 수 있다.

에이전트 정체성에는 수명 주기가 필요하다. 생성 시에는 책임 소유자와 승인된 사용 목적을 식별해야 한다. 정기 검토를 통해 에이전트가 여전히 필요한지, 권한이 여전히 목적에 맞는지 확인해야 한다.

만료 역시 중요하다. 임시 에이전트는 작업이나 프로젝트가 끝나면 접근 권한을 잃어야 한다. 지속형 에이전트는 권한이 있는 사람 계정과 마찬가지로 정기적인 재인증을 거쳐야 한다.

권한도 작업별이며 단기적이어야 한다. 보고서를 작성하는 에이전트는 선택된 기록에 대한 임시 읽기 권한을 받을 수 있다. 해당 보고서를 조직 외부로 보내려면 별도 권한이나 사람의 확인이 필요해야 한다.

이 설계는 정체성이 더 이상 책임과 맞지 않는 접근 권한을 축적할 때 발생하는 권한 확산을 줄인다. 권한 확산은 이미 직원 환경에서도 다루기 어렵다. 자율 에이전트는 팀이 빠르게 만들 수 있기 때문에 이 문제를 증폭시킬 수 있다.

따라서 에이전트 발견은 운영상의 필수 요건이 된다. 보안 팀은 SaaS 서비스, 개발 플랫폼, 내부 자동화 시스템, 타사 통합 전반에 걸친 인벤토리가 필요하다. 조달 기록만으로는 기존 제품 내부에서 생성된 에이전트를 식별할 수 없다.

발견 과정은 AI 기능과 행동하는 정체성을 구분해야 한다. 하나의 문서만 읽는 요약 기능은 드라이브를 검색하고 메시지를 보낼 수 있는 에이전트와 다른 위험을 수반한다. 둘 다 동일한 모델을 사용할 수 있다.

소유자 역시 정책과 로그에 표시돼야 한다. 에이전트가 기대를 벗어나 행동할 때 대응 담당자는 이를 중지할 수 있는 사람 또는 팀이 필요하다. 익명 자동화는 사고 대응을 지연시킨다.

조직은 이미 서비스, 워크로드, 기계에 비인간 정체성을 사용하고 있다. 에이전트 정체성은 이러한 체계를 대체하는 것이 아니라 확장한다. 차이는 정책이 같은 할당 역할 내에서도 가변적인 행동을 고려해야 한다는 점이다.

주요 보안 벤더들은 이 방향으로 움직이고 있다. Cisco는 자사의 에이전트 보안 업데이트에서 에이전트 검색, 에이전틱 아이덴티티 제어, Model Context Protocol 집행을 발표했다. Model Context Protocol, 즉 MCP는 모델을 도구 및 외부 데이터와 연결한다.

벤더 발표가 모든 배포 환경에서 이러한 제어가 작동한다는 독립적 증거는 아니다. 다만 경쟁이 향하는 방향은 보여준다. 아이덴티티 플랫폼, 액세스 브로커, 보안 게이트웨이 모두 에이전트 트래픽의 제어 지점이 되기를 원한다.

기업 구매자는 하나의 게이트웨이를 완전한 솔루션으로 간주해서는 안 된다. NIST는 오래전부터 단일 벤더가 전체 Zero Trust 아키텍처를 제공하지는 않는다고 지적해 왔다. 에이전틱 보안은 구성 요소와 일관성 없는 집행이 발생할 가능성을 더한다.

가장 즉각적인 압박은 아이덴티티 및 액세스 관리 팀에 가해진다. 이들은 관리되지 않는 서비스 계정 문제를 되풀이하지 않으면서도 빠르게 생성되는 머신 액터를 지원해야 한다. 정적인 역할 할당만으로는 충분하지 않다.

에이전트 하이재킹은 정적 권한 검사의 한계를 드러낸다

인증을 올바르게 통과한 에이전트도 잘못된 작업을 수행할 수 있다. 인증은 그 추론의 타당성까지 검증하지 않기 때문이다.

Zero Trust를 재설계해야 한다는 가장 강력한 근거는 에이전트 하이재킹 연구에서 나온다. 2026년 3월, NIST는 13개 프런티어 모델을 대상으로 한 대규모 공개 레드팀 경쟁의 결과를 보고했다. 400명 이상의 참가자가 25만 건이 넘는 공격을 시도했다.

시험된 모든 모델에서 최소 한 건의 성공적인 하이재킹 공격이 발견됐다. 모델별 저항성에는 차이가 있었지만, 역량이 보안을 일관되게 예측하지는 못했다. 일부 공격 계열은 서로 다른 모델과 시나리오에서도 전이됐다.

이 결과가 배포된 모든 에이전트가 쉽게 침해된다는 뜻은 아니다. 경쟁 환경은 집중된 공격자를 유도하며, 모든 프로덕션 제어를 재현하지 못할 수 있다. 하지만 모델 수준의 저항성만으로는 보안 경계 역할을 할 수 없다는 점은 분명히 보여준다.

NIST는 에이전트 하이재킹을 에이전트가 처리하는 데이터 안에 악의적인 지시를 삽입하는 공격으로 정의한다. 목적은 에이전트를 유해한 행동으로 유도하는 것이다. 가능한 결과로는 데이터 유출이나 악성 코드 실행이 있다.

핵심은 에이전트가 흔히 유효한 도구와 자격 증명을 사용한다는 점이다. 방화벽에는 승인된 연결로 보일 수 있다. 아이덴티티 시스템에는 인증된 계정으로 보일 수 있다. 위험한 단계는 에이전트가 콘텐츠를 해석하는 과정에서 발생한다.

따라서 정적 허용 목록만으로는 불완전하다. 에이전트가 업무를 위해 이메일을 읽고 데이터베이스를 업데이트할 수 있도록 허용해야 할 수 있다. 그렇더라도 정책은 이메일이 데이터베이스 도구의 동작을 재정의하지 못하도록 막아야 한다.

관련 레드팀 결과는 심층 방어를 뒷받침한다. 모델 평가가 필요하지만, 배포 환경에는 제한된 도구, 데이터 경계, 모니터링, 승인 지점도 필요하다.

도구 권한은 편의성이 아니라 결과의 중대성을 반영해야 한다. 공개 웹페이지를 읽는 일은 내려받은 코드를 실행하는 일과 위험이 다르다. 고객 레코드를 조회하는 것과 이를 삭제하거나 내보내는 것도 다르다.

영향이 큰 도구는 제한된 작업만 노출해야 한다. 회의 일정을 잡아야 하는 에이전트에 무제한 사서함 제어 권한을 부여해서는 안 된다. 결제를 작성하는 재무 에이전트가 결제를 승인하고 전송하는 권한까지 가져서도 안 된다.

이 원칙을 직무 분리라고 한다. 민감한 프로세스의 모든 단계를 하나의 아이덴티티가 통제하지 못하도록 막는다. 자동화로 통합하고 싶은 유혹이 있더라도 에이전틱 시스템에도 같은 분리가 필요하다.

되돌릴 수 없는 경계에서는 사람의 승인이 여전히 유용하다. 이체, 삭제, 외부 게시, 프로덕션 배포, 자격 증명 변경에는 명시적 검사가 필요하다. 승인 화면에는 의도한 작업과 관련 맥락이 표시돼야 한다.

일반적인 “허용” 버튼은 보호 효과가 거의 없다. 검토자는 어떤 에이전트가 작업을 요청했는지, 어떤 데이터를 사용했는지, 승인 시 어떤 결과가 발생하는지 알아야 한다. 그렇지 않으면 자동화는 소셜 엔지니어링을 승인 화면으로 옮길 뿐이다.

모니터링은 행동 변화에 초점을 맞춰야 한다. 에이전트가 갑자기 익숙하지 않은 리포지터리에 접근한다면 하이재킹이나 잘못된 계획 수립을 의미할 수 있다. 반복적인 도구 호출 실패는 에이전트가 자신의 역할 범위를 넘어 탐색하고 있다는 신호일 수 있다.

속도 제한도 실수로 인한 피해를 줄인다. 머신 속도의 실행은 하나의 잘못된 판단을 광범위한 사고로 키울 수 있다. 작업량을 제한하면 모니터링 시스템과 대응 인력이 개입할 시간을 확보할 수 있다.

샌드박싱은 여전히 가치가 있지만, 안전하다는 가정을 만들어서는 안 된다. 에이전트는 런타임을 벗어나지 않고도 피해를 일으킬 수 있다. 권한이 있는 데이터를 잘못된 목적지로 보내는 데 소프트웨어 익스플로잇은 필요하지 않을 수 있다.

핵심 불확실성은 의도 인식 시스템이 유용한 업무를 차단하지 않으면서 신뢰할 만한 결정을 내릴 수 있는지다. 에이전트의 계획은 변하고, 비즈니스 업무에는 모호성이 있으며, 정책은 모든 정당한 예외를 예상할 수 없다.

지나치게 엄격한 제어는 끊임없는 승인 요청을 낳는다. 그러면 팀은 생산성을 회복하기 위해 더 넓은 권한을 부여할 수 있다. 이는 Zero Trust가 제거하려 했던 바로 그 암묵적 신뢰를 다시 만들어낸다.

지나치게 관대한 제어는 반대의 실패를 낳는다. 악의적인 입력이나 계획 오류가 권한을 악용하기 전까지 에이전트는 매끄럽게 작동한다. 보안 팀은 차단된 업무와 안전하지 않은 작업을 모두 측정해야 한다.

이러한 트레이드오프는 “에이전틱 Zero Trust” 제품이 문제를 해결했다는 단순한 주장을 막는다. 제품 데모는 대개 선별된 워크플로를 보여준다. 실제 배포 환경에는 레거시 시스템, 공유 아이덴티티, 일관성 없는 로그가 존재한다.

가장 신뢰할 만한 단기 접근법은 계층형이다. 각 에이전트에 아이덴티티를 부여하고, 각 도구를 제한하며, 작업을 시작한 사용자를 보존하고, 중대한 작업을 검증하고, 행동을 모니터링해야 한다. 모델 보호 장치는 때때로 실패할 수 있다고 가정해야 한다.

경쟁의 전선은 제어 플레인으로 이동하고 있다

보안 벤더들은 에이전트 행동을 중재하기 위해 경쟁하고 있지만, 기업에는 이 중재의 효과를 입증할 공통 모델이 아직 부족하다.

에이전틱 AI는 아이덴티티 제공업체, 네트워크 보안 벤더, 클라우드 플랫폼, 전문 AI 보안 기업에 기회를 만든다. 각 그룹은 워크플로의 서로 다른 부분을 통제한다. 어느 쪽도 전체 체인을 자동으로 볼 수는 없다.

아이덴티티 벤더는 누가 액세스를 받았는지 안다. 네트워크 플랫폼은 시스템 간 연결을 관찰한다. 클라우드 제공업체는 워크로드와 API 호출을 모니터링할 수 있다. AI 보안 도구는 프롬프트, 모델 출력, 도구 요청을 검사한다.

가장 가치 있는 위치는 정책 결정 지점이다. Zero Trust 아키텍처에서 이 구성 요소는 액세스를 평가하고 집행이 이를 허용해야 하는지 결정한다. 에이전틱 시스템은 이 결정을 더 풍부하고 더 논쟁적인 것으로 만든다.

네트워크 벤더는 에이전트 통신이 보안 브로커를 거쳐야 한다고 주장할 수 있다. 아이덴티티 벤더는 머신 아이덴티티와 위임된 권한 부여를 정책의 중심에 둘 수 있다. AI 보안 제공업체는 프롬프트 검사와 행동 평가를 우선시할 수 있다.

세 관점 모두 답의 일부를 담고 있다. 네트워크 맥락만으로는 모든 악의적 지시를 드러낼 수 없다. 프롬프트 검사만으로는 차단된 데이터베이스 쿼리를 직접 집행할 수 없다. 아이덴티티 검증만으로는 인증된 에이전트가 목적을 따른다고 보장할 수 없다.

MCP는 모델과 도구 간 연결을 표준화하기 때문에 하나의 초점이 됐다. 게이트웨이는 서버를 인벤토리화하고, 작업을 제한하며, 호출을 기록할 수 있다. 그러나 모든 에이전트가 MCP를 사용하지는 않으며, 게이트웨이는 이를 우회하는 도구를 통제할 수 없다.

에이전트 간 통신은 또 다른 과제를 제시한다. 위임은 모델, 벤더 또는 조직 경계를 넘을 수 있다. 수신 에이전트는 발신자의 아이덴티티, 권한, 요청된 범위에 관한 증거가 필요하다.

서명된 메시지는 발신자를 인증할 수 있다. 하지만 발신자의 계획이 안전하다는 사실까지 입증하지는 않는다. 정책은 요청의 출처를 식별하는 프로비넌스와, 요청을 진행해야 하는지를 결정하는 권한 부여를 분리해야 한다.

표준화 작업은 이러한 격차를 다루기 시작하고 있다. NIST는 2026년 2월 에이전트 표준 이니셔티브를 시작했다. 이 의제에는 상호운용성, 오픈 프로토콜, 보안, 아이덴티티, 신뢰할 수 있는 도입이 포함된다.

이 이니셔티브가 중요한 이유는 조직이 에이전트 아이덴티티와 권한을 비교 가능한 방식으로 표현해야 하기 때문이다. 공통 형식이 없으면 각 플랫폼은 독점적인 아이덴티티와 정책 신호를 만든다. 그러면 보안 팀은 환경 전반에서 제어를 집행하기 어려워진다.

표준만으로 위험 허용 수준을 정할 수는 없다. 병원, 은행, 방산 계약업체, 마케팅 에이전시는 동일한 도구 작업에 서로 다른 결과를 부여할 것이다. 상호운용성은 공통 기반을 제공할 뿐, 보편적 정책을 제공하지는 않는다.

Breaking Defense의 관점은 고보증 환경에 특히 관련성이 크다. 방위 시스템은 기밀 데이터, 임무 제약, 레거시 장비, 엄격한 책임성을 함께 갖는 경우가 많다. 자율적 작업은 일반적인 사무 자동화를 넘어서는 결과를 초래할 수 있다.

이러한 환경은 자동화에 대한 압박도 만든다. 분석가는 대량의 경보, 문서, 센서 데이터를 마주한다. 에이전트는 정보를 연관 짓고 반복적인 단계를 실행하는 데 도움이 될 수 있지만, 자율성이 커질수록 추적 가능한 제어의 필요성도 커진다.

따라서 경쟁은 제품 용어가 아니라 증거를 통해 평가해야 한다. 구매자는 제어가 에이전트를 신뢰성 있게 식별하고, 작업을 소유자에게 연결하며, 도구를 제한하고, 활용 가능한 감사 기록을 생성하는지 테스트해야 한다.

실패 사례도 테스트해야 한다. 아이덴티티 제공업체를 사용할 수 없을 때는 어떻게 되는가? 에이전트가 캐시된 권한으로 대체 작동할 수 있는가? 브로커는 폐쇄 실패하는가, 아니면 트래픽이 검사를 우회하는가?

개별 기능만큼 크로스플랫폼 커버리지도 중요하다. 조직은 한 클라우드 모델, 다른 벤더의 코딩 에이전트, 여러 SaaS 어시스턴트를 사용할 수 있다. 하나의 환경만 보는 제어에는 상당한 사각지대가 남는다.

시장은 통합 플랫폼을 중심으로 통합될 가능성이 높지만, 통합은 그 자체로 집중 위험을 만들 수 있다. 하나의 손상된 정책 플레인이 많은 에이전트에 영향을 미칠 수 있다. 독립적인 로깅과 집행은 여전히 중요한 안전장치다.

Google News는 에이전틱 AI가 익숙한 보안 모델을 대체한다는 헤드라인을 증폭시킬 수 있다. 더 정확한 결론은 더 좁다. 기존 벤더는 Zero Trust를 연결 결정에서 아이덴티티, 의도, 작업 거버넌스로 확장해야 한다.

보안 팀이 다음으로 주시해야 할 것

다음 단계는 자율 보안에 대한 더 광범위한 주장보다 측정 가능한 배포 증거에 의해 결정될 것이다.

첫 번째 신호는 표준화 그룹이 에이전트 아이덴티티와 위임된 권한 부여를 위한 활용 가능한 명세를 만드는지 여부다. NIST는 이 이니셔티브가 연구, 가이드라인, 기타 산출물을 개발할 것이라고 밝혔다. 기업은 벤더 간에도 유지되는 형식을 주시해야 한다.

유용한 아이덴티티 명세는 에이전트를 소유자, 목적, 모델, 승인된 도구에 연결해야 한다. 또한 위임 과정에서 작업을 시작한 사용자를 보존해야 한다. 플랫폼이 호환되지 않는 표현을 채택한다면 거버넌스는 계속 파편화될 것이다.

두 번째 신호는 독립적인 보안 테스트다. NIST의 경쟁에서는 시험된 모든 프런티어 모델에 대한 성공적 공격이 발견됐지만, 조직에는 배포 수준의 평가가 필요하다. 테스트에는 모델, 도구, 권한, 메모리, 외부 데이터가 포함돼야 한다.

비교 테스트는 프롬프트 인젝션 성공 여부 이상을 측정해야 한다. 에이전트가 작업 범위를 초과하는지, 정당한 도구를 오용하는지, 긴 워크플로 안에 중대한 작업을 숨기는지 살펴봐야 한다. 복구 역량과 감사 품질도 테스트해야 한다.

유용한 기능을 유지한 채 공격 성공률이 떨어진다면, 의도를 인식하는 제어에 대한 신뢰는 강화될 것이다. 개선된 모델이 도구가 풍부한 배포 환경 전반에서 여전히 취약하다면, 인프라 제어는 더욱 중요해질 것이다.

세 번째 신호는 파일럿 이후의 기업 행동이다. 보안팀은 고유한 ID, 제한된 자격 증명, 명확한 책임자를 부여받는 에이전트의 수를 추적해야 한다. 또한 방치된 에이전트와 검토되지 않은 권한도 측정해야 한다.

도입 수치만으로는 거의 알 수 없다. 기업은 수천 개의 에이전트를 배포하면서도 이를 읽기 전용으로 유지하고 격리할 수 있다. 광범위한 프로덕션 접근 권한을 가진 단 하나의 에이전트가 그 전체 집단보다 더 큰 위험을 초래할 수 있다.

사고 보고서는 또 하나의 현실 점검 수단이 될 것이다. 공개 사례는 실패가 프롬프트 인젝션, 과도한 권한, ID 혼동, 또는 승인 경계 부재 중 무엇에서 비롯됐는지 설명해야 한다. 이러한 세부 정보가 없다면 업계는 방어책을 비교할 수 없다.

보안 리더는 파일럿을 확대하기 전에 직접적인 질문을 던져야 한다:

• 모든 에이전트에 고유한 ID와 책임 소재가 명확한 소유자가 있는가?

• 작업이 끝나면 권한이 자동으로 만료될 수 있는가?

• 로그에 요청한 사람과 실제로 행동한 에이전트가 모두 보존되는가?

• 되돌릴 수 없는 변경을 생성할 수 있는 도구는 무엇인가?

• 외부 콘텐츠가 그러한 도구 호출에 영향을 줄 수 있는가?

• 어느 정도의 작업량에서 검토 또는 중지가 실행되는가?

• 대응 담당자는 전체 플랫폼을 중단하지 않고 단일 에이전트만 비활성화할 수 있는가?

• 위임된 에이전트는 원래 작업의 제약을 받는가?

• 정책 서비스가 사용할 수 없을 때 시스템은 기본 거부 방식으로 실패하는가?

• 감사자는 민감한 작업이 발생한 이유를 재구성할 수 있는가?

이 질문들은 “완전히 뒤집었다”는 주장을 구현 테스트로 바꾼다. 플랫폼이 이에 답할 수 없다면, 그 플랫폼의 Zero Trust 언어는 불완전한 상태다. 답할 수 있다면 아키텍처는 이미 적응하고 있을 수 있다.

가장 중요한 결론은 조직이 Zero Trust를 포기해서는 안 된다는 점이다. 대신 더 작고 더 역동적인 권한 단위에 이를 적용해야 한다. 모든 에이전트, 도구 호출, 위임, 그리고 중요한 결과를 낳는 작업에는 각각의 정책 맥락이 필요하다.

이 접근 방식은 마찰을 유발할 것이다. 일부 자동화 작업에는 더 제한적인 도구나 사람의 확인이 필요할 것이다. 팀이 인벤토리와 수명주기 제어를 구축하는 동안 일부 파일럿은 느려질 것이다.

대안은 숨겨진 권한이다. 에이전트는 광범위한 인간 권한을 상속하고, 신뢰할 수 없는 콘텐츠를 처리하며, 불완전한 기록을 남길 것이다. 그러면 보안팀은 사고가 발생한 뒤에야 자율 워크플로를 발견하게 된다.

Agentic AI는 Zero Trust를 무너뜨리지 않았다. 대신 많은 Zero Trust 프로그램이 인증, 네트워크 접근, 또는 기기 상태에서 멈췄던 지점을 드러냈다. 다음 버전은 인증된 기계가 무엇을 하기로 결정하는지까지 관리해야 한다.

따라서 Google News를 통해 제기된 질문은, 제목이 그 반전을 과장하더라도 계속 유지할 가치가 있다. 조직은 에이전트의 다음 작업이 실행되기 전에 그 ID, 목적, 근거, 권한을 추적할 수 있는가?

프로덕션 워크플로 하나부터 시작해 그 사슬을 처음부터 끝까지 재구성하라. 어느 인계 단계든 보이지 않게 된다면 이를 제어 공백으로 간주하라. 이 실습은 또 하나의 보안 라벨을 도입하는 것보다 더 큰 가치를 제공한다. Zero Trust가 실제 업무 전반에서 에이전트를 따라가는지 검증하기 때문이다.