Amazon Google 보안 경쟁이 치열해지면서 AI 에이전트에 강력한 제한을 두는 AWS

AWS는 공격자나 오염된 데이터가 AI 에이전트의 추론을 조작할 위험이 있음에도, 에이전트에 강제 가능한 제한을 적용했다. 이는 어느 클라우드가 에이전트를 중요한 기업 시스템에 안전하게 연결할 수 있는지를 두고 벌어지는 Amazon Google 경쟁을 한층 선명하게 만든다.

Amazon Bedrock AgentCore Policy는 에이전트가 요청한 도구 작업이 기반 서비스에 도달하기 전에 이를 검사한다. 조작된 에이전트가 위험한 요청을 생성할 수는 있지만, 그 요청이 외부 정책과 충돌할 경우 실패해야 한다.

이 구분은 프롬프트 필터가 결코 완전한 보안 경계를 제공하지 못했기 때문에 중요하다. 모델은 동일한 확률적 메커니즘으로 지시문과 신뢰할 수 없는 데이터를 처리한다. AWS는 이제 모델을 최종 권한자가 아니라 신뢰할 수 없는 의사결정자로 취급한다.

Google Cloud와 Microsoft도 각자의 ID, 게이트웨이, 정보 흐름 제어를 통해 같은 큰 방향을 따르고 있다. 새롭게 형성되는 경쟁은 더 이상 모델 품질에만 국한되지 않는다. 클라우드 제공업체는 에이전트가 연결된 모든 시스템에 대한 무제한 접근 권한을 상속받지 않고도 작업할 수 있음을 보여야 한다.

에이전트 외부로 권한 부여를 옮기는 AWS

AWS는 에이전트가 하고자 하는 일과 인프라가 허용하는 일을 분리하고 있다.

Amazon Bedrock AgentCore의 정책은 에이전트와 도구 간 상호작용 주위에 보호 경계를 만든다. 이 서비스는 AgentCore Gateway를 통해 라우팅되는 요청을 가로채고, 도구 호출을 허용하기 전에 각 요청을 평가한다.

AgentCore Gateway는 관리형 인터페이스를 통해 에이전트를 API, 함수 및 기타 도구와 연결한다. 정책 엔진은 에이전트의 프롬프트나 오케스트레이션 코드 내부가 아니라 그 연결 옆에 위치한다.

이 배치는 보안 모델을 바꾼다. 시스템 프롬프트는 에이전트에게 제한된 고객 기록을 절대 조회하지 말라고 지시할 수 있다. 그러나 프롬프트 인젝션은 모델이 그 지시를 무시하거나 다르게 해석하도록 설득할 수 있다.

외부 권한 부여 엔진은 모델의 동의가 필요하지 않다. 명시적 규칙, 인증된 ID, 도구 매개변수 및 사용 가능한 요청 컨텍스트를 사용해 제안된 작업을 평가한다.

AWS는 이러한 규칙을 표현하기 위해 오픈소스 권한 부여 언어인 Cedar를 사용한다. Cedar 정책은 요청을 수행하는 주체, 요청된 작업, 보호된 리소스 및 필요한 조건을 식별한다.

이 서비스는 기본 거부 의미론을 따른다. 정책이 명시적으로 허용하지 않는 한 작업에는 접근 권한이 부여되지 않는다. 일치하는 금지 규칙은 해당 요청을 허용할 수 있는 더 광범위한 권한보다도 우선한다.

AWS는 AgentCore policy guide에서 이러한 작동 방식을 설명한다. 이 가이드는 라우팅된 모든 에이전트 요청이 도구 접근 권한이 부여되기 전에 평가된다고 밝힌다.

개발자는 Cedar를 직접 작성하거나 요구사항을 평이한 영어로 기술할 수 있다. 자연어 작성 서비스는 이러한 요구사항을 후보 Cedar 정책으로 변환한다.

AWS는 이 서비스가 생성된 정책을 게이트웨이의 도구 스키마에 대해 검증한다고 말한다. 또한 지나치게 허용적이거나 과도하게 제한적이거나 충족 불가능해 보이는 규칙도 확인한다.

