Thales Google Cloud AI Security, 제어 기능 추가했지만 자율성은 위험 부담 높여

Thales는 9월 28일 Google Cloud와의 파트너십을 확대하며, 가드레일이 자율 시스템을 얼마나 안정적으로 통제할 수 있는지를 둘러싼 의문이 해소되지 않은 가운데 AI 에이전트용 보안 제어 기능을 추가했다. Thales Google Cloud AI 보안 통합은 Thales AI Security Fabric과 Gemini Enterprise를 연결한다. 이는 사용자, 에이전트, 모델, 기업 데이터, 외부 도구 간 상호작용을 대상으로 한다.

이번 발표는 기업 AI의 더 큰 변화를 반영한다. 과거 어시스턴트는 주로 사람이 검토할 답변을 생성했다. 이제 에이전트는 도구를 선택하고, 민감한 기록을 조회하며, API를 호출하고, 비즈니스 시스템을 변경할 수 있다. 따라서 악의적인 지시나 과도한 권한은 단순히 부정확한 응답이 아니라 운영상 사고를 초래할 수 있다.

Google Cloud는 이미 Agent Gateway를 에이전트와 도구 간 연결을 위한 제어 지점으로 제시하고 있다. Thales는 이러한 연결 주위에 검사, 정책 집행, 위협 탐지 기능을 추가하고 있다. 이로써 양사의 파트너십은 기업용 에이전트를 위한 보안 계층을 정의하려는 Microsoft, Zscaler, Palo Alto Networks 및 기타 벤더와 같은 전략적 경쟁 구도에 놓이게 됐다.

핵심 질문은 더 이상 AI 에이전트에 추가 보호가 필요한지 여부가 아니다. 정부 지침과 독립적인 보안 연구는 이 문제를 이미 정리했다. 진짜 질문은 통합 런타임 계층이 에이전트를 일관되게 제약하면서도, 배포를 정당화할 만큼 빠르고 비용 효율적이며 충분히 유용하게 유지할 수 있는지다.

Thales Google Cloud AI 보안 통합이 바꾸는 점

이 파트너십은 AI 시스템이 데이터를 읽고, 도구를 선택하거나, 작업을 시도하는 바로 그 순간에 더 가까운 위치로 에이전트 보안을 이동시킨다.

보안 발표에 따르면, Thales AI Security Fabric은 Google Cloud Gemini Enterprise와 통합된다. Thales는 결합된 시스템이 사용자, 에이전트, 모델, 도구, 기업 정보를 아우르는 통신 전반에 가시성, 거버넌스, 보안 정책을 적용할 수 있다고 밝혔다.

의도된 적용 범위는 에이전트 워크플로의 여러 단계에 걸친다. 이 시스템은 에이전트로 유입되는 트래픽을 검사하고, 에이전트와 모델 간 교환을 관찰하며, 외부 도구 호출을 모니터링할 수 있다. 또한 에이전트가 접근할 수 있는 정보와 수행할 수 있는 작업에 제한을 적용하는 것을 목표로 한다.

이러한 구분이 중요한 이유는 에이전트가 하나의 고립된 모델 세션이 아니기 때문이다. 에이전트는 의사결정, 자격 증명, 데이터 소스, 소프트웨어 인터페이스가 연결된 사슬이다. 각각의 인계 지점은 공격자, 구성 오류, 또는 신뢰할 수 없는 모델 결정이 결과를 바꿀 수 있는 또 다른 지점을 만든다.

Thales는 프롬프트 인젝션, 데이터 유출, 안전하지 않은 출력, 무단 작업, 에이전트 간 통신을 핵심 위험으로 지목한다. 프롬프트 인젝션은 콘텐츠에 삽입된 적대적 지시가 모델의 행동을 조작하는 상황을 뜻한다. 이메일, 문서, 웹사이트 또는 도구 응답은 사용자가 알아차리지 못하는 사이 이러한 지시를 담을 수 있다.

