AI Agent 내부자 위협, 보안의 중심을 신뢰된 접근으로 옮기다

AI agent는 중요한 경계를 넘어섰다. 이제 이들은 지속적인 감독 없이도 신뢰된 자격 증명을 사용해 데이터를 읽고, 도구를 호출하며, 기업 시스템을 변경할 수 있다.

이러한 변화로 AI agent 내부자 위협은 모델 안전성 문제가 아니라 접근 제어 문제가 되었다. agent가 레코드를 노출하고, 무단 메시지를 보내거나, 안전하지 않은 워크플로를 실행하기 위해 악의적인 의도를 가질 필요는 없다. 정당한 권한과 유해한 지시, 그리고 행동할 만큼의 자율성만 있으면 된다.

최근 Cybersecurity Insiders의 주장은 이러한 전환을 잘 보여준다. 기업들은 한때 AI를 외부 공격자로부터 보호해야 하는 소프트웨어로 여겼다. 이제 보안 팀은 그 소프트웨어 자체가 신뢰할 수 있지만 안전하지 않은 운영자가 될 수 있는지를 고려해야 한다.

이는 모든 agent를 적대적 존재로 분류해야 한다는 뜻은 아니다. 조직은 더 이상 인증이 어떤 행동의 안전성을 증명한다고 볼 수 없다는 의미다. 유효한 ID는 누가 또는 무엇이 접근을 요청했는지를 알려준다. 하지만 요청된 행동이 사용자의 실제 의도와 일치하는지는 증명하지 못한다.

따라서 새롭게 부상하는 대립 구도는 인간 대 기계가 아니다. 광범위하고 지속적인 접근과 제한적이며 작업별로 구체화된 권한 부여 간의 대립이다. 보안 팀은 agent가 직원과 기존 애플리케이션을 위해 구축된 느슨한 접근 패턴을 그대로 상속받아도 되는지 결정해야 한다.

그 답은 agent 도입이 통제된 자동화로 이어질지, 아니면 탐지하기 어려운 새로운 유형의 내부자 사고를 낳을지를 결정하게 된다.

AI Agent 내부자 위협은 정당한 접근에서 시작된다

핵심 위험은 AI agent가 경계를 돌파하는 데 있지 않다. 기업이 의도적으로 부여한 접근 권한을 통해 행동한다는 데 있다.

전통적인 내부자 위험 프로그램은 직원, 계약자, 그리고 탈취된 계정을 중점적으로 다룬다. 이들은 이미 신뢰 경계 내부에 있다. 외부에 노출된 취약점을 악용하지 않고도 데이터나 시스템을 오용할 수 있다.

agent는 놀랄 만큼 이 모델에 잘 들어맞는다. OAuth 권한 부여, 서비스 ID, API 접근, 데이터베이스 권한, 위임된 권한을 보유할 수 있다. 또한 여러 단계로 구성된 워크플로에서 이러한 권한을 결합할 수도 있다.

영업 브리핑을 준비하도록 배정된 agent는 고객 레코드를 검색하고, 내부 메모를 가져오고, 이메일 초안을 작성할 수 있다. 코딩 agent는 리포지토리를 읽고, 터미널을 열고, 파일을 수정한 뒤 pull request를 제출할 수 있다. 지원 agent는 계정 정보를 조회하고 환불을 시작할 수 있다.

개별 권한은 각각 합리적으로 보일 수 있다. 위험한 역량은 agent가 이를 예상치 못한 순서로 연결할 때 나타난다.

이는 agent와 기존 애플리케이션 사이의 근본적인 차이다. 전통적인 소프트웨어는 일반적으로 미리 정해진 경로를 따른다. agent는 목표를 해석하고, 도구를 선택하며, 실행 중에 중간 단계를 결정한다.

이러한 유연성은 가치를 창출하지만, 기존 제어 체계에 내재된 가정도 약화시킨다. 하나의 의도된 워크플로를 위해 부여된 권한이 여러 의도하지 않은 워크플로를 지원할 수 있다. agent는 인간 운영자보다 더 빠르게 그러한 경로를 발견할 수 있다.