이 생성 과정이 모호한 요구사항을 안전하게 만들어 주는 것은 아니다. AWS는 자연어 정책도 정확하고 모호하지 않은 문구가 필요하다고 경고한다. 보안 팀은 생성된 정책을 의심의 여지 없는 코드로 취급하지 말고 결과 Cedar를 검토해야 한다.

정책을 만드는 모델도 이를 집행하는 메커니즘과 분리돼 있다. 배포된 후에는 다른 모델에 의견을 묻는 대신 형식 정책이 권한 부여 결정을 통제한다.

계정 조회와 환불 처리 도구를 갖춘 내부 지원 에이전트를 생각해 보자. 기업은 모든 지원 담당자가 자신에게 배정된 계정을 조회하도록 허용하면서, 더 큰 금액의 환불 승인 권한은 관리자에게만 부여할 수 있다.

이메일에 환불을 요구하는 악의적 지시가 포함돼 있다면 에이전트는 해당 작업을 시도할 수 있다. 하지만 인증된 직원에게 필요한 역할이 없거나 금액이 정책 한도를 초과하면 게이트웨이는 여전히 이를 거부할 수 있다.

거부된 요청은 결제 시스템에 도달할 필요조차 없다. 이 결과는 에이전트에게 악의적 지시의 모든 변형을 식별하도록 요구하는 것보다 더 강력하다.

AWS 출시 문서에 따르면 AgentCore Policy는 13개 AWS 리전에서 정식 제공된다. 중앙화된 정책은 연결된 게이트웨이를 통해 여러 에이전트와 도구에 일관되게 적용될 수 있다.

CloudWatch 통합은 모니터링과 감사를 위해 권한 부여 결정을 기록한다. 이러한 기록은 에이전트가 어떤 작업을 요청했고, 허용됐거나 거부됐는지 보안 팀에 더 명확히 보여준다.

따라서 즉각적인 변화는 장식적인 것이 아니라 아키텍처적이다. AWS는 불확실한 모델 동작과 중요한 기업 시스템 사이에 결정론적 검사 지점을 배치하고 있다.

프롬프트 인젝션이 Amazon Google 경쟁을 바꾸는 이유

이제 Amazon Google 클라우드 경쟁은 단순히 답변 품질을 높이는 것이 아니라, 침해된 에이전트를 통제하는 능력에 달려 있다.

AI 에이전트는 비공개 정보를 조회하고, API를 호출하고, 메시지를 보내거나, 기록을 변경할 수 있을 때 유용해진다. 바로 그 권한이 조작 이후 발생 가능한 피해 규모도 결정한다.

프롬프트 인젝션은 모델이 처리하는 콘텐츠에 적대적 지시를 삽입한다. 직접 인젝션은 사용자 요청에서 비롯되는 반면, 간접 인젝션은 웹사이트, 문서, 이메일 또는 도구 응답 안에 숨겨질 수 있다.

공급업체를 조사하는 에이전트는 웹페이지에 삽입된 지시를 접할 수 있다. 해당 지시는 기밀 파일을 조회한 뒤 다른 연결 도구를 통해 전송하라고 명령할 수 있다.

콘텐츠 필터는 익숙한 공격 패턴을 탐지할 수 있다. 하지만 이례적인 표현, 인코딩된 명령 또는 여러 상호작용에 분산된 시퀀스는 놓칠 수도 있다.

근본적인 문제는 악의적 프롬프트를 넘어선다. 모델은 작업을 환각하거나, 비즈니스 규칙을 오해하거나, 개별적으로는 허용 가능한 도구들을 허용할 수 없는 워크플로로 결합할 수 있다.

OWASP는 이 상태를 excessive agency라고 설명한다. LLM이 예상치 못한 출력 이후 유해한 결과를 초래할 만큼 충분한 기능이나 권한을 부여받을 때 위험이 나타난다.