파트너십이 제시하는 대응은 통합된 집행 계층이다. Thales는 자사의 패브릭이 AI 특화 위협을 탐지하고, 에이전트 행동의 가시성을 유지하며, 조직 정책을 위반하는 작업을 차단할 수 있다고 밝혔다. 회사는 또한 중앙화된 기록이 컴플라이언스 검토와 사고 조사에 도움이 된다고 설명한다.

Thales가 제시한 보험 사례를 살펴보자. 보험금 지급을 지원하도록 승인된 에이전트가 허용된 소스 밖의 개인정보를 참조할 수 있다. 지급액 계산이 합리적으로 보이더라도, 해당 워크플로는 개인정보 보호, 공정성, 컴플라이언스 문제를 일으킬 수 있다.

런타임 제어 기능은 워크플로 진행을 허용하기 전에 요청된 데이터 소스, 에이전트에 부여된 역할, 제안된 작업을 검토할 수 있다. 요청을 거부하거나, 시도된 접근을 기록하거나, 사람의 승인을 요구할 수 있다. 이는 사용자가 제출한 프롬프트만 필터링하는 방식과는 다른 보안 모델이다.

이 통합은 Google Cloud의 더 폭넓은 에이전트 아키텍처를 기반으로 한다. Agent Gateway 생태계는 사용자-에이전트, 에이전트-에이전트, 에이전트-도구 트래픽 전반에 걸쳐 거버넌스가 적용된 연결을 제공한다. Google은 이 게이트웨이를 여러 보안 제공업체와 연동할 수 있는 개방형 제어 지점으로 설명해 왔다.

따라서 Thales는 Google Cloud의 기본 제어 기능을 대체하는 것이 아니다. 대신 더 광범위한 아키텍처 안에서 특화된 검사 및 집행 계층을 제공한다. 그 가치는 얼마나 많은 추가 맥락을 분석할 수 있는지, 그리고 위험한 활동이 비즈니스 시스템에 도달하기 전에 얼마나 안정적으로 개입할 수 있는지에 달려 있다.

AI 에이전트에 모델 가드레일 이상의 제어 기능이 필요한 이유

시스템이 자격 증명을 보유하고 즉각적인 사람 검토 없이 행동할 수 있다면, 안전한 모델 응답이 안전한 워크플로를 보장하지는 않는다.

기존의 생성형 AI 보안은 흔히 콘텐츠에 초점을 맞춘다. 조직은 유해한 답변, 기밀 데이터 노출, 부적절한 프롬프트를 막으려 한다. 이러한 우려는 여전히 중요하지만, 에이전트는 실제 결과를 낳는 소프트웨어 작업이라는 또 다른 위험 범주를 도입한다.

에이전트는 지시를 받고, 계획을 세우고, 도구를 선택하고, 거래를 실행할 수 있다. 메시지를 보내거나, 고객 기록을 수정하거나, 환불을 승인하거나, 소스 코드를 변경하거나, 인프라 변경을 시작할 수 있다. 사람이 중간 추론 과정을 보기 전에 오류가 확산될 수 있다.

이 차이는 런타임 권한 부여가 핵심이 되는 이유를 설명한다. 정책은 에이전트가 무엇을 말하는지만이 아니라, 어떤 신원을 사용하는지, 어떤 리소스를 요청하는지, 해당 작업이 부여된 업무에 부합하는지도 평가해야 한다. 워크플로의 방향이 바뀔 때마다 이러한 결정이 다시 필요할 수 있다.

에이전트가 협업하면 문제는 더 어려워진다. 한 에이전트는 정보를 수집하고, 다른 에이전트는 권고안을 만들며, 세 번째 에이전트는 작업을 실행할 수 있다. 손상된 구성 요소는 조작된 맥락이나 요청을 나머지 체인에 전달할 수 있다.

Thales는 자사의 제어 기능이 이러한 에이전트 간 상호작용을 다룰 것이라고 밝혔다. 이 약속은 중요한 공백을 겨냥하지만, 그 가치는 구현 세부 사항에 따라 결정된다. 보안팀은 신원을 어떻게 검증하는지, 위임된 권한을 어떻게 표현하는지, 여러 에이전트에 걸친 작업에서 정책이 어떻게 유지되는지를 알아야 한다.