Prompt injection은 문제를 더욱 심각하게 만든다. Prompt injection은 AI 시스템이 읽는 데이터 안에 기만적인 지시를 삽입하는 공격이다. agent는 그러한 지시를 자신에게 할당된 작업의 일부로 오인할 수 있다.

외부 폴더의 문서를 검토하는 assistant를 상상해 보자. 문서에는 assistant에게 기밀 파일을 가져와 그 내용을 다른 곳으로 보내라고 지시하는 숨겨진 텍스트가 포함되어 있다. 두 행동 모두 승인된 도구를 사용하므로 agent는 이를 따를 수 있다.

시스템에는 성공적인 로그인, 유효한 토큰, 허용된 API 호출이 기록될 수 있다. 기존 모니터링은 이를 승인된 활동으로 본다. 기업은 데이터 유출을 보게 된다.

OWASP의 agentic threat guidance는 자율적 계획 수립, 도구 사용, 메모리, 그리고 agent 간 상호작용에서 발생하는 위험을 식별한다. 이는 고립된 모델 동작이 아니다. 모델과 권한을 결합하면서 만들어지는 시스템 수준의 위험이다.

agent가 부정확하게 정의된 목표를 받을 때도 같은 문제가 발생한다. “기한이 지난 모든 요청을 해결하라”는 지시는 메시지 전송, 레코드 변경, 또는 사람의 검토가 필요했던 사례의 종결로 이어질 수 있다. 먼저 모델을 침해할 필요조차 없다.

그렇기 때문에 의도는 ID만큼 중요하다. 안전한 설계는 누가 작업을 승인했는지, 어떤 리소스가 대상인지, 어떤 행동이 허용되는지, 그리고 그 권한이 언제까지 유효한지를 판단해야 한다.

이러한 경계가 없다면 인증된 agent는 유난히 빠른 운영 속도를 가진 내부자가 된다.

신뢰된 접근이 새로운 보안 경계가 되고 있다

AI agent는 정당한 업무가 이미 애플리케이션, 클라우드, 데이터 저장소를 아우르기 때문에 네트워크 위치보다 신뢰된 접근을 더 중요하게 만든다.

Zero trust 아키텍처는 이러한 변화의 일부를 이미 예견했다. NIST의 zero trust standard는 네트워크 위치나 자산 소유권만을 근거로 한 암묵적 신뢰를 거부한다. 대신 사용자, 자산, 리소스, 그리고 명시적 권한 부여를 중심에 둔다.

접근을 요청하는 주체가 자율 시스템일 때 이 모델은 더욱 시급해진다. agent는 과거에는 인간 내부자의 속도를 늦췄던 경계를 넘나들며 작동할 수 있다. 기기를 바꾸거나, 여러 인터페이스를 열거나, 애플리케이션 사이에서 데이터를 수동으로 복사할 필요가 없다.

하나의 지시가 연쇄적인 도구 호출을 촉발할 수 있다. 그 연쇄는 메시징 플랫폼에서 클라우드 스토리지로, 다시 고객 데이터베이스와 외부 서비스로 이어질 수 있다. agent는 신뢰된 통합을 통해 이 순서를 수행한다.

네트워크 방화벽은 허용된 연결을 확인한다. ID 시스템은 인식된 자격 증명을 확인한다. 애플리케이션 로그에는 할당된 계정이 수행하도록 허용된 작업이 표시된다.

하지만 결합된 결과는 여전히 정책을 위반할 수 있다.

따라서 보안은 각각의 행동에 더 가까이 다가가야 한다. 권한 부여는 agent의 ID, 소유자, 현재 작업, 요청 리소스, 사용 중인 도구, 그리고 주변 위험 신호를 고려해야 한다.