권한 부여는 그에 따른 피해 반경을 제한한다. 이 시스템은 에이전트가 결국 잘못된 결정을 내릴 것이라고 가정한 뒤, 그 결정이 무제한 작업으로 이어지는 것을 막는다.

이 접근 방식은 확립된 클라우드 보안 관행과 닮아 있다. 애플리케이션에는 작업에 필요한 권한만 부여해야 하며, 민감한 작업에는 추가 검사를 적용해야 한다.

에이전트는 도구를 동적으로 선택하기 때문에 이 원칙을 복잡하게 만든다. 또한 여러 호출을 연결하고, 단계 간 컨텍스트를 유지하며, 직접 감독 없이 더 오랫동안 작동할 수 있다.

따라서 광범위한 권한을 가진 정적 서비스 계정은 심각한 책임이 될 수 있다. 에이전트는 관련 사용자나 작업과 무관하게 그 자격 증명에 연결된 모든 기능을 사실상 얻게 된다.

AWS는 AgentCore 요청을 OAuth 사용자 또는 AWS Identity and Access Management 엔터티에 연결할 수 있다. 그러면 정책은 에이전트의 공유 서비스 역할에만 의존하지 않고 요청 배후의 ID를 고려할 수 있다.

Google은 Gemini 기반 에이전트와 Model Context Protocol 연결을 확장하면서 같은 문제에 직면하고 있다. MCP는 모델이 외부 도구를 발견하고 호출할 수 있게 해 주는 표준 인터페이스다.

Google의 MCP security guidance는 프로덕션 접근에 대한 거부 정책, 범위를 좁힌 권한, 입력 정제 및 모니터링을 권장한다. 또한 그렇지 않으면 보안이 전적으로 에이전트 프로그래밍에 의존할 수 있다고 경고한다.

이러한 수렴은 중요하다. Amazon Google 경쟁은 흔히 모델 가용성, 인프라, 데이터 플랫폼, 개발자 도구를 중심으로 전개됐다. 에이전트 권한 부여는 또 하나의 주요 구매 기준이 되고 있다.

기업 고객은 에이전트를 고립된 챗봇으로 배포하는 경우가 드물다. 이들은 에이전트를 데이터베이스, 코드 저장소, 지원 플랫폼, 클라우드 콘솔 및 내부 지식 저장소에 연결하길 원한다.

모든 연결은 효용과 노출을 동시에 만든다. 연결은 쉽게 만들지만 권한 부여는 취약한 클라우드 제공업체는 운영 위험을 고객에게 되돌려 넘긴다.

AWS는 AgentCore Policy를 프레임워크와 모델 전반에서 재사용할 수 있는 집행 계층으로 자리매김하고 있다. 개발자는 여러 인기 오케스트레이션 프레임워크로 구축한 에이전트와 AgentCore를 함께 사용할 수 있다.

이러한 개방성은 기업이 모델을 바꾸더라도 보안 정책은 안정적으로 유지돼야 한다는 AWS의 주장을 뒷받침한다. 조직은 모든 권한 규칙을 다시 작성하지 않고도 하나의 파운데이션 모델을 다른 모델로 교체할 수 있다.

Google도 클라우드 ID 제어, Model Armor, 리소스 수준 권한을 통해 유사한 주장을 펼칠 수 있다. Google의 강점은 Google Workspace, Gemini 및 광범위한 데이터 플랫폼과의 근접성이다.

Microsoft는 Entra ID, Copilot 및 에이전트 개발 스택을 통해 압박을 더하고 있다. 시장은 AI 추론과 기업 실행 사이의 경계를 누가 통제하는지를 두고 벌이는 3자 경쟁으로 변하고 있다.

구매자에게 중요한 Amazon Google 질문은 어떤 모델이 악의적 프롬프트를 언제나 거부하는가가 아니다. 어떤 공급업체도 모든 입력과 도구 조합에서 완벽한 거부를 신뢰성 있게 약속할 수는 없다.