NIST도 같은 문제를 지적했다. NIST의 2026년 5월 에이전트 보안 분석은 에이전트가 새로운 위협을 초래한다는 폭넓은 합의를 확인했다. 응답자들은 익숙한 사이버 보안 관행도 여전히 유용하지만, 에이전트 시스템에 맞게 조정해야 한다고 말했다.

신원 관리는 이러한 조정의 한 사례다. 기존 애플리케이션은 예측 가능한 기능을 가진 안정적인 서비스 계정을 통해 작동하는 경우가 많다. 에이전트는 동적으로 계획을 구성하고, 변화하는 맥락에 따라 여러 도구 중 하나를 선택할 수 있다.

그러한 에이전트에 광범위한 자격 증명을 부여하면 유용성은 높아지지만 조작에 따른 피해도 커진다. 모든 권한을 사전에 제한하면 위험은 줄어들지만, 에이전트가 정당한 업무를 완료하지 못하게 될 수 있다. 보안팀은 유용한 자율성과 엄격히 제한된 피해 범위 사이에서 균형을 맞춰야 한다.

감사 기록도 또 다른 과제다. 조사자가 어떤 사용자가 작업을 시작했는지, 어떤 정보가 에이전트에 영향을 미쳤는지, 왜 작업이 권한을 받았는지를 파악할 수 없다면 도구 호출 로그만으로는 충분하지 않다. 유용한 기록은 사람의 의도, 에이전트 신원, 데이터 접근, 그리고 그에 따른 시스템 변경을 연결해야 한다.

Thales Google Cloud AI 보안 접근 방식은 워크플로 전반의 가시성을 통해 이 문제를 다룬다. 원칙적으로 공유 계층은 그렇지 않으면 모델, 신원, API, 애플리케이션 로그에 각각 분산되어 보이는 활동을 상관 분석할 수 있다.

이러한 가시성은 보안 운영팀이 비정상적인 행동을 식별하는 데 도움이 될 수 있다. 일반적으로 지역별 판매 데이터를 읽는 에이전트가 갑자기 직원 기록이나 낯선 외부 엔드포인트를 요청한다면 면밀한 검토가 필요하다. 정적 규칙으로 모든 유효한 순서를 예측할 수 없을 때 행동 맥락은 가치가 있다.

그러나 가시성이 곧 차단을 의미하지는 않는다. 대시보드는 피해가 발생한 뒤 사고를 설명할 수 있다. 더 강한 주장은 정책이 에이전트의 유용성을 만드는 정당한 변형을 차단하지 않으면서도, 안전하지 않은 작업을 실시간으로 중단할 수 있다는 것이다.

런타임 집행이 주요 경쟁 격전지로 부상

전략적 경쟁은 클라우드 플랫폼에 내장된 보안과 모델, 에이전트, 도구 전반에서 일관된 정책을 약속하는 독립적 제어 기능 사이에서 벌어진다.

Google Cloud는 단일 보안 공급업체에 의존하는 대신 Agent Gateway를 중심으로 파트너 생태계를 구축하고 있다. 공개된 참여 업체에는 Thales, Zscaler, Exabeam, Silverfort, Cisco, CrowdStrike, Palo Alto Networks 등이 포함된다. 각 벤더는 에이전트 워크플로의 서로 다른 부분을 다룬다.

Thales는 Imperva 애플리케이션 및 API 보안을 이 구조에 도입한다. Thales가 밝힌 적용 범위에는 클라이언트-에이전트 트래픽, 에이전트-모델 교환, 그리고 Model Context Protocol 같은 인터페이스를 사용하는 도구와의 상호작용이 포함된다. MCP는 AI 애플리케이션이 외부 데이터 및 소프트웨어 기능에 연결할 수 있도록 하는 프로토콜이다.

이 접근 방식은 기업 구매자에게 유연성을 제공한다. 기업은 Google의 인프라를 사용하면서 기존 보안 운영 환경에 맞는 추가 제어 기능을 선택할 수 있다. 또한 모델 제공업체가 제공하는 보호 장치에 전적으로 의존해야 한다는 압박을 줄일 수 있다.