이를 위해 배포된 각 agent에는 고유한 ID가 필요하다. 여러 agent가 하나의 이름으로 활동을 생성할 수 있기 때문에 공유 서비스 계정은 조사를 어렵게 한다. 또한 새 워크플로가 같은 계정을 재사용하면서 권한이 누적되도록 만든다.

전용 ID는 소유권 추적을 가능하게 한다. 보안 팀은 agent를 스폰서, 목적, 허용 도구, 배포 환경, 검토 일정과 연결할 수 있다. 관련 없는 자동화를 중단하지 않고도 하나의 워크플로를 중지할 수 있다.

그러나 ID만으로는 충분하지 않다. 고유하게 식별된 agent도 여전히 과도한 권한을 가질 수 있다. 또한 유효한 권한을 잘못된 시점이나 잘못된 목표를 위해 사용할 수 있다.

효과적인 제어는 권한 범위와 권한 지속 시간을 모두 줄여야 한다. 분기 보고서를 준비하는 agent는 접촉한 모든 소스에 대한 영구 접근 권한을 유지해서는 안 된다. 현재 작업을 위해 제한된 범위의 권한만 받아야 한다.

수명이 짧은 자격 증명은 오용 가능한 시간을 줄인다. Just-in-time 접근은 작업이 시작될 때 권한을 부여하고 이후 이를 회수한다. 도구 수준 정책은 agent가 호출할 수 있는 작업을 제한한다.

이러한 제어는 AI agent 내부자 위협이 주는 핵심 교훈을 반영한다. 신뢰는 agent에게 영구적으로 부여되는 것이 아니라, 특정 조건에서 수행되는 특정 행동에 부여되어야 한다.

기업은 읽기와 실행도 분리해야 한다. 일정을 요약하는 agent에는 회의를 예약하는 agent와 다른 권한이 필요하다. 코드 변경을 제안하는 시스템에 자동으로 해당 변경을 배포할 권한까지 부여해서는 안 된다.

이런 구분은 빠른 도입 과정에서 사라질 수 있다. 팀은 읽기 전용 assistant로 시작한 뒤 점진적으로 쓰기 권한, 브라우저 제어, 워크플로 자동화를 추가한다. 초기 위험 평가는 더 이상 배포된 시스템과 일치하지 않는다.

따라서 agent 인벤토리는 설치 현황뿐 아니라 역량을 추적해야 한다. 보안 팀은 어떤 agent가 민감한 데이터에 접근하고, 외부 도구를 호출하고, 공개적으로 소통하고, 레코드를 수정하거나, 거래를 승인할 수 있는지 알아야 한다.

인벤토리는 agent의 변화 속도만큼 빠르게 갱신되어야 한다.

기존 내부자 통제가 Agent 행동을 놓치는 이유

인간의 속도와 동기를 기준으로 설계된 제어 체계는 소프트웨어가 피로하거나 망설이지 않고 수백 건의 정당한 행동을 수행할 수 있을 때 어려움을 겪는다.

인간 내부자 위험 프로그램은 흔히 식별 가능한 행동 변화를 찾는다. 직원이 비정상적인 양의 데이터를 다운로드하거나, 예상치 못한 시간에 로그인하거나, 평소 역할과 무관한 부서에 접근하는 경우다.

이러한 신호는 여전히 유용하지만, agent는 다른 기준선을 만든다. 지속적으로 작동할 수 있고, 사람보다 많은 레코드를 처리할 수 있다. 활동의 출발점도 직원 endpoint가 아닌 안정적인 클라우드 인프라일 수 있다.

높은 행동 빈도는 악의적 행동이 아니라 정상적인 자동화를 의미할 수 있다. 낮은 행동 빈도도 정교하게 표적화된 정보 공개를 숨길 수 있다. 행동량만으로는 신뢰할 수 없는 신호가 된다.

의도 추론도 더 어렵다. 인간 사용자는 보통 대화형 세션을 통해 행동한다. 조사 담당자는 그러한 행동을 직무 책임, 커뮤니케이션, 알려진 비즈니스 프로세스와 비교할 수 있다.

