LLM 가드레일이란 무엇인가요?
LLM 가드레일은 AI 기반 애플리케이션이 프로덕션에서 어떻게 동작하는지 제한하는 기술적 통제입니다. 모델 자체를 수정하는 대신, 가드레일은 모델이 볼 수 있는 것, 말할 수 있는 것, 할 수 있는 것을 모든 요청에 대해 관리하는 정책으로 모델에 감싸줍니다.
가드레일은 추론 시간에 작동하며 애플리케이션과 그 주변 인프라에 의해 강제됩니다. 프롬프트가 모델에 도달하기 전에 입력을 검증하고, 응답이 사용자에게 도달하기 전에 출력을 검사하며, 도구, API, 데이터 소스, 클라우드 자원에 대한 접근을 엄격히 통제합니다.
가드레일을 다른 관련 안전 메커니즘과 구분하는 것이 중요합니다:
모델 정렬(훈련 시간): 인간 피드백을 통한 강화 학습(RLHF)과 같은 정렬 기법은 훈련 중 모델의 기본 행동을 형성합니다. 이렇게 하면 전반적인 안전성과 유용성이 향상되지만, 정적인 상태이고 애플리케이션의 맥락이나 정책을 인지하지 못합니다.
제공자 콘텐츠 필터 (서비스 수준): 클라우드 제공업체들은 증오 발언이나 폭력 같은 광범위한 콘텐츠를 차단하는 내장 필터(예: Azure OpenAI 콘텐츠 필터링이나 Amazon Bedrock Guardrails)를 제공합니다. 이들은 API 계층에서 동작하며 의도적으로 일반적입니다.
LLM 가드레일 (애플리케이션 수준): 가드레일은 당신이 설계하고 설정하여 강제하는 통제 수단입니다 너 보안과 비즈니스 규칙. 사용자, 역할, 환경, 사용 사례에 따라 달라질 수 있으며, 애플리케이션이 변화함에 따라 진화합니다.
AI 에이전트 25명. 257번의 진짜 공격. 누가 이길까?
제로데이 디스커버리부터 클라우드 권한 강화에 이르기까지, 우리는 257개의 실제 공격적 보안 과제에서 25개의 에이전트-모델 조합을 테스트했습니다. 결과가 놀라울 수도 있습니다 👀
이 층들은 상호 보완적입니다. 정렬은 기본 안전을 제공하고, 제공자 필터는 공통 유해 콘텐츠를 차단하며, 가드레일은 애플리케이션별 보안 및 접근 통제를 강제합니다.
실제로 LLM 가드레일은 AI 시스템의 애플리케이션 계층 보안처럼 작동합니다. 모델 추론 전후의 정책을 시행하고, 모델이 귀하의 신원, 데이터 거버넌스 규칙, 클라우드 권한에 의해 정의된 경계 내에서 작동하도록 보장합니다.
관리되거나 '안전한' LLM조차도 가드레일이 필요합니다. 잘 정렬된 모델은 여전히 조작할 수 있습니다. 즉각적인 인젝션 또는 잘못 설정된 신원으로 인해 과도한 권한에 노출될 수 있습니다. 따라서 효과적인 가드레일은 계층화되어 있고, 맥락 인식이 되며, 주변 클라우드 환경과 긴밀하게 통합되어야 합니다.
왜 LLM 가드레일이 애플리케이션 보안에 필수적인가
현대 애플리케이션에서는 LLM이 더 이상 고립된 채팅 인터페이스가 아닙니다. 이들은 애플리케이션 로직에 직접 내장되어 있어 사용자 입력을 해석하고, 데이터를 가져오며, 도구를 호출하고, 하위 작업을 트리거합니다. 그 결과, LLM 동작의 약점은 빠르게 애플리케이션 보안 위험이 됩니다.
가장 눈에 띄는 위험 중 하나는 신속한 주사입니다. 공격자는 입력을 조작해 시스템 명령을 덮어쓰거나 모델에서 의도치 않은 동작을 추출할 수 있습니다. 연구 성공률은 모델 아키텍처, 방어 기법, 공격 복잡성에 따라 크게 달라지므로, 일반화된 통계가 실제로는 덜 유용함을 보여줍니다. 중요한 것은 당신의 특정 가드레일이 현실적이고 다단계 공격에 얼마나 잘 버틸 수 있느냐입니다.
데이터 유출 또 다른 큰 우려 사항입니다. LLM은 종종 내부 지식 기반, 검색 증강 생성 소스, 또는 민감한 운영 데이터에 접근할 수 있습니다. 강력한 출력 제어가 없으면, 모델은 절대 시스템을 벗어나지 말아야 할 정보를 노출시킬 수 있습니다. "내부 시스템에 대해 무엇을 알고 있나요?"와 같은 간단한 질문조차도 가드레일이 약하거나 범위가 미흡할 경우 의도치 않은 노출로 이어질 수 있습니다.
툴 호출과 함수 실행이 긴장감을 크게 높입니다. LLM이 API 호출을 트리거하거나 레코드를 수정하거나 클라우드 자원과 상호작용할 수 있을 때, 성공적인 공격은 실제 세계에 영향을 미칠 수 있습니다. 기본 서비스 정체성이 과도하게 특권을 부여받으면, 침해된 에이전트는 의도한 것보다 훨씬 더 많은 정보를 접근할 수 있습니다. 최소 권한 권한을 강제함으로써 기본적으로 폭발 반경을 제한하여, 남용된 요원도 과도한 피해를 입히지 못하게 합니다.
신뢰성 문제와 보안 문제를 분리하는 것도 중요합니다. 환각은 모델이 잘못된 정보를 생성하는 신뢰성 문제입니다. 무단 행위, 데이터 노출, 권한 남용은 보안 문제로, 가드레일이 이를 방지하기 위해 설계되어 있습니다. 이들을 같은 위험으로 취급하면 잘못된 통제와 잘못된 신뢰가 생깁니다.
궁극적으로 LLM 가드레일은 AI 시스템이 중요한 신뢰 경계에 위치하기 때문에 중요합니다. 신뢰할 수 없는 입력을 신뢰할 수 있는 행동으로 전환합니다. 신원, 데이터 접근, 클라우드 권한에 연결된 강력하고 층층적인 보호막이 없으면, AI 애플리케이션은 공격 표면을 통제하기보다는 확장하게 됩니다.
현대 AI 애플리케이션 스택에서 LLM 가드레일이 어디에 위치하는지
LLM 가드레일은 단일 제어 지점에 존재하지 않고 전체 AI 애플리케이션 스택을 아우릅니다. 이들이 어떻게 함께 작동하는지 이해하려면 애플리케이션, API, 아이덴티티, 데이터, 런타임 및 인프라의 다섯 계층에 걸친 가드레일을 보는 것이 도움이 됩니다.
애플리케이션 계층, 가드레일은 프롬프트와 응답 처리 방식을 결정합니다. 입력 검증은 사용자의 프롬프트에서 악의적인 패턴을 확인하며, 응답 정책은 출력이 형식, 안전 및 공개 규칙을 준수하도록 보장합니다. 많은 팀들이 여기서 프롬프트 레벨 컨트롤로 시작하지만, 이는 전체 위험의 아주 좁은 부분만을 다룹니다.
그 API 계층 애플리케이션이 LLM 서비스와 어떻게 상호작용하는지를 규율합니다. 이 단계의 가드레일에는 인증, 역할 기반 권한, 속도 제한, 토큰 사용 제한이 포함됩니다. 이들은 익숙한 웹 보안 통제 장치이지만, 단일 요청이 큰 자원을 소모하거나 하위 작업을 촉발할 수 있는 AI 엔드포인트에서 특히 중요해집니다.
그 정체층 LLM 기반 구성 요소가 클라우드 자원에 접근하기 위해 사용하는 서비스 계정과 역할에 중점을 둡니다. 신원 가드레일은 최소 권한 접근을 강제하여 AI 에이전트가 명시적으로 허용된 작업만 수행할 수 있도록 합니다. 신원 권한이 너무 광범위하면, 애플리케이션 수준의 가드레일이 효과를 잃게 됩니다.
그 데이터 계층 LLM이 접근할 수 있는 데이터셋, 임베딩, 검색 소스를 제어합니다. 데이터 가드레일은 어떤 모델이 어떤 데이터를 읽을 수 있는지, 민감한 정보를 어떻게 처리하는지, 사용자 또는 역할별로 검색 범위를 어떻게 정의하는지 정의합니다. 이러한 통제는 학습 파이프라인이나 검색 증강 생성을 통한 의도치 않은 데이터 노출을 방지하는 데 매우 중요합니다.
그 런타임 및 인프라 계층 컨테이너, 관리형 LLM 서비스, 네트워크 경계 등 AI 서비스가 실행되는 환경을 다룹니다. 이 계층의 가드레일에는 네트워크 격리, 워크로드 세분화, 런타임 시 이상 동작 감지가 포함됩니다. 이러한 조작은 이전 판정을 우회하는 실제 공격을 잡는 데 도움을 줍니다.
실제로는 이러한 계층의 소유권이 팀 간에 분산되어 있습니다. 애플리케이션 팀은 프롬프트와 로직을, 플랫폼 팀은 API와 아이덴티티를 관리하며, 클라우드 보안 팀은 인프라를 관리합니다. LLM 가드레일은 모든 곳에서 조정이 필요합니다. 심층 방어는 계층 간 통제가 정렬되고 일관되게 집행될 때만 작동합니다.
GenAI 보안 모범 사례 치트 시트
이 치트 시트는 조직의 GenAI 보안 태세를 강화하기 위해 채택할 수 있는 7가지 모범 사례에 대한 실용적인 개요를 제공합니다.
LLM 가드레일의 핵심 유형(그리고 실제로 보호하는 것)
대부분의 LLM 가드레일은 소수의 범주로 나뉩니다. 각 기관은 시스템의 다른 부분을 보호하며, 명확한 한계가 있습니다. 이러한 한계를 이해하는 것이 매우 중요합니다. 왜냐하면 어떤 하나의 가드레일도 모든 공격을 단독으로 막을 수 없기 때문입니다.
입력 가드레일
입력 가드레일은 사용자와 모델 사이에 위치합니다. 그들의 목표는 악의적이거나 위험한 프롬프트가 LLM에 도달하기 전에 감지하고 차단하는 것입니다. 일반적인 기법으로는 패턴 매칭, 프롬프트 분류, 명령어 경계 강제가 있습니다.
입력 가드레일은 명백한 공격을 막을 수 있지만, 인코딩, 간접 표현, 다중 턴 대화로 쉽게 우회할 수 있습니다. 따라서 이들은 주요 방어선이 아니라 초기 필터로 취급되어야 합니다.
출력 가드레일
출력 가드레일은 사용자에게 반환되기 전에 모델 응답을 검사합니다. 민감한 데이터 삭제, 허용되지 않은 주제 차단, 구조화된 출력 형식 요구와 같은 규칙을 강제합니다.
이러한 통제는 우발적인 데이터 유출을 줄이는 데 도움을 주지만, 탐지 정확도에 의존합니다. 새로운 공격 기법이나 미묘한 데이터 노출이 특히 출력이 길거나 동적으로 생성될 때 누락될 수 있습니다.
공구 및 기능 가드레일
도구와 기능 가드레일은 LLM이 외부 API를 호출하거나 코드를 실행할 수 있을 때 취할 수 있는 동작을 제어합니다. 이 지점에서 AI 위험은 이론에서 운영상으로 넘어갑니다.
효과적인 통제 방법은 다음과 같습니다:
역할별 액션 허용 목록
각 역할이 호출할 수 있는 도구를 정의하세요. 지원 상담원의 LLM은 문서를 검색하거나 티켓을 생성할 수 있지만, 청구 기록을 수정하거나 계정을 삭제해서는 안 됩니다.실행 전 정책 검사
실행 전에 모든 툴 호출을 검증하세요. 사용자가 권한이 있고, 해당 동작이 현재 맥락에서 허용되며, 요청이 비즈니스 규칙이나 속도 제한을 위반하지 않는지 확인하세요.고위험 행동에 대한 인간의 승인
데이터 삭제, 금융 거래, 권한 변경과 같은 파괴적이거나 민감한 작업에 대해서는 명시적인 인간 확인을 요구합니다.범위 및 특권 집행
도구 호출이 기본 서비스 정체성의 권한을 초과하지 않도록 보장합니다. LLM이 읽기 전용 식별 방식으로 실행된다면, 모델이 권장하더라도 쓰기 작업을 트리거할 수 없어야 합니다.다중 에이전트 경계 제어
여러 에이전트가 상호작용할 때는 엄격한 경계를 설정하세요. 고객 대면 에이전트는 명시적 권한과 검증 없이 다른 에이전트가 소유한 관리 도구를 직접 호출해서는 안 됩니다.
도구 가드레일은 남용 위험을 줄이지만, 서비스 신원이 과도하게 특권을 부여받을 경우 실패합니다. 이로 인해 신원 제어가 애플리케이션 논리만큼 중요해집니다.
신원 및 허가 가드레일
아이덴티티 가드레일은 LLM 기반 구성 요소가 사용하는 클라우드 역할과 서비스 계정을 관리합니다. 그들의 목표는 AI 서비스가 진정으로 필요한 자원에만 접근할 수 있도록 최소 권한 접근을 강제하는 것입니다.
이 가드레일은 문제가 생겼을 때 폭발 반경을 제한하지만, 실제 환경에서는 자주 잘못 설정됩니다. 과도한 권한은 잘 설계된 애플리케이션 수준의 제어조차도 조용히 약화시킬 수 있습니다.
데이터 접근 가드레일
데이터 가드레일은 모델이 접근할 수 있는 데이터셋, 임베딩, 검색 소스를 제어합니다. 민감한 정보가 적절한 허가 없이 프롬프트나 응답에 끌어들이는 것을 방지합니다.
이러한 통제는 정확한 데이터 분류와 접근 정책에 의존합니다. 데이터가 잘못 표시되거나 접근 규칙이 너무 광범위하면 가드레일의 효과가 떨어집니다.
런타임 가드레일
런타임 가드레일은 실제로 프로덕션에서 일어나는 일을 모니터링합니다. API 호출, 신원 활동, 클라우드 텔레메트리 전반에 걸친 행동을 분석하여 이상 현상과 오용을 감지합니다.
런타임 감지 초기 통제를 통과하는 우회를 포착하는 데 도움이 되지만, 오탐을 줄이기 위해서는 기준선과 조정이 필요합니다. 신원 권한과 데이터 민감도에 관한 맥락과 결합되면, 런타임 신호는 훨씬 더 실행 가능해집니다.
LLM 보안 모범 사례 [치트 시트]
이 7페이지 분량의 체크리스트는 실제 위협에 매핑된 수명 주기 전반에 걸쳐 LLM을 보호하는 데 도움이 되는 실용적이고 구현 준비가 된 단계를 제공합니다.
클라우드 환경에서 LLM 가드레일 구현
프로토타입에서 본격적인 AI 애플리케이션으로 전환하면 가드레일 구현의 복잡성이 크게 증가합니다. 클라우드에서 모델이 어디서 어떻게 실행되는지가 그 통제의 효과에 직접적인 영향을 미칩니다.
관리형 LLM 서비스는 유용한 기본 보호 기능을 제공하지만, 애플리케이션 및 클라우드 수준의 보안 통제를 완전히 없애지는 못합니다. Azure OpenAI는 네트워크 격리를 지원합니다. 프라이버시 엔드포인트를 사용하는 Azure Private Link인증용 관리 신원도 포함됩니다. 아마존 베드락은 기본 콘텐츠 필터링을 넘어서는 내장 보호 장치를 제공하며, 거부된 주제, 맥락 기반 확인, 자동 추론을 이용한 환각 감지 등이 포함됩니다. Google Vertex AI는 콘텐츠 안전 필터를 제공하며 VPC 서비스 제어와 통합하여 데이터 유출을 제한합니다.
Vertex AI 보안 모범 사례 치트 시트
명확한 권고사항, 실제 통제 장치, 실행 가능한 단계가 포함된 Vertex AI 보안 관리 치트 시트를 탐색해 보세요.
이러한 관리된 기능들은 특정 위험 유형을 줄여주지만, 중요한 결정은 여전히 고객의 책임입니다. Teams는 여전히 네트워크 노출, 신원 권한, 데이터 접근 정책, 로그 설정을 통제합니다. 클라우드 네이티브 제어 보안 어떻게 서비스는 접속되지만 완전히 해결하지는 않습니다 모델의 동작 애플리케이션 내에서 말이죠. 프롬프트 인젝션, 도구 오용, 논리 남용 같은 위험은 여전히 애플리케이션 계층에서 맞춤형 가드레일을 통해 처리되어야 합니다.
이로 인해 공동 책임 모델 클라우드 제공자와 애플리케이션 소유자 간의 문제입니다. 제공업체는 기본 플랫폼을 보호하고 기본 보호를 제공하며, 고객은 비즈니스 특화 정책, 최소 권한 접근, 그리고 문맥 기반 가드레일을 집행할 책임이 있습니다.
다중 테넌트 및 공유 클라우드 환경은 추가적인 위험을 초래합니다. 단일 잘못 구성된 VPC, 공개 접근 가능한 AI 엔드포인트, 혹은 지나치게 광범위한 IAM 역할이 모델 로직을 변경하지 않고도 애플리케이션 수준의 가드레일을 조용히 약화시킬 수 있습니다.
클라우드 오구성 흔히 발생하는 고장 지점입니다. AI 서비스가 인터넷에 노출되거나 고도로 특권화된 신원으로 운영될 때, 공격자들은 기본 클라우드 API를 악용해 즉흥 검증과 도구 제어를 완전히 우회할 수 있습니다. 이러한 상황에서는 가드레일이 테스트 중에는 효과적일 수 있지만, 실제 생산 환경에서는 거의 보호를 제공하지 못할 수 있습니다.
가드레일 드리프트도 또 다른 도전 과제입니다. 개발 또는 스테이징 환경에서 존재하는 통제 장치는 긴급 변경, 새로운 파이프라인 또는 인프라 업데이트로 인해 운영 환경에서 약화되거나 제거될 수 있습니다. 시간이 지나면서 이 드리프트는 공격자가 이용할 수 있는 틈을 만듭니다.
효과적인 가드레일을 유지하려면 전 생애주기 동안 지속적인 검증이 필요합니다. 컨트롤은 개발부터 배포, 런타임까지 일관되게 시행되어야 합니다. 가드레일 점검을 CI 및 CD 파이프라인에 통합하면 생산 단계에 도달하기 전에 잘못된 구성을 발견할 수 있습니다.
심층 방어는 애플리케이션 계층의 가드레일, 신원 권한, 데이터 접근 정책, 인프라 통제가 시스템이 진화함에 따라 정렬될 때만 효과가 있습니다. 클라우드 네이티브 보호 강화 AI 보안하지만 모델 동작을 직접 다루는 견고하고 응용 분야별 가드레일의 필요성을 대체하지는 못합니다.
왜 LLM 가드레일이 실패하는지, 그리고 공격자가 어떻게 이를 우회하는지도
선의의 가드레일 배치조차도 현실적인 압박 속에서 실패하는 경우가 많습니다. 공격자가 통제 장치를 우회하는 방법을 이해하는 것은 운영 환경에서 견고한 가드레일을 설계하는 데 필수적입니다.
즉각적인 주입은 여전히 가장 눈에 띄는 약점입니다. 공격자들은 거의 단일 악성 프롬프트에만 의존하지 않습니다. 대신 다중 턴 상호작용, 역할 조작, 간접 지시를 사용해 점차 시스템 의도를 덮어쓴다. 개별 프롬프트만 평가하는 가드레일은 이러한 패턴을 놓치는 경우가 많아 시간이 지남에 따라 해로운 행동이 드러나게 합니다.
실제 악성코드 캠페인에서는 악성 페이로드에 프롬프트를 삽입해 런타임 동작을 유도하는 방법을 탐구하기 시작했습니다. 예를 들어, 라임허그 악성코드는 base64로 인코딩된 프롬프트를 LLM에 보내 시스템 정찰 명령을 요청하며 감염된 호스트에 대한 정보를 수집하려 시도했습니다. 이 경우 모델은 사용자와 상호작용하지 않고 침해된 환경 내에서 호출되어 사용자 입력 차단을 완전히 우회했습니다.
출력 필터링에 과도하게 의존하는 것도 흔한 실패입니다. 허용되지 않은 콘텐츠의 응답을 스캔하는 필터는 인코딩, 난독화, 또는 명백히 위험한 텍스트를 생성하지 않고 유해한 행동을 유발하는 방식으로 우회할 수 있습니다. 많은 경우, 모델이 문제를 일으키는 언어를 생성할 때보다는 동작을 성공적으로 실행할 때 가장 큰 피해를 입힙니다.
도구 및 기능 남용은 더 미묘하지만 종종 더 위험합니다. Amazon Q 개발자 확장 침해공격자들은 AI 에이전트에게 접근 가능한 모든 파일과 클라우드 자원을 삭제하라는 명시적인 지시를 삽입했습니다. 비록 이 공격은 최종적으로 성공하지는 못했지만, 악의적인 행위자들이 도구 호출과 외부 실행 컨텍스트를 활용한 가드레일 우회 기법을 실험하고 있음을 보여줍니다.
과도한 신원 권한은 종종 견고한 보호막을 약화시킵니다. LLM이 광범위한 클라우드 권한을 가진 서비스 아이덴티티로 작동한다면, 모델에 영향력을 행사한 공격자가 애플리케이션 제어를 우회하고 클라우드 API와 직접 상호작용할 수 있습니다. 이런 경우, 신속한 가드레일은 신원 및 접근 관리에 진짜 약점이 있기 때문에 거의 보호를 제공하지 못합니다.
환경 간 이동도 반복되는 문제입니다. 개발 또는 스테이징 환경에서 신중하게 구현된 통제는 비상 수정, 새로운 통합 또는 문서화되지 않은 변경 사항으로 인해 운영 환경에서 약화되는 경우가 많습니다. 이로 인해 초기 보안 검토가 완료된 후에도 공격자가 악용할 수 있는 사각지대가 생깁니다.
인프라 수준의 노출은 애플리케이션 가드레일을 완전히 우회할 수 있습니다. 자체 호스팅 모델의 경우, 공개적으로 접근 가능한 컴퓨트 인스턴스는 인스턴스 메타데이터 서비스나 자격 증명 소스를 노출시켜 공격자가 민감한 데이터를 추출하고 권한을 에스컬레이션할 수 있게 합니다. 관리형 AI 서비스의 경우, 잘못 설정된 공용 엔드포인트나 약한 네트워크 제어가 직접 적용을 가능하게 합니다 API 남용 애플리케이션 레이어를 전혀 건드리지 않고요.
이러한 시나리오들 전반에 걸쳐 일관된 패턴이 나타납니다. 가드레일은 필요하지만, 그 자체로는 충분하지 않습니다. 최근 AI 호출 페이로드를 이용한 악성코드 캠페인에서 관찰된 실제 오용 패턴은 공격자들이 이미 신분 중심 방어를 회피하는 방법을 실험 중임을 보여줍니다. 신원, 데이터 접근, 인프라 노출을 규율하는 클라우드 네이티브 보안 통제의 강화가 없으면, 가드레일은 진정한 보호가 아닌 잘못된 안전감을 조성합니다.
Wiz가 AI 애플리케이션을 보호하는 방어 수단을 어떻게 도와주는가
LLM 가드레일은 AI 응용의 모습을 정의합니다 아마도 하지만 이러한 통제가 위협이 신원, 데이터, 인프라와 상호작용하는 실제 클라우드 환경에서 작동한다는 보장은 없습니다. Wiz는 지속적인 가시성, 위험 평가, 그리고 맥락이 풍부한 방어를 통해 전체 AI 공격 표면을 보호함으로써 가드레일을 강화합니다.
위즈의 AI 보안 태세 관리(AI-SPM) 에이전트 없이 확장된다 CNAPP 클라우드와 SaaS 전반에 걸쳐 모든 AI 에이전트, 모델, 엔드포인트 및 관련 서비스를 재고 조사하는 데 기반을 둡니다. 여기에는 AI 자재 명세서 그리고 에이전트 인벤토리 뷰 이를 통해 에이전트가 어디에서 실행되는지, 어떤 접근 권한이 있는지, 민감한 워크로드와 데이터에 어떻게 연결되는지 알 수 있습니다. 또한 Wiz 보안 그래프를 사용해 실제 클라우드 신원과 자원에 대한 노출을 매핑하여 팀이 단순히 존재하는 것뿐만 아니라 중요한 것까지 볼 수 있게 합니다.
이 플랫폼은 Azure OpenAI, Amazon Bedrock, Google Vertex AI 등 AI 서비스 전반에서 안전한 구성을 지속적으로 검증하며, 제공업체 가드레일, 신원 정책, 민감한 데이터 제어 검증을 포함합니다. 이렇게 하면 운영 환경에서 애플리케이션 가드레일을 약화시킬 수 있는 잘못된 설정과 누락된 보호를 발견할 수 있습니다.
마지막으로, Wiz는 실행 시 활동과 위협 신호를 클라우드 컨텍스트와 연관시켜 의심스러운 에이전트 행동을 감지하고, 잠재적 공격 경로를 추적하며, 대응 작업을 자동화합니다. 이를 신원 권한, 데이터 민감도, 인프라 노출과 연계함으로써, 팀은 이론적 격차가 아닌 실제 악용 가능성에 따라 복구 우선순위를 정할 수 있습니다.