더 나은 질문은 거부가 실패한 뒤에 무슨 일이 벌어지는가다. 안전한 플랫폼은 침해된 에이전트가 사용할 수 있는 도구, 기록, 매개변수, 대상 및 작업 순서를 제한해야 한다.

도구 경계에서 만나는 Amazon Google 보안 전략

AWS, Google, Microsoft는 결정론적 집행으로 수렴하고 있지만, 그 집행을 구성하는 방식은 서로 다르다.

AWS는 AgentCore Policy를 게이트웨이 경로에 직접 배치한다. 적용 대상인 모든 에이전트-도구 요청은 요청된 호출이 진행되기 전에 정책 엔진에 도달한다.

Cedar는 팀이 검사, 검증, 분석할 수 있는 형식 언어를 AWS에 제공한다. AWS는 에이전트를 넘어 Cedar 개념을 사용해 왔으며, 이는 에이전트 권한 부여를 확립된 애플리케이션 보안 관행과 연결하는 데 도움이 된다.

이 회사의 보안 연구자들은 모델 자체에 대해 단호한 가정을 한다. 이들의 Cedar security analysis는 조직이 심층 방어 설계 안에서 LLM을 신뢰할 수 없는 행위자로 취급해야 한다고 말한다.

이는 모델이 악의적이라는 뜻이 아니다. 모델은 확률적으로 작동하고 조작된 컨텍스트에 취약하기 때문에, 권한 부여 시스템은 예측 가능한 모델 동작에 의존할 수 없다는 뜻이다.

Google의 공개 가이드는 현재 MCP 서버와 Google Cloud 리소스 주변의 계층형 제어를 강조한다. 이러한 제어에는 거부 정책, 최소 권한 자격 증명, 분리된 테스트 환경, 정제된 입력 및 제한된 프로덕션 접근이 포함된다.

Google은 워크플로에 필요하지 않은 한 읽기-쓰기 도구가 프로덕션 리소스에 도달하지 못하도록 막는 것도 권장한다. 권한이 부여된 작업조차 원치 않는 결과를 낳을 수 있으므로 복구 기능은 여전히 중요하다.

실질적인 차이는 개발자 경험에서 드러날 수 있다. AWS는 관리형 게이트웨이에서 Cedar 기반 평가를 제공하는 전용 AgentCore 정책 엔진을 제공한다.

Google은 성숙한 Cloud IAM과 제품별 정책을 활용할 수 있다. 그러나 개발자는 관련된 모든 도구 경로가 실제로 의도한 제어 지점을 통과하도록 여전히 보장해야 한다.

이 단서는 AWS에도 적용됩니다. AgentCore Policy는 연결된 AgentCore Gateway를 통해 라우팅되는 트래픽을 관리합니다. 다른 실행 경로를 가진 에이전트는 해당 검사 지점을 우회할 수 있습니다.

예를 들어 정책은 관리형 MCP 도구를 통한 S3 작업을 차단할 수 있습니다. 하지만 동등한 명령을 실행할 수 있는 별도의 셸 도구까지 자동으로 제한되지는 않습니다.

따라서 아키텍처 검토에서는 단순히 도구 이름이 아니라 기능을 열거해야 합니다. 보안팀은 에이전트가 SDK, 명령줄, 브라우저, 함수 또는 보조 에이전트를 통해 동일한 리소스에 도달할 수 있는지 물어야 합니다.

Microsoft는 정보 흐름 제어를 통해 또 다른 변형을 개발하고 있습니다. FIDES 미들웨어는 콘텐츠에 무결성과 기밀성 라벨을 부여한 뒤, 그 라벨을 도구 호출 전반에 전달합니다.

Microsoft의 FIDES 보안 모델은 신뢰할 수 없는 콘텐츠가 민감한 작업에 영향을 미치지 못하도록 막을 수 있습니다. 또한 비공개 데이터가 공개 대상에 흘러가는 것도 제한할 수 있습니다.