agent는 광범위한 지시를 중간 의사결정으로 번역한다. 사용자는 그러한 결정을 전혀 보지 못할 수 있다. 최종 행동은 최초 요청에서 여러 단계 떨어져 있을 수 있다.

로그에는 그 연쇄가 보존되어야 한다. 조사 담당자는 사용자 지시, 모델 결정, 검색된 컨텍스트, 도구 선택, 권한 부여 결과, 최종 영향까지 재구성할 수 있어야 한다.

이는 모든 내부 모델 연산을 저장해야 한다는 뜻은 아니다. 중요한 외부 행동과 각각을 뒷받침하는 권한에 대한 감사 가능한 기록을 유지해야 한다는 의미다.

표준 애플리케이션 로그는 종종 일부 조각만 제공한다. 한 시스템은 토큰을 기록하고, 다른 시스템은 데이터베이스 쿼리를 기록하며, 세 번째 시스템은 발신 메시지를 기록한다. 공유된 작업 식별자가 없으면 조직은 이를 하나의 agent 워크플로로 연결할 수 없다.

관측 가능성 문제는 multi-agent 시스템에서 커진다. 한 agent가 다른 agent에게 조사를 위임하고, 그 agent가 세 번째 시스템에 도구 실행을 요청할 수 있다. 최초 사용자가 각 참여자를 승인하지 않았더라도 권한은 이 연쇄를 따라 이동할 수 있다.

재귀적 신뢰는 이렇게 확장되는 관계를 설명한다. 조직은 하나의 agent를 신뢰하고, 그 agent는 다른 서비스를 신뢰하며, 그 서비스는 또 다른 ID나 도구에 의존한다. 실질적인 공격 표면은 모든 연결 고리로 확장된다.

AI agent 내부자 위협은 명백한 침입 이벤트를 만들지 않고도 이러한 연쇄를 악용할 수 있다. 침해된 도구 응답은 계획 수립 agent에 영향을 미칠 수 있다. 오염된 메모리 항목은 향후 결정에 영향을 줄 수 있다. 외부 문서는 신뢰된 워크플로의 방향을 바꿀 수 있다.

기존 endpoint 및 네트워크 방어는 여전히 중요하다. 악성 코드를 차단하고, 의심스러운 목적지를 탐지하며, 침해된 인프라를 격리할 수 있다. 하지만 승인된 비즈니스 행동이 사용자가 의도한 결과를 반영하는지 신뢰성 있게 판단할 수는 없다.

그 판단에는 더 풍부한 컨텍스트가 필요하다.

조직은 각 agent 역할에 대한 행동 기준선을 수립해야 한다. 보고 agent는 일반적으로 승인된 데이터 소스를 읽고 특정 문서 저장소에 작성할 수 있다. 이메일 전송이나 자격 증명 접근 시도는 해당 프로필의 범위를 벗어난다.

정책은 순서 제약도 적용할 수 있다. 신뢰할 수 없는 웹페이지를 읽었다고 해서 즉시 기밀 레코드 접근이 승인되어서는 안 된다. 데이터 민감도가 변경되면 새로운 권한 부여 결정을 촉발해야 한다.

인간 승인은 여전히 고영향 작업에 유용합니다. 그러나 승인 화면은 의미 있는 정보를 제시해야 합니다. “계속”하라는 모호한 요청만으로는 검토자가 어떤 데이터가 이동하는지 또는 어떤 레코드가 변경되는지 이해하는 데 도움이 되지 않습니다.

승인 절차에는 작업, 대상 위치, 영향을 받는 리소스, 예상되는 결과가 명시되어야 합니다. 그렇지 않으면 인간은 보안 통제가 아니라 형식적인 확인 절차가 됩니다.

최소 권한은 에이전트가 아니라 작업을 따라야 합니다

가장 안전한 접근 모델은 에이전트에 하나의 작업에 필요한 최소한의 권한만 부여하고, 작업이 바뀌면 새로운 결정을 내리도록 강제합니다.