그 대가는 복잡성이다. 여러 제품이 서로 다른 관점에서 동일한 워크플로를 검사할 수 있다. 보안팀은 어떤 구성 요소가 신원, 데이터 보호, 행동 분석, 권한 부여, 사고 대응을 담당하는지 결정해야 한다.

중복된 제어 기능은 심층 방어만큼이나 쉽게 공백을 만들 수 있다. 한 제품은 에이전트 신원을 기반으로 요청을 승인할 수 있지만, 다른 제품은 오용을 인식하는 데 필요한 작업 맥락이 부족할 수 있다. 세 번째 제품은 반환된 민감한 데이터를 이해하지 못한 채 도구 호출만 기록할 수 있다.

Microsoft는 보다 수직적으로 통합된 경로를 추구하고 있다. Microsoft의 에이전트 보안 전략은 신원, 접근 정책, 데이터 거버넌스, 생산성 애플리케이션을 연결한다. Microsoft Entra는 에이전트에 신원을 할당할 수 있으며, Purview 정책은 Microsoft 환경 내 민감한 정보를 관리한다.

이 모델은 이미 Microsoft 서비스 중심으로 운영되는 조직에 더 명확한 관리 경로를 제공한다. 동시에 익숙한 플랫폼 종속성 우려도 제기한다. 한 벤더의 애플리케이션에 최적화된 제어 기능은 워크플로가 여러 클라우드, 모델, 타사 도구를 넘나들 때 일관성이 떨어질 수 있다.

Google의 파트너 기반 아키텍처는 개방성을 핵심 강점으로 내세운다. 그러나 개방성은 통합 작업을 플랫폼과 고객에게 이전한다. 정책은 모든 인계 지점에서 유지되고, 프로덕션 트래픽에 충분히 빠른 속도로 결정을 내릴 수 있을 때만 유용하다.

독립 벤더들도 관련된 과제에 직면한다. 이들은 추가 계층이 또 하나의 모니터링 콘솔 이상을 제공한다는 점을 입증해야 한다. 구매자들은 집행 가능한 정책, 실용적인 조사 기능, 그리고 일상 업무를 방해하지 않으면서 위험을 줄인다는 증거를 기대할 것이다.

Thales는 Imperva가 이미 웹 애플리케이션과 API 주변에서 운영되고 있기 때문에 신뢰할 만한 위치에 있다. 에이전트 워크플로는 이러한 인터페이스를 다수 사용한다. 기존의 트래픽 검사, 봇 관리, API 보호 기능은 클라이언트를 식별하고 요청을 제어하는 기반을 제공할 수 있다.

에이전트의 행동은 여전히 기존 애플리케이션 트래픽과 다릅니다. 유효한 에이전트가 기술적으로는 유효한 API 요청을 하더라도 그 목적은 허용할 수 없을 수 있습니다. 이러한 차이를 감지하려면 사용자 의도, 위임된 권한, 데이터 민감도, 이전 작업의 순서에 관한 맥락이 필요합니다.

바로 이 지점에서 경쟁의 압박은 기존 웹 보안을 넘어섭니다. 공급업체는 에이전트 자체의 설명에 의존하지 않고도 에이전트의 운영 맥락을 해석해야 합니다. 조작된 모델은 안전하지 않은 호출에 대해 그럴듯한 근거를 제시할 수 있습니다.

클라우드 제공업체 역시 정보 측면에서 우위를 가집니다. 이들은 모델 서비스, ID 계층, 네트워크, 에이전트 플랫폼을 운영합니다. 파트너는 고객 프라이버시와 시스템 성능을 존중하면서도 정확한 판단을 내릴 수 있을 만큼 충분한 텔레메트리를 받아야 합니다.

따라서 가장 강력한 아키텍처는 계층형일 수 있습니다. 네이티브 클라우드 제어 기능은 기본적인 ID 및 격리를 강제하고, 전문 제품은 애플리케이션 동작과 민감한 데이터 이동을 검사합니다. 되돌릴 수 없거나 영향이 큰 결정에는 여전히 사람의 승인이 적절합니다.