이 접근 방식은 단일 작업 권한 부여의 약점을 다룹니다. 데이터베이스 조회는 허용될 수 있고 이메일 발송도 허용될 수 있습니다. 위험한 행위는 비공개 쿼리 결과가 외부 이메일로 흘러갈 때 나타납니다.

AWS는 세션 인식 평가로 정책을 확장해 왔습니다. 시간적 제어는 모든 요청을 고립된 이벤트로 판단하는 대신 에이전트의 최근 작업을 살펴볼 수 있습니다.

공격자는 해로운 목표를 여러 개의 정상적으로 보이는 단계로 나눌 수 있기 때문에 이 방향은 중요합니다. 개별 작업에서는 드러나지 않는 위험이 일련의 작업에서는 드러날 수 있습니다.

에이전트는 먼저 기밀 포트폴리오를 읽고, 요약을 계산한 뒤, 마지막으로 외부 전송을 시도할 수 있습니다. 이들을 연결하는 궤적이 보이지 않으면 각 도구 호출은 유효해 보일 수 있습니다.

Amazon과 Google의 보안 설계를 비교하는 고객에게는 용어보다 적용 범위가 더 중요합니다. 고위험 실행 경로가 집행 대상에서 제외되어 있다면, 형식적인 정책 언어는 보호 효과가 거의 없습니다.

ID 전파도 중요합니다. 정책 엔진은 사용자, 워크로드, 리소스, 작업 및 관련 비즈니스 맥락을 신뢰성 있게 파악해야 합니다.

에이전트가 여러 직원을 지원하는 경우 일반적인 “agent” ID는 충분하지 않습니다. 이는 모든 사용자에게 에이전트의 최대 권한 집합을 부여하고, 일반적인 접근 제어가 제공하는 책임 추적성을 지워버릴 수 있습니다.

조직은 위임된 각 요청 뒤에 있는 사람 또는 워크로드 ID를 보존해야 합니다. 또한 공유 자격 증명 안에 에이전트를 숨기는 대신, 자체적으로 제한된 ID를 에이전트에 부여해야 합니다.

이러한 분리는 서로 다른 두 가지 질문에 답하는 데 도움이 됩니다. 첫 번째는 사용자가 해당 작업을 요청할 수 있는지 묻습니다. 두 번째는 이 에이전트가 이 특정 도구를 통해 그 작업을 수행할 수 있는지 묻습니다.

중앙 정책은 팀 간 불일치도 줄입니다. 중앙 정책이 없다면 각 개발자는 프롬프트, 맞춤형 미들웨어 또는 개별 도구 핸들러 안에 권한 부여를 구현할 수 있습니다.

그러한 분산된 검사는 감사하기 어려워집니다. 에이전트에 새로운 도구, 모델 및 워크플로 분기가 추가되면서 검사 로직도 서로 달라집니다.

공유 게이트웨이가 모든 리소스 수준 권한을 대체할 수는 없습니다. 하지만 에이전트의 의도가 다운스트림 서비스에 도달하기 전에 조직이 정책을 적용하는 일관된 지점을 제공할 수 있습니다.

정책의 강도는 적용 범위만큼만 강하다

AgentCore Policy는 위험을 줄이지만, AWS에서 호스팅되는 에이전트가 안전하다는 것을 증명하지는 않습니다.

이 서비스는 구성된 게이트웨이와 정책 엔진을 통과하는 요청을 제어합니다. 개발자가 그 경계 밖에 남겨 둔 도구, 자격 증명 또는 네트워크 경로까지 관리할 수는 없습니다.

이는 적용 범위 문제를 만듭니다. 보안팀은 위험한 작업을 차단했다고 믿을 수 있지만, 대체 도구가 동일한 리소스에 이르는 다른 경로를 제공할 수 있습니다.

광범위한 IAM 권한은 이 격차를 악화시킬 수 있습니다. 에이전트의 런타임 역할이 서비스를 직접 호출할 수 있다면, 게이트웨이 제한은 비인가 경로를 차단하는 리소스 정책과 함께 적용되어야 합니다.