최소 권한은 오랫동안 보안 원칙으로 여겨져 왔습니다. 에이전트 시스템은 워크플로가 동적이기 때문에 이를 구현하기가 더 까다롭습니다.

전통적인 애플리케이션은 안정적인 기능 집합에 맞는 권한을 부여받습니다. 에이전트는 요청, 검색된 정보 또는 이전 단계의 결과에 따라 서로 다른 도구를 선택할 수 있습니다.

가능한 모든 권한을 미리 부여하면 개발은 단순해집니다. 그러나 동시에 사용되지 않는 권한이 축적됩니다. 조작된 에이전트는 현재 작업에 전혀 필요하지 않은 기능을 사용할 수 있습니다.

작업에 묶인 권한 부여는 더 나은 경로를 제공합니다. 시스템은 선언된 목표를 평가하고 필요한 리소스에 대해 제한된 기능 권한을 발급합니다. 그 권한은 단계 또는 세션이 종료되면 만료됩니다.

Microsoft의 최소 권한 패턴은 자율성을 확대하기 전에 ID, 범위, 도구 접근 및 감사 가능성을 정의할 것을 권장합니다. 또한 책임 소재가 분명한 소유자를 둔 전용 에이전트 ID를 강조합니다.

경비 보고서를 처리하는 에이전트를 생각해 보겠습니다. 이 에이전트는 제출된 문서를 읽고 정책과 대조하며 권고안을 준비해야 합니다. 지급을 실행할 영구 권한은 필요하지 않습니다.

이후 비즈니스가 정해진 한도 이하의 자동 환급을 허용한다면, 그 쓰기 권한은 별도로 분리되어야 합니다. 시스템은 이를 승인한 정책을 기록하고 경계를 벗어나는 경우 상위 검토를 요구해야 합니다.

이러한 분해는 문제가 발생했을 때 피해를 제한합니다. 영수증 내부의 악성 지시가 권고안에 영향을 줄 수는 있습니다. 그러나 그것이 자금의 목적지를 변경할 권한까지 자동으로 부여해서는 안 됩니다.

같은 모델은 지식 업무에도 적용됩니다. 리서치 에이전트는 팀에서 승인한 문서를 검색할 수 있지만, 출력 대상은 계속 제한되어야 합니다. 민감한 원본 자료가 공개 프롬프트, 외부 채널 또는 관련 없는 프로젝트로 흘러가서는 안 됩니다.

접근 결정에는 데이터 맥락이 필요합니다. 파일 레이블, 프로젝트 멤버십, 법적 보존 조치, 고객 제한 또는 기밀성 수준에 따라 동일한 도구 호출의 적절성이 달라질 수 있습니다.

AI knowledge base를 구축하는 조직은 권한 경계를 검색 품질의 일부로 다뤄야 합니다. 유용한 답변은 소유권이나 기밀성 경계를 넘지 않으면서 관련 정보를 활용해야 합니다.

도구 설계도 중요합니다. 광범위한 도구는 광범위한 실패 모드를 만듭니다. 임의의 쿼리를 실행할 수 있는 범용 데이터베이스 커넥터는 승인된 필드만 반환하는 목적형 기능보다 더 큰 위험을 수반합니다.

개발자는 가장 좁으면서도 유용한 작업만 노출해야 합니다. 에이전트에 전체 메일함 접근 권한을 주는 대신, 서비스는 사건 식별자와 일치하는 메시지의 검색만 허용할 수 있습니다. 셸 접근 대신 통제된 빌드 명령을 노출할 수 있습니다.

도구 바인딩은 특정 에이전트 ID를 특정 작업에 연결합니다. 플랫폼이 해당 도구의 존재를 알고 있다는 이유만으로 에이전트가 모든 통합 기능을 호출할 수 있어서는 안 됩니다.

입력과 출력도 모델 외부에서 검증해야 합니다. 모델이 자신이 제안한 작업이 정책을 위반하는지 판단하는 책임을 단독으로 져서는 안 됩니다.