이 경쟁은 가장 긴 기능 목록으로 결판나지 않을 것입니다. 기업은 각 아키텍처가 혼합 환경, 위임된 ID, 불완전한 맥락을 얼마나 잘 처리하는지 판단할 것입니다. 또한 사고 대응자가 서로 호환되지 않는 여러 로그를 이어 붙이지 않고도 워크플로를 재구성할 수 있는지 검토할 것입니다.

보안 약속에는 여전히 프로덕션 증거가 필요하다

Thales와 Google Cloud는 올바른 통제 지점을 제시하지만, 이번 발표는 적대적 압박 상황에서 해당 통제가 얼마나 정확하고 일관되게 작동하는지를 입증하지는 못한다.

두 회사는 이번 발표에서 배포 수치, 지연 시간 측정값, 독립 평가, 상세한 오탐률을 공개하지 않았습니다. 통합 패브릭이 프로덕션 환경에서 공격을 차단하는 모습을 보여주는 고객 사례 연구도 제시하지 않았습니다.

이러한 부재가 제품 방향의 타당성을 무효화하지는 않습니다. 다만 이번 출시만으로 도출할 수 있는 결론에는 한계가 있습니다. 이 통합은 에이전트형 워크플로가 이제 안전하다는 증거가 아니라, 확장된 보안 아키텍처로 보아야 합니다.

프롬프트 인젝션은 여전히 까다로운 시험대입니다. NIST의 2026년 3월 레드팀 결과는 간접 프롬프트 인젝션을 에이전트 하이재킹으로 설명합니다. 공격자는 에이전트가 나중에 처리할 외부 콘텐츠 안에 악의적인 지시를 삽입합니다.

이러한 공격은 근본적인 모호성을 악용합니다. 모델은 정당한 지시와 신뢰할 수 없는 정보를 유사한 텍스트 형태로 모두 받습니다. 악성 콘텐츠가 그 경계를 흐리도록 설계되었을 때에도, 분석해야 할 데이터와 따라야 할 명령을 구분해야 합니다.

런타임 정책은 피해를 줄일 수 있습니다. 삽입된 지시가 에이전트를 설득해 기밀 기록을 요청하도록 만들 수는 있지만, 별도의 권한 부여 계층은 여전히 그 요청을 거부할 수 있습니다. 이 통제 기능은 모델이 왜 잘못된 결정을 내렸는지 정확히 판단할 필요가 없습니다.

이러한 분리는 파트너십의 가장 강력한 아이디어 중 하나입니다. 데이터 접근과 도구 사용에 대한 결정론적 제한은 모델 수준 가드레일이 놓치는 실패를 억제할 수 있습니다. 최소 권한 자격 증명과 사람의 승인은 영향을 더욱 줄일 수 있습니다.

그러나 정책 엔진에는 정확한 맥락이 필요합니다. 어떤 사용자가 작업을 승인했는지, 에이전트가 어떤 목적을 수행하는지, 어떤 리소스가 필요한지를 알아야 합니다. 광범위하거나 부실하게 관리되는 정책은 기술적으로 진보한 통제 계층을 허용적인 관문으로 바꿔버릴 수 있습니다.

오탐은 반대 방향의 실패를 만듭니다. 에이전트가 반복해서 승인을 위해 멈추거나 일상적인 데이터에 접근하지 못한다면, 직원들은 이를 피할 수 있습니다. 관리자는 정책을 완화해 결국 집행이 실질적인 보호를 제공하지 못하게 할 수 있습니다.

지연 시간도 중요합니다. 모든 검사 단계는 처리 시간을 추가합니다. 단일 상호작용에서는 영향이 작을 수 있지만, 수십 건의 모델 요청과 도구 호출이 포함된 워크플로에서는 상당할 수 있습니다. 조직에는 현실적인 멀티 에이전트 배포 환경의 측정값이 필요합니다.

암호화와 프라이버시는 또 다른 긴장을 더합니다. 보안 도구는 민감한 정보와 악의적인 지시를 식별할 수 있을 만큼의 가시성이 필요합니다. 고객은 어떤 콘텐츠가 검사되는지, 어디에서 처리되는지, 얼마나 오래 보관되는지, 누가 접근할 수 있는지에 관한 명확한 설명을 원할 것입니다.