정책 설계도 여전히 어렵습니다. 자연어 저작은 문법 장벽을 낮추지만, 모호한 비즈니스 요구사항이나 누락된 보안 가정을 해결하지는 않습니다.

“분석가가 적절한 보고서를 볼 수 있도록 허용한다”는 정확한 권한 부여 규칙이 아닙니다. 조직은 어떤 분석가, 보고서, 분류, 지역, 고객 및 운영 조건이 적절한지 정의해야 합니다.

생성된 Cedar는 검토, 테스트 및 변경 관리가 필요합니다. 팀은 예상된 승인, 예상된 거부, 형식이 잘못된 요청, 누락된 컨텍스트, 그리고 의도적으로 적대적인 파라미터 조합을 테스트해야 합니다.

모든 것을 거부하는 정책은 운영 실패를 일으킵니다. 반대로 조용히 모든 것을 허용하는 규칙은 정반대의 문제를 만듭니다. 두 결과 모두 문법적으로는 유효해 보일 수 있습니다.

개발자는 에이전트가 제공하는 권한 부여 컨텍스트도 고려해야 합니다. 보안에 민감한 속성은 신뢰할 수 있는 ID 토큰, 리소스 메타데이터 또는 통제된 인프라에서 가져와야 합니다.

모델이 거래의 위험이 낮다거나 문서가 공개되어 있다고 선언하도록 허용해서는 안 됩니다. 이러한 주장은 모델의 추론 과정 밖에서 검증되어야 합니다.

감사 로그는 또 다른 의무를 수반합니다. 모든 결정을 기록하면 조사에 도움이 되지만, 팀은 기록을 적극적으로 모니터링하고 유용한 컨텍스트를 보존해야 합니다.

거부된 작업은 보안 제어가 성공했음을 나타낼 수 있습니다. 반복적인 거부는 손상된 워크플로, 정책 오류 또는 에이전트가 금지된 목표를 계속 재시도하고 있음을 드러낼 수도 있습니다.

허용된 작업도 주의가 필요합니다. 특히 정책이 세션 이력이나 데이터 이동을 고려하지 않을 때 공격자는 개별적으로는 정당한 권한을 악용할 수 있습니다.

되돌릴 수 없거나 영향이 큰 작업에는 사람의 승인이 여전히 유용합니다. 그러나 에이전트가 요청된 작업에 대해 오해를 부르는 설명을 제공하면 승인 화면은 실패할 수 있습니다.

인터페이스는 실제 도구 요청에서 가져온 신뢰할 수 있는 세부 정보를 표시해야 합니다. 검토자는 대상, 리소스, 파라미터, 데이터 분류 및 예상 효과를 확인해야 합니다.

보안팀은 정책 관리 영역도 방어해야 합니다. 에이전트가 자체 규칙을 편집하거나, 더 약한 정책 엔진을 연결하거나, 더 광범위한 접근 권한을 가진 자격 증명을 획득할 수 있어서는 안 됩니다.

여기서 역할 분리가 도움이 됩니다. 개발자는 정책 변경을 제안하고, 보안 담당자는 통제된 워크플로를 통해 변경 사항을 검토하고 배포할 수 있습니다.

동일한 원칙은 내부 지식 시스템에도 적용됩니다. 검색 가능한 지식 베이스를 구축하는 팀은 해당 콘텐츠를 에이전트에 노출하기 전에 문서 권한을 보존해야 합니다.

검색은 요청 사용자의 권한에 따라 레코드를 필터링해야 합니다. 모델은 사용자가 직접 접근할 수 있는 정보의 부분 집합만 받아야 합니다.

이 설계는 중요한 실패 모드를 방지합니다. 성공적으로 조작된 모델조차도 접근 가능한 컨텍스트에 한 번도 들어오지 않은 정보는 공개할 수 없습니다.

조직은 프롬프트 인젝션 탐지에 모든 신뢰를 두어서는 안 됩니다. 탐지는 유용한 방어 수단을 추가하지만, 익숙하지 않은 공격과 무해해 보이는 지시문은 분류기를 피할 수 있습니다.