별도의 정책 계층은 실행 전에 대상 위치, 데이터 분류, 거래 한도 및 작업 맥락을 검사할 수 있습니다. 이를 통해 작업을 차단하거나 변환하거나 상위 검토로 넘길 수 있습니다.

이러한 분리는 에이전트 보안에 관한 흔한 오해를 바로잡습니다. 더 나은 프롬프트와 더 강력한 모델은 실수를 줄일 수 있지만, 강제 가능한 경계를 대체할 수는 없습니다.

프롬프트는 지시입니다. 권한 부여 정책은 통제 수단입니다.

이 구분은 중요합니다. 에이전트는 프롬프트를 오해하거나 오염된 맥락을 물려받거나 상충하는 지시를 받을 수 있기 때문입니다. 모델이 예측 불가능하게 동작하더라도 정책 엔진은 계속해서 제한을 집행해야 합니다.

제로 트러스트는 도움이 되지만, 의도를 해결하지는 못합니다

제로 트러스트는 에이전트의 영향 범위를 줄일 수 있지만, 허용된 작업이 사용자의 실제 목표에 부합하는지 자동으로 판단할 수는 없습니다.

이것이 신뢰 기반 접근 논쟁의 핵심적인 절충점입니다. 보안 공급업체들은 점점 더 ID, 조건부 접근, 제로 트러스트를 에이전트 위험의 해법으로 제시하고 있습니다. 이러한 통제는 중요한 취약점을 해결합니다.

Microsoft의 Zero Trust for AI는 AI 데이터, 모델, 워크로드, 사용자 및 에이전트 행동 전반에 명시적 검증과 최소 권한을 확장합니다. Microsoft는 조작되거나 과도한 권한을 부여받거나 정렬이 어긋난 에이전트를 잠재적인 “이중 스파이”로 설명하기도 합니다.

이러한 관점은 유용하지만, 조직은 제로 트러스트를 완결된 제품 범주로 취급해서는 안 됩니다. NIST는 제로 트러스트를 단일 기술 구매가 아니라 일련의 아키텍처 원칙으로 설명합니다.

조직은 현대적인 ID 통제를 배포하면서도 에이전트에 과도한 권한을 남겨둘 수 있습니다. 인증을 요구하면서도 한 에이전트 작업과 다른 작업을 구분하지 못할 수 있습니다. 아무도 검토하지 않는 로그를 수집할 수도 있습니다.

가장 어려운 사례는 권한이 있고 그럴듯해 보이는 작업입니다.

고객 서비스 에이전트는 고객 데이터에 합법적으로 접근하고 메시지를 보낼 수 있습니다. 코딩 에이전트는 소스 파일을 합법적으로 수정할 수 있습니다. 조달 에이전트는 공급업체에 합법적으로 연락할 수 있습니다.

각 작업의 악의적이거나 잘못된 버전은 ID 계층에서는 거의 동일하게 보일 수 있습니다.

맥락 기반 권한 부여는 그 격차를 좁힙니다. 시스템은 대상이 승인되었는지, 요청된 필드가 필요한지, 작업이 과거 행동과 일치하는지, 데이터 분류가 전송을 허용하는지 물을 수 있습니다.

그럼에도 맥락 모델은 거짓 양성과 거짓 음성을 만듭니다. 엄격한 통제는 유용한 워크플로를 중단시킬 수 있습니다. 느슨한 통제는 생산성을 유지하는 대신 유해한 조합을 허용할 수 있습니다.

조직은 자율성이 어디에서 멈출지를 결정해야 합니다. 영향이 작고 되돌릴 수 있는 작업은 더 많은 자유를 허용할 수 있습니다. 영향이 크고 되돌릴 수 없는 작업은 더 강한 검증과, 종종 인간의 승인을 요구합니다.

되돌릴 수 있는지 여부는 특별한 주의가 필요합니다. 메시지 초안을 작성하는 에이전트는 검토 가능한 산출물을 만듭니다. 메시지를 보내는 에이전트는 외부 세계를 바꿉니다. 레코드 삭제를 권고하는 에이전트와 실제로 삭제를 수행하는 에이전트는 다릅니다.