문제는 한 제품에 국한되지 않습니다. OWASP 에이전트 위험에는 목표 하이재킹, 도구 오용, ID 악용, 메모리 오염, 안전하지 않은 에이전트 간 통신, 연쇄적 실패가 포함됩니다. 단일 트래픽 필터로 모든 범주를 해결할 수는 없습니다.

메모리 오염은 유용한 사례입니다. 공격자는 에이전트가 나중에 사용하도록 저장하는 거짓 또는 악의적인 정보를 심을 수 있습니다. 런타임 통제 기능은 원래 입력을 검사할 수 있지만, 유해한 영향은 며칠 뒤 다른 워크플로에서 나타날 수 있습니다.

연쇄적 실패도 마찬가지로 어렵습니다. 한 에이전트가 다른 에이전트에게 신뢰할 만해 보이는 부정확한 결과를 생성할 수 있습니다. 개별 도구 호출은 각각 정책을 충족할 수 있지만, 전체 워크플로는 유해한 결과로 향할 수 있습니다.

따라서 조직에는 심층 방어가 필요합니다. 제한된 권한, 샌드박싱, 서명된 ID, 보호된 메모리, 검증된 도구, 지속적 모니터링, 사람의 검토를 결합해야 합니다. 보안 테스트는 고립된 모델 응답이 아니라 완전한 워크플로를 다뤄야 합니다.

정부 지침도 이러한 입장을 뒷받침합니다. 호주의 에이전트 도입 지침은 사람의 통제 지점, 지속적 모니터링, 최소 권한, 여러 겹의 방어를 권고합니다. 또한 자율성은 점진적으로 확대할 것을 조언합니다.

Thales AI Security Fabric은 이러한 방어 수단 중 하나가 될 수 있습니다. 이번 발표만으로 이를 전체 보안 프로그램으로 간주할 근거는 부족합니다. 구매자는 이것이 기존의 ID 시스템, 개발 통제, 사고 대응, 승인 절차와 어떻게 상호작용하는지 물어야 합니다.

에이전트 보안이 워크플로로 이동하면서 압박을 받는 주체들

보안 공급업체, 클라우드 플랫폼, 기업 구매자는 이제 에이전트 거버넌스를 문서화된 정책에서 집행 가능한 소프트웨어로 전환해야 한다는 압박을 받고 있다.

클라우드 제공업체는 가장 즉각적인 기대에 직면합니다. 고객이 에이전트를 실험 단계에서 비즈니스 운영으로 옮기기를 원하지만, 법무 및 보안 팀이 허용 가능한 경계를 정의하지 못하면 도입은 멈춥니다. ID, 접근 권한, 감사 가능성에 대한 기본적인 질문에 답하지 못하는 플랫폼은 민감한 배포 환경에서 어려움을 겪을 것입니다.

Google Cloud의 대응은 Agent Gateway를 공통 집행 지점으로 구축하고 전문 파트너들로 이를 보완하는 것입니다. Thales는 하나의 보안 패브릭을 통해 애플리케이션, API, 모델, 도구 상호작용을 포괄함으로써 이 전략을 강화합니다.

Thales는 이처럼 넓은 범위가 계속 관리 가능하다는 점을 보여줘야 합니다. 고객에게 여러 기술 계층 전반의 일관된 가시성을 제공하는 것이 이 회사의 가치 제안에 달려 있습니다. 분절된 정책이나 중복 경보는 통합의 이점을 약화시킬 것입니다.

경쟁 보안 공급업체 역시 동등하게 광범위한 보호 범위를 입증해야 한다는 압박을 받습니다. 프롬프트만 보호하는 것으로는 더 이상 충분하지 않습니다. 구매자에게는 자격 증명, 도구 실행, 데이터 이동, 메모리, 에이전트 간 메시지, 외부 작업을 위한 통제가 필요합니다.

ID 제공업체도 새로운 업무 부담에 직면합니다. 에이전트에는 고유한 ID, 제한된 권한, 추적 가능한 소유권, 관리 가능한 수명 주기가 필요합니다. 임시 에이전트가 작업 종료 후 영구적인 자격 증명을 남겨서는 안 됩니다.