AWS는 게이트웨이 입력과 출력을 평가하기 위해 정책 계층에서 Bedrock Guardrails를 지원합니다. 이 기능은 Cedar 집행을 대체하는 것이 아니라 보완합니다.

차이는 간단합니다. 가드레일은 콘텐츠가 위험해 보이는지 추정하는 반면, 권한 부여는 요청된 작업이 허용되는지 결정합니다.

확률적 탐지와 결정론적 집행은 서로 다른 문제를 해결합니다. 두 방식을 결합하면 어느 한 계층이 모든 실패를 포착한다는 착각 없이 공격 표면을 줄일 수 있습니다.

Amazon과 Google의 보안 경쟁은 이러한 계층을 우회하기 어렵게 만드는 공급업체에 보상을 줄 것입니다. 안전한 에이전트에 대한 마케팅 주장은 입증 가능한 집행 범위보다 중요하지 않습니다.

고객은 간접 인젝션, 손상된 도구, 대체 실행 경로 및 다단계 데이터 이동을 포함한 레드팀 훈련으로 이러한 주장을 검증해야 합니다.

또한 실패 시 동작도 확인해야 합니다. 거부된 도구 호출은 오류 또는 폴백 경로를 통해 민감한 세부 정보를 노출하지 않고 보호 대상 작업을 중단해야 합니다.

AWS는 정책을 에이전트 코드 밖에 배치함으로써 더 강력한 기본 패턴을 확립했습니다. 남은 질문은 고객이 주변의 ID와 경로를 같은 수준의 주의로 구성할 것인지입니다.

엔터프라이즈 구매자가 다음으로 주목해야 할 것

다음 단계에서는 경쟁 에이전트 플랫폼 전반의 정책 적용 범위, 세션 인식 및 이식성이 시험대에 오를 것입니다.

첫 번째 신호는 고객이 시간적 정책을 얼마나 빠르게 도입하는가입니다. 단일 요청 규칙은 명확한 제한에 효과적이지만, 많은 에이전트 공격은 권한이 부여된 작업의 연속을 통해 나타납니다.

시간적 평가는 에이전트가 외부 전송을 시도하기 전에 민감한 데이터를 읽었음을 감지할 수 있습니다. 또한 특정 작업 순서 이후 추가 승인을 요구할 수도 있습니다.

어려운 부분은 상태와 해석에 있습니다. 시스템은 일반적인 워크플로를 차단하거나 과도한 지연을 추가하지 않으면서 위험한 궤적을 인식할 수 있을 만큼 충분한 이력을 추적해야 합니다.

구매자는 정확히 어느 정도의 세션 이력을 평가하는지 설명하는 공개 기술 문서를 찾아야 합니다. 또한 사용자, 에이전트 및 동시 작업 간에 상태가 어떻게 격리되는지도 물어야 합니다.

두 번째 신호는 Google과 Microsoft가 관리형 에이전트 플랫폼을 통해 동등한 제어 기능을 어떻게 제공하는가입니다. 세 공급업체 모두 프롬프트 지시문만으로는 연결된 시스템을 보호할 수 없다는 점을 인식하고 있습니다.

Gemini 에이전트는 Workspace 콘텐츠, 클라우드 데이터 및 개발자 인프라와 가까이 위치할 수 있기 때문에 Google의 대응은 중요합니다. 강력한 리소스 권한은 이미 존재하지만, 에이전트에 특화된 구성은 여전히 필수적입니다.

Microsoft는 Entra ID를 Copilot, Agent Framework 및 정보 흐름 라벨과 결합할 수 있습니다. Microsoft 도구와 타사 도구 전반에서 일관된 집행을 제공하는지가 Microsoft의 강점을 좌우할 것입니다.

Amazon과 Google의 비교는 엔드투엔드 경로에 초점을 맞춰야 합니다. 구매자는 사용자 ID에서 에이전트 추론, 게이트웨이 실행, 최종 리소스 접근에 이르기까지 정책이 작업을 따라간다는 증거를 필요로 합니다.