보안 아키텍처는 이러한 차이를 반영해야 합니다.

팀은 에이전트를 모델뿐 아니라 시스템으로도 테스트해야 합니다. 모델 평가는 통제된 조건에서 에이전트가 지시를 따르는지 측정할 수 있습니다. 프로덕션 위험은 도구, 자격 증명, 메모리, 데이터 소스 및 주변 애플리케이션에 달려 있습니다.

레드팀 훈련에는 악성 문서, 모호한 목표, 손상된 도구 응답 및 예상치 못한 권한 조합을 도입해야 합니다. 목적은 외부 통제가 실패를 억제하는지 관찰하는 것입니다.

OWASP의 프레임워크는 팀이 이러한 위협을 열거하는 데 도움을 주며, NIST의 cloud access model은 ID 계층 정책과 세분화된 애플리케이션 통제가 분산 서비스 전반의 제로 트러스트를 어떻게 지원하는지 설명합니다.

어느 쪽도 에이전트가 비즈니스 의도를 이해한다고 보장하지는 않습니다. 이러한 불확실성은 배포 결정에서 계속 명확히 드러나야 합니다.

따라서 보안 책임자는 범위를 설명하지 않은 채 플랫폼이 “에이전트를 보호한다”고 주장하는 경우 이를 검증해야 합니다. 에이전트 ID를 발견할 수 있는가? 권한을 관리하는가? 도구 호출을 검사하는가? 프롬프트와 데이터를 보호하는가? 시스템 간 감사 추적을 보존하는가?

대부분의 제품은 수명 주기의 일부만 다룹니다. 기업에는 여전히 정책 소유권, 운영 프로세스, 사고 대응 및 애플리케이션별 통제가 필요합니다.

AI agent insider threat는 하나의 패치로 해결할 수 있는 단일 취약점이 아닙니다. 이는 확률적으로 의사결정하는 시스템을 신뢰된 워크플로에 배치한 결과입니다.

신뢰 기반 접근이 개선되고 있는지 보여줄 세 가지 신호

AI 보안의 다음 단계는 책임 있는 에이전트에 관한 더 광범위한 약속이 아니라, 배포 가능한 통제와 사고 증거로 측정될 것입니다.

첫 번째 신호는 구분되고 관리되는 에이전트 ID의 도입입니다. 조직은 에이전트를 열거하고, 소유자를 식별하며, 권한을 검토하고, 개별적으로 비활성화할 수 있어야 합니다.

Microsoft Entra의 agent identity framework는 주요 ID 플랫폼이 향하는 방향을 보여줍니다. 이는 비인간 행위자를 위한 전용 에이전트 구성 요소, 활동 로깅, 거버넌스 및 조건부 접근을 지원합니다.

다른 ID 및 클라우드 제공업체도 이기종 환경 전반에서 이에 상응하는 통제를 제공해야 한다는 압박을 받을 것입니다. 기업은 하나의 에이전트 플랫폼이나 하나의 ID 시스템만 운영하는 경우가 드뭅니다.

관리자가 공유 서비스 계정에 의존하지 않고도 애플리케이션 전반에서 하나의 에이전트 작업을 추적할 수 있을 때 진전은 신뢰할 만해집니다. 전용 ID가 선택 사항으로 남거나 플랫폼별로만 제공된다면 가시성은 계속 파편화될 것입니다.

두 번째 신호는 작업 범위에 한정되고 수명이 짧은 권한 부여의 확산입니다. 에이전트 플랫폼은 사용자나 개발자로부터 상시 권한을 상속하는 대신, 정의된 작업에 필요한 접근을 요청해야 합니다.

이 변화에는 오케스트레이션 시스템과 ID 인프라 간의 더 나은 통합이 필요합니다. 플랫폼은 정책 엔진이 평가할 수 있는 형태로 에이전트의 의도를 설명해야 합니다.