애플리케이션 소유자에게도 또 다른 부담이 있습니다. 에이전트가 어떤 작업을 어떤 조건에서 수행할 수 있는지 정의해야 합니다. 워크플로를 이해하는 사람들의 운영상 입력 없이는 보안 팀이 유용한 정책을 만들 수 없습니다.

개발자는 더 구조화된 맥락을 제공해야 합니다. 도구 호출이 작업, 사용자, 요청 리소스, 의도된 효과를 명시하면 보안 계층은 더 나은 결정을 내릴 수 있습니다. 비구조화된 프롬프트만으로는 권한 부여의 기반이 약합니다.

기업 구매자는 조달을 거버넌스의 종착점으로 여기는 유혹을 경계해야 합니다. 보안 패브릭을 설치한다고 허용 가능한 자율성이 결정되는 것은 아닙니다. 조직은 여전히 사용 사례를 분류하고, 소유자를 지정하고, 에스컬레이션 지점을 정의하고, 실패 시나리오를 테스트해야 합니다.

저위험 사용 사례는 합리적인 출발점입니다. 승인된 내부 문서로 보고서 초안을 작성하는 에이전트는 메시지를 보내거나 고객 계정을 수정하는 에이전트보다 피해 범위가 작습니다. 권한은 평가를 통해 워크플로가 계속 통제되고 있음이 확인된 후에만 확대해야 합니다.

영향이 큰 작업에는 명시적인 승인이 필요합니다. 금융 이체, 프로덕션 변경, 법적 커뮤니케이션, 인사 결정, 민감한 데이터 공개는 모델의 자신감에만 의존해서는 안 됩니다. 사람의 검토는 워크플로를 늦출 수 있지만, 그러한 마찰은 오류의 결과를 반영합니다.

지식 근로자는 이러한 통제가 업무용 에이전트가 보고 수행할 수 있는 일을 결정하기 때문에 관심을 가져야 합니다. 더 나은 보안은 에이전트가 유용한 내부 정보에 접근하도록 할 수 있습니다. 부실하게 설계된 통제는 지나치게 많은 데이터를 노출하거나 정확한 업무에 필요한 맥락을 차단할 수 있습니다.

직원에게도 투명성이 필요합니다. 에이전트가 자신의 ID로 행동하는 시점, 접근한 기록, 그 결과물이 외부 변경을 유발하는지를 알아야 합니다. 사고가 발생했을 때 숨겨진 자동화는 책임 소재를 어렵게 만듭니다.

더 큰 변화는 조직적입니다. AI 보안은 모델 평가 업무에서 일상적인 ID 및 애플리케이션 관리로 옮겨가고 있습니다. 이는 에이전트를 직원, 서비스, 공급업체, 소프트웨어 배포에 적용되는 것과 같은 운영 규율 아래에 둡니다.

Thales Google Cloud AI 보안 파트너십이 중요한 이유는 이러한 전환을 명확히 드러내기 때문입니다. 성공 여부는 발표 자체보다 기업이 또 다른 단절된 거버넌스 계층을 만들지 않고 통제 기능을 적용할 수 있는지에 달려 있습니다.

통제 기능의 작동 여부를 보여줄 세 가지 신호

다음 시험대는 측정 가능한 배포 증거이며, 그 뒤를 플랫폼 간 상호운용 가능한 ID와 신뢰할 수 있는 적대적 평가가 이을 것이다.

첫 번째 신호는 결과가 공개된 프로덕션 도입입니다. Thales 또는 Google Cloud는 워크플로, 권한, 차단된 동작, 운영 오버헤드를 설명하는 고객 사례를 공개해야 합니다. 유용한 증거에는 탐지 정확도, 승인 빈도, 지연 시간, 사고 대응 결과가 포함됩니다.

고객이 보안 에이전트를 배포했다는 모호한 설명만으로는 알 수 있는 것이 거의 없습니다. 가장 강력한 사례 연구는 통제 기능이 현실적인 프롬프트 인젝션이나 무단 도구 호출을 어떻게 차단했는지 보여줄 것입니다. 또한 정상적인 활동이 얼마나 자주 중단되었는지도 설명해야 합니다.