세 번째 신호는 독립적인 보안 테스트입니다. 공급업체 문서는 의도된 동작을 설명하는 반면, 레드팀은 누락된 경로, 혼동된 ID, 안전하지 않은 기본값 및 예상치 못한 도구 조합을 드러냅니다.

테스트에는 악성 웹페이지, 오염된 지원 티켓, 손상된 MCP 응답, 승인된 리포지토리 내부의 적대적 문서가 포함되어야 합니다. 각 소스는 간접 지시문을 에이전트의 컨텍스트로 가져올 수 있습니다.

연구자는 에이전트가 금지된 요청을 기술적으로 다른 작업으로 변환할 수 있는지도 테스트해야 합니다. 차단된 내보내기는 브라우저 업로드, 셸 명령, 인코딩된 메시지 또는 다른 에이전트에 대한 요청으로 바뀔 수 있습니다.

결과는 외부 정책이 의미 있는 격리를 제공하는지, 아니면 또 하나의 구성 계층에 불과한지를 결정할 것입니다. 가장 강력한 증거는 모델의 동작을 바꾸지만 여전히 권한 부여 경계를 넘지 못하는 공격에서 나올 것입니다.

기업은 아키텍처를 개선하기 위해 그 결과를 기다릴 필요가 없습니다. 모든 에이전트, 도구, 자격 증명, 데이터 소스 및 외부 대상의 목록을 만드는 것부터 시작할 수 있습니다.

각 도구에는 가능한 한 가장 좁은 작업 범위를 부여해야 합니다. 읽기 전용 접근은 수정, 삭제, 외부 공유 또는 금융 실행과 분리되어야 합니다.

팀은 단기 위임으로 충분한 경우 상시 자격 증명을 제거해야 합니다. 도구 호출 전반에 사용자 ID를 보존하고, 시도된 작업과 완료된 작업을 모두 기록해야 합니다.

영향이 큰 작업에는 신뢰할 수 있는 승인 컨텍스트가 필요합니다. 보안팀은 의도된 게이트웨이 경로만 검증하는 대신 보호 대상 리소스에 이르는 대체 경로를 정기적으로 테스트해야 합니다.

아마존과 구글의 클라우드 선택에서 이제 모델 벤치마크만으로는 충분하지 않습니다. 구매자는 기본 거부 동작, ID 전파, 정책 분석, 감사 세부 정보, 세션 제어, 적용 범위를 비교해야 합니다.

또한 모델과 프레임워크가 바뀌어도 정책이 어떻게 유지되는지 물어야 합니다. 특정 에이전트 구현에 지나치게 밀접하게 연결된 권한 부여는 마이그레이션 과정에서 유지 비용이 커지고 우회되기 쉬워집니다.

AWS는 분명한 아키텍처적 선택을 했습니다. 에이전트의 추론은 계속 조작될 수 있다고 가정하고, 에이전트 외부의 결정론적 제어를 통해 그 결과를 제한합니다.

이러한 가정은 모델의 완벽한 복종을 약속하는 것보다 더 신뢰할 수 있습니다. 실수와 공격이 발생할 수 있음을 인정하면서도, 도구와 데이터에 대한 별도의 권한을 유지합니다.

이 접근 방식은 여전히 엄격한 구성에 의존합니다. 과도한 권한을 가진 런타임, 관리되지 않는 셸, 또는 권한 부여 필터링 전에 가져온 데이터를 좁은 게이트웨이 정책만으로 보완할 수는 없습니다.

이제 엔터프라이즈 팀은 하나의 구체적인 워크플로를 처음부터 끝까지 테스트해야 합니다. 에이전트를 조작하고, 에이전트가 요청하는 작업을 관찰하며, 보호된 작업이 외부 경계에서 실패하는지 확인해야 합니다.

이 테스트는 아마존, 구글 및 기타 모든 에이전트 플랫폼에 실용적인 기준을 제시합니다. 모델은 속을 수 있지만, 인프라는 여전히 거부해야 합니다.