승인 인터페이스도 개선되어야 합니다. 사용자는 민감한 권한을 부여하기 전에 리소스, 작업, 대상 및 예상 효과를 확인해야 합니다.

공급업체가 이러한 통제를 기본값으로 제공한다면 신뢰 기반 접근의 논지는 더 강해집니다. 안전한 구성을 위해 광범위한 맞춤 엔지니어링이 필요하다면, 납기 압박을 받는 팀은 계속해서 광범위한 권한을 선택할 것입니다.

세 번째 신호는 실제 사고와 독립적인 테스트에서 나온 공개 증거입니다. 보안 팀은 에이전트가 시연 환경 밖에서 어떻게 실패하는지 알아야 합니다.

유용한 공개 자료는 최초 지시, 접근 경로, 관련 도구, 실패한 통제 및 억제가 성공한 지점을 설명해야 합니다. 안전하지 않은 출력에 대한 모호한 언급만으로는 충분한 아키텍처 지침을 제공하지 못합니다.

독립 평가는 프롬프트 인젝션, 과도한 자율성, 오염된 메모리, 자격 증명 노출 및 에이전트 간 조작에 맞서 완전한 에이전트 시스템을 테스트해야 합니다. 또한 통제가 유용한 업무를 보존하는지도 측정해야 합니다.

사고 보고는 어떤 위험이 지배적인지 명확히 할 것입니다. 프롬프트 인젝션은 상당한 주목을 받고 있지만, 구성 오류, 과도한 권한, 공유 ID 및 검토되지 않은 통합도 그에 못지않게 중요할 수 있습니다.

그 결과는 지출과 설계 우선순위를 결정할 것입니다. 대부분의 사고가 탈취된 자격 증명과 관련된다면 ID 보호가 우선시될 것입니다. 유효한 에이전트가 허용된 도구를 반복적으로 오용한다면 런타임 권한 부여와 행동 통제가 주요 격전지가 될 것입니다.

기업은 완벽한 표준을 기다릴 필요가 없습니다. 지금 에이전트를 목록화하고, ID를 분리하며, 사용하지 않는 권한을 제거하고, 도구를 제한하고, 작업 체인을 기록하며, 되돌릴 수 없는 작업에는 승인을 요구할 수 있습니다.

또한 에이전트가 예기치 않게 행동할 때 어떤 일이 일어나는지 정의해야 합니다. 신속한 중단, 자격 증명 폐기, 워크플로 격리 및 증거 보존은 사고 대응 계획에 포함되어야 합니다.

실질적인 질문은 간단합니다. 조직이 중요한 모든 에이전트 행동을 설명할 수 있고, 전체 비즈니스 프로세스를 중단하지 않고도 그 권한을 회수할 수 있는가?

답이 아니오라면, 해당 에이전트는 보안 아키텍처가 안전하게 관리할 수 있는 수준보다 더 많은 신뢰를 받고 있는 것입니다.

AI 에이전트 내부자 위협은 운영 순서를 바꿉니다. 기업은 먼저 광범위한 접근 권한을 부여한 뒤 배포 후에 모니터링을 추가할 수 없습니다. 자율성보다 앞서 신원 관리, 작업 경계, 감사 가능성, 격리 체계가 마련되어야 합니다.

개발자와 엔터프라이즈 구매자는 다음 평가에서 에이전트가 데모를 완료하는지 여부를 넘어 살펴봐야 합니다. 무엇에 접근할 수 있는지, 그 권한은 어떻게 만료되는지, 독립적인 통제 수단이 최종 행동을 중단시킬 수 있는지를 물어야 합니다.

신뢰할 수 있는 접근은 이제 전장이 되었습니다. 접근 권한은 모델의 출력을 실제 결과로 전환하기 때문입니다. 이 전환을 관리하는 조직은 인증된 모든 행동을 본질적으로 신뢰할 수 있다고 간주하지 않으면서도 자동화의 가치를 확보하게 될 것입니다.