이러한 증거가 나타난다면 런타임 집행이 실용적인 에이전트 배포를 지원할 수 있다는 주장을 강화할 것입니다. 고객이 계속 익명으로 남고 측정값도 비공개라면, 구매자는 이 통합을 유망하지만 검증되지 않은 것으로 보아야 합니다.

두 번째 신호는 플랫폼 전반에서 더 강력한 ID 및 권한 부여가 이루어지는 것입니다. NIST는 이미 에이전트 식별, 위임, 감사, 부인 방지와 관련된 문제를 강조했습니다. 시장에는 어떤 에이전트가 누구를 위해, 어떤 권한으로 행동하는지 일관되게 증명할 방법이 필요합니다.

기업 워크플로는 한 공급업체의 환경 안에만 머무는 경우가 드물기 때문에 상호운용성이 중요합니다. 에이전트는 Google 모델을 사용하고, 타사 데이터베이스를 조회하고, Microsoft 애플리케이션을 호출하고, 내부 개발 도구를 실행할 수 있습니다.

정책은 하나의 재사용 가능한 자격 증명에 광범위한 접근 권한을 부여하지 않고도 이 워크플로를 따라야 합니다. 특정 작업에 연결된 단기 권한 부여는 위험을 줄일 수 있습니다. 검증 가능한 기록은 모든 중대한 작업을 에이전트와 책임 있는 사람 또는 서비스 모두에 연결해야 합니다.

개방형 ID 표준의 진전은 Google Cloud의 파트너 전략을 강화할 것이다. 반면 파편화가 지속되면 기술 스택의 더 많은 부분을 통제하는 긴밀히 통합된 플랫폼에 유리하게 작용할 것이다.

세 번째 신호는 독립적인 적대적 테스트다. Thales와 Google Cloud는 간접 프롬프트 인젝션, 악성 도구 출력, 자격 증명 오용, 메모리 오염, 손상된 에이전트에 맞서 통합 시스템을 테스트해야 한다. 평가는 공격 탐지 여부뿐 아니라 격리 수준을 측정해야 한다.

유용한 테스트는 모델이 실패한다고 가정하는 방식이 될 것이다. 이후 외부 통제가 데이터 유출이나 무단 시스템 변경을 막는지 살펴본다. 이는 모델 안전성 주장과 주변 아키텍처가 제공하는 실질적인 보안 가치를 구분한다.

독립 연구자들은 멀티 에이전트 워크플로에서 발생하는 우회 가능성도 검토해야 한다. 정책이 하나의 직접 요청은 차단하면서도, 각각은 허용 가능한 여러 행동이 결합해 동일한 금지 결과를 낳는 것은 허용할 수 있다.

이번 출시는 적절한 시점에 이뤄졌다. 기업들은 에이전트가 정보를 요약하는 수준을 넘어 더 많은 일을 하기를 원하고, 규제 기관과 보안팀은 더 명확한 책임성을 요구한다. 이러한 압력은 런타임 제어를 선택 기능이 아니라 필수 요건으로 만든다.

그럼에도 자율성이 높아질수록 입증 책임도 커진다. 에이전트에 더 큰 권한이 부여될수록 구매자는 ID, 권한, 정책, 감사 기록이 공격 상황에서도 함께 작동한다는 더 많은 증거를 필요로 한다.

Thales Google Cloud AI 보안 통합을 평가하는 조직은 범위가 제한된 하나의 워크플로와 명확한 실패 예산으로 시작해야 한다. 모든 도구, 자격 증명, 데이터 소스, 되돌릴 수 없는 작업을 매핑하라. 이어서 제어 수단이 사용자에게 승인 절차를 과도하게 요구하지 않으면서 오용을 막는지 테스트해야 한다.

결정적인 질문은 실무적이다. 파트너십은 워크플로가 변경될 때마다 에이전트의 광범위한 역량을 좁게 승인된 행동으로 전환할 수 있는가? 운영 환경의 측정치, 상호운용 가능한 ID, 독립 테스트가 그 답을 제공할 것이다.