챗봇을 위한 가드 구현 예시

Cato Guards를 사용한 AI 애플리케이션 보안 (샘플 구성)

개요

이 가이드는 Cato AI Security Guards를 사용하여 사용자 정의 AI 애플리케이션을 보호하는 엔드 투 엔드 프로세스를 안내합니다. 이 과정은 세 단계로 구성되어 있으며, 각 단계는 이전 단계를 기반으로 하여 각 단계에서 어떤 변화가 발생하며 왜 필요한지를 정확히 볼 수 있습니다.

이 가이드에 사용되는 애플리케이션은 TravelBot입니다 — 간단한 AI 기반 여행 비서 챗봇입니다. 예시가 특정하지만, 개념과 단계는 구축하고 보호할 수 있는 모든 사용자 정의 AI 애플리케이션에 적용됩니다.

이 가이드는 세 가지 단계를 다룹니다:

• 1단계 기본 라인을 설정합니다: LLM과 직접 통신하는 보안 통제 없이 작동하는 AI 애플리케이션입니다. 이 단계는 시작점을 이해하고 이를 통해 발생하는 위험을 소개합니다.
• 2단계에서는 Cato Proxy Guard를 생성하여 애플리케이션과 LLM 사이에 삽입합니다. 트래픽은 가드를 통해 재조정되어 모든 상호작용을 기록하기 시작합니다. 아직 정책 규칙이 구성되지 않았습니다 — 이 단계에서 목표는 가드가 있을 때도 플로우가 정상 작동하는지 확인하는 것입니다.
• 3단계에서는 강제를 활성화합니다: 상호작용 정책 규칙을 구성하고 게시하여 가드가 탈옥 시도를 차단하고 건강 관련 콘텐츠를 모니터링하도록 지시합니다. 애플리케이션이 이제 완전히 보호받고 있습니다.
  이 가이드의 끝까지 진행하면 사용자 정의 AI 애플리케이션을 Cato Guards로 어떻게 보호할 수 있는지 — 완전히 열린 연결부터 적극적으로 강제되고 모니터링 및 관리되는 AI 워크플로우까지 명확하게 그림을 그릴 수 있습니다.

1단계 — 기본 라인: 가드 없이 사용하는 AI 앱

이 단계에서 다루는 내용

보안 통제를 도입하기 전에, 애플리케이션이 자체적으로 어떻게 작동하는지 이해하는 것이 중요합니다. 이 단계는 AI 기반 챗 애플리케이션의 기본 설정을 통해, 대형 언어 모델(LLM)과 직접 통신하는 작동 상태를 안내합니다. 이것을 '전' 단계로 바라보십시오: 앱이 기능적이지만 사용자와 모델 사이에 아무 것도 없습니다.

앱이 어떻게 작동하는가

애플리케이션은 TravelBot이라는 간단한 여행 비서 챗봇입니다. 함께 작동하는 세 가지 구성 요소로 이루어져 있습니다:

1. 프론트엔드
사용자가 보고 상호작용하는 부분입니다 — 브라우저의 채팅 인터페이스에서 질문을 입력하고 응답을 받을 수 있습니다.

2. 백엔드
이것은 배경에서 작동하는 엔진입니다. 사용자의 메시지를 받아 대화 기록을 추적하고 메시지를 LLM으로 전달합니다. 또한 오류를 처리하고 모델의 응답을 사용자에게 되돌려줍니다. 백엔드는 경량 웹 프레임워크인 Flask로 구축되었습니다.

3. LLM 연결
여기가 지능이 존재하는 부분입니다. 백엔드는 사용자 메시지(회화 기록과 함께)를 대형 언어 모델로 보내어 응답을 생성합니다. 이 단계에서는 백엔드가 직접 LLM과 통신 — 그 사이에 아무것도 없습니다.

흐름은 다음과 같습니다:

사용자 (브라우저) → 백엔드 (Flask) → LLM → 사용자에게 응답

언어 및 프레임워크에 대한 노트

이 가이드의 샘플 애플리케이션은 경량 웹 프레임워크 Flask를 사용하는 Python으로 구축되었습니다. 파이썬은 AI 애플리케이션 개발의 인기 있는 선택이지만, 유일한 선택은 아닙니다. Node.js, Java, Go 또는 다른 언어로 구축된 애플리케이션에도 동일한 개념과 흐름이 적용됩니다. 구성 값, 요청 구조, 및 가드 통합은 모두 같은 논리를 따릅니다 — 단, 문법만 변경됩니다.

구성 파일

백엔드와 LLM 간의 연결은 config.py라는 파일로 제어됩니다. 이 파일에는 세 가지 중요한 값이 포함되어 있습니다:

OPENAI_API_KEY = "sk-proj-xK92mLqP3nVwTz8YdR5eN1uJbF7cQm4HsAo6WpGi0XvCl"
BASE_URL = "https://bedrock-mantle.eu-north-1.api.aws/v1"
MODEL_ID = "amazon.nova-pro-v1:0"

• OPENAI_API_KEY — 이는 LLM 공급 업체에게 애플리케이션이 요청을 승인받았음을 증명하는 자격 증명입니다.
• BASE_URL — 백엔드가 요청을 보내는 주소입니다. 현재 LLM 제공자에게 직접 포인트합니다.
• MODEL_ID — LLM 제공자에게 응답을 생성할 때 사용할 특정 모델을 지시합니다.

이 단계에서 앱을 실행하려면, LLM 제공자에게 제공받은 자격 증명을 사용하여 세 가지 값을 입력해야 합니다.

애플리케이션이 메시지와 함께 하는 일

사용자가 메시지를 보내면 단계별로 다음과 같은 일이 발생합니다:

1. 사용자가 채팅 인터페이스에서 메시지를 입력하고 전송 버튼을 누릅니다.
2. 브라우저는 메시지를 Flask 백엔드로 보내며, 대화를 식별하는 세션 ID도 함께 보냅니다.
3. 백엔드는 메시지를 대화 기록에 추가하고 모든 것을 LLM으로 전달하면서 모델에게 TravelBot으로 작동하라는 시스템 지시를 앞에 추가합니다.
4. LLM은 전체 회화를 처리하고 응답을 생성합니다.
5. 응답은 백엔드로 다시 전송돼서 대화 기록에 추가되고 사용자 브라우저로 반환됩니다.
6. 사용자는 채팅 인터페이스에서 응답을 봅니다.

아직 발생하지 않는 일

이 단계에서는 애플리케이션이 완전히 기능하지만 완전히 보호되지 않은 상태입니다. 즉:

• 사용자가 모델에게 보내는 것에 대한 검사가 없습니다.
• 도구 호출 및 응답에 대해 검사 없음이 있습니다.
• 정책 강제가 없습니다 — 악성 메시지를 포함하여 모든 메시지가 LLM에 도달합니다.
• 애플리케이션이 어떻게 사용되는지에 대한 가시성이 없습니다.

예를 들어, 사용자는 모델의 지시를 무시하게끔 하거나, 민감한 정보를 추출하거나, 조직의 정책을 위반하는 방식으로 애플리케이션을 사용할 수 있습니다 — 이 모든 것은 감지되거나 중지되지 않습니다.

이것이 바로 다음 단계에서 해결하는 격차입니다.

요약

2단계 — 가드를 도입

이 단계에서 다루는 내용

1단계에서 우리는 LLM과 직접 통신하는 작동하는 AI 애플리케이션을 설정했습니다. 앱이 작동하지만 사용자와 모델 사이에 아무것도 없습니다. 이 단계에서는 애플리케이션과 LLM 사이에 자리하여 모델에 도달하기 전에 실시간으로 트래픽을 검사하고 응답을 사용자에게 반환하기 전에 검토하는 강제 레이어인 Cato AI Security Guard를 도입합니다.

이 단계가 끝나면 모든 LLM 트래픽, 사용자 메시지, 도구 정의, 도구 사용 등이 Cato를 통해 진행됩니다. 사용자 경험은 동일하게 유지됩니다 — 하지만 이제 모든 상호작용이 검사 및 제어될 수 있습니다.

업데이트된 흐름은 다음과 같습니다:

가드란 무엇인가?

가드는 AI 보안의 강제 지점입니다. 이 예에서는 프록시 모드를 사용하여 애플리케이션과 LLM 사이에 중재자로 작용하며, 귀하가 정의한 정책에 대해 모든 프롬프트와 응답을 평가합니다. 정책에 따라 가드는 상호작용을 허용하거나 차단하거나 기록할 수 있습니다.

가드에는 세 가지 종류가 있습니다. 이 가이드에서는 Proxy Guard를 사용합니다. 프록시 모드에서 가드는 트래픽 경로에 완전히 인라인됩니다. 애플리케이션은 직접 LLM에 요청을 보내는 대신 가드의 엔드포인트에 요청을 보냅니다, 그리고 가드는 검토 후 LLM으로 전달합니다. 애플리케이션의 로직에는 변경사항이 필요하지 않지만 — 목적지 주소만 변경됩니다.

1단계 — Cato 관리 애플리케이션에서 가드를 생성

첫 번째 단계는 Cato 관리 애플리케이션에서 논리적 엔터티로 가드를 생성하는 것입니다. UI에서 완료됩니다 — 이 시점에서는 코드가 필요하지 않습니다.

1. 탐색 메뉴에서 AI 보안 > 가드를 선택한 다음 New를 클릭합니다.
2. 설명적인 가드 이름을 입력하세요. 우리의 예에서는 E2E 샘플 사례를 사용합니다.
3. 가드 유형 선택에서 프록시를 선택하세요.
4. AI 서비스 선택에서 드롭다운에서 사용자 정의 엔드포인트를 선택합니다. 이 옵션은 애플리케이션에서 사용하는 모든 OpenAI 호환 엔드포인트에서 작동합니다.
5. 엔드포인트 URL 필드에 LLM 제공자의 URL을 입력하세요. 우리의 예에서는 https://bedrock-mantle.eu-north-1.api.aws/v1입니다. 이것은 이전에 config.py에서 BASE_URL로 설정된 동일한 URL입니다 — 이제 이 주소를 직접 애플리케이션에서 사용하지 않고 가드에게 넘겨줍니다.
   참고: URL은 /v1까지의 경로를 포함해야 합니다.
6. 가드 설정 구성에서 가드의 호스트를 Cato의 클라우드로 설정한 채로 두세요. 이는 가드가 Cato에 의해 관리 및 호스팅되며 — 추가 인프라를 배포하거나 유지할 필요가 없다는 뜻입니다.
7. 저장을 클릭하세요.

무슨 일이 방금 벌어졌습니까? 당신은 이제 LLM의 위치를 알고 있는 가드를 생성했습니다. 이제 Cato는 앱과 LLM 사이의 모든 트래픽의 중재자로 작용합니다. 가드는 아직 정책 규칙이 없습니다 — 우리는 3단계에서 이러한 규칙을 추가할 것입니다. 현재로서는 단순히 연결을 설정하고 흐름이 여전히 작동하는지 확인하는 것입니다.

2단계 — 가드의 연결 세부 정보 가져오기

가드가 저장되면, 가드 페이지에서 열고, 가드의 문서 페이지로 이동하여 애플리케이션이 가드에 연결할 수 있는 모든 것을 제공합니다, 즉 LLM에 직접 연결하는 것이 아니라 연결합니다.

여기에서 두 가지 주요 정보를 찾을 수 있습니다:

• 가드 엔드포인트 (새로운 BASE_URL) - 이것은 이제 애플리케이션이 요청을 보낼 주소입니다: https://api.aisec.catonetworks.com/fw/v1/proxy/openai

  • 이는 구성에서 LLM의 엔드포인트 URL을 대체합니다. 이 시점부터, 애플리케이션은 Cato와 대화하고 Cato는 LLM과 대화합니다.

• 가드 API 키 (새로운 OPENAI_API_KEY)

  • 문서 페이지에는 가드 API 키도 제공되었습니다 — 애플리케이션이 가드와 인증하는 데 사용하는 자격 증명입니다. 이것은 이전에 구성에 있던 LLM API 키를 대체합니다. 이렇게 보입니다: cato-1234-abcde

참고: Cato는 두 개의 가드 API 키를 제공합니다. 요청하려면 하나만 필요합니다. 두 번째 키는 자격 증명을 안전하게 회전할 수 있도록 존재합니다 — 응용 프로그램이 여전히 활성 상태인 동안 새 키를 사용하는 것으로 업데이트할 수 있어 다운타임을 방지합니다.

LLM API 키

이전에 LLM API 키는 응용 프로그램의 구성에 위치했습니다. 가드가 설치되면, 그 키는 애플리케이션이 가드에게 보내는 요청 헤더로 이동합니다 — 구체적으로 x-cato-provider-api-key라는 헤더에 있습니다. 가드는 이를 사용하여 애플리케이션을 대신하여 LLM과 인증합니다.

이것은 실제로 보안 향상입니다: LLM API 키는 구성 파일에 하드코드되지 않고 있으며, 가드는 해당 자격 증명의 제어된 패스-스루 역할을 합니다.

3단계 — 애플리케이션 구성 업데이트

이제 가드가 생성되고 연결 세부 정보가 있으므로 애플리케이션을 업데이트할 시간입니다. 1단계와 2단계를 명확히 분리하기 위해 원본을 덮어쓰지 않고 새로운 구성 파일 세트를 만듭니다. 이렇게 해서 두 단계 모두 참조를 위해 완전하게 유지됩니다.

새로운 구성 파일 config_stage2.py는 업데이트된 연결 세부사항을 반영합니다:

# 2단계 구성 — Cato 프록시 가드를 통해 라우팅

GUARD_API_KEY = "cato-xxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
BASE_URL = "https://api.aisec.catonetworks.com/fw/v1/proxy/openai"
MODEL_ID = "amazon.nova-pro-v1:0"
LLM_PROVIDER_API_KEY = "[SECRET_1]" # LLM 제공자 API 키 - 가드로 전달, LLM 직접 전달되지 않음

SYSTEM_PROMPT = (
 "You are TravelBot, a friendly and knowledgeable travel assistant. "
 "Help users discover destinations, plan itineraries, recommend hotels, "
 "and share practical travel tips. Keep responses concise and enthusiastic. "
 "If a question is unrelated to travel, politely redirect the conversation."
)

MAX_TOKENS = 1024

1단계와의 주요 차이점은 다음과 같습니다:

4단계 — 클라이언트 코드 업데이트

클라이언트 코드도 Stage 2 버전인 — bedrock_client_stage2.py를 받습니다. Stage 1과는 크게 같은 논리, 두 가지 추가 사항이 있습니다:

1. 가드 API 키는 가드에서 인증하는 데 사용됩니다 (in Authorization header).
2. LLM API 키는 추가 헤더 (x-cato-provider-api-key)로 전달되어 가드가 LLM으로 전달할 수 있습니다.
3. 세션 ID는 헤더 (x-cato-session-id)로 전달되어 가드가 같은 대화에서 요청을 함께 그룹화할 수 있습니다 — 이는 이미 애플리케이션 로직에 존재하는 session_id에 직접 매핑됩니다.

# bedrock_client_stage2.py

openai에서 import OpenAI
config_stage2에서 import GUARD_API_KEY, BASE_URL, MODEL_ID, LLM_PROVIDER_API_KEY, SYSTEM_PROMPT, MAX_TOKENS


class BedrockClient:
    def __init__(self):
        self._client = 존재하지 않음

    def _get_client(self) -> OpenAI:
        if self._client is 같은지:
            self._client는 OpenAI(
                api_key=GUARD_API_KEY,
                base_url=BASE_URL,
                default_headers={
                    "x-cato-provider-api-key": LLM_PROVIDER_API_KEY,
                }
            )
        return self._client

    def invoke(self, messages: 목록[dict], session_id: str = "") -> 같은지:
        all_messages = [{"역할": "시스템", "내용": SYSTEM_PROMPT}] + messages

        대응 = self._get_client().chat.completions.create(
            모델=MODEL_ID,
            messages=all_messages,
            max_tokens=MAX_TOKENS,
            extra_headers={
                "x-cato-session-id": session_id,
            }
        )

        return 대응.choices[0].message.content

플로우 확인

업데이트된 구성 및 클라이언트 파일이 배치되면, 애플리케이션은 사용자 관점에서 스테이징 1과 정확히 동일하게 작동해야 합니다. TravelBot은 여행 질문에 동일하게 응답합니다 - 그러나 이제 모든 상호작용은 가드를 통과하고 있습니다.

이 시점에서 가드는 어떤 정책 규칙도 구성되지 않았기 때문에 트래픽을 차단하거나 수정하지 않습니다. 예외적으로 모든 상호작용은 로그됩니다. Cato 관리 애플리케이션에서 가드를 열고 가드 로깅 페이지를 확인하여 애플리케이션이 사용되면서 세션이 나타나는 것을 볼 수 있습니다.

이것은 통합이 올바르게 작동하고 있으며 가드가 트래픽을 수신하고 있음을 확인합니다.

스테이징 1의 변경 요약에서 스테이징 2로 가기

스테이징 3 — 정책 규칙 구성하기

이 단계가 포함하는 것이 무엇입니까

스테이징 2에서는 가드를 소개하고 트래픽이 올바르게 흐르는 것을 확인했습니다. 가드는 활성되었지만 아직 아무 규칙을 강제 적용하지 않습니다 — 트래픽을 관찰하기만 합니다. 이 단계에서는 가드 상호작용 정책: 가드에게 특정 유형의 콘텐츠를 감지했을 때 취할 행동을 지시하는 규칙 세트를 구성합니다.

이 단계가 끝나면 가드는 라이브 트래픽에 대해 두 가지 규칙을 적극적으로 강제할 것입니다:

• PII나 비밀번호 같은 정보를 포함하는 모든 상호작용을 차단 및 익명화
• 의료 조언이나 건강 관련 데이터를 포함하는 모든 상호작용 모니터링

참고: 감지가 기대한 대로 작동하는지 확인한 후, 규칙을 모니터링으로 설정하고 이후 차단으로 이동해 먼저 테스트하는 것을 권장합니다.

가드 상호작용 정책이란 무엇입니까?

가드 상호작용 정책은 AI 보안 가드의 규칙 베이스입니다. 이를 AI 트래픽을 위한 방화벽으로 생각하세요 — 네트워크 패킷을 검사하는 대신, AI 상호작용의 콘텐츠를 검사하고 일치하는 경우 정의된 작업을 적용합니다.

정책의 각 규칙은 지정합니다:

• 규칙이 적용되는 가드
• 찾아볼 대상 — 엔진 프로필에 의해 정의된 탐지 카테고리(예: jailbreak 시도, PII, 또는 의료 데이터)
• 일치가 발견되면 수행해야 할 작업 — 차단, 모니터링, 익명화 및 차단, 또는 익명화 및 모니터링
• 트래픽 검사 방향 — 사용자로부터 들어오는 메시지, 어시스턴트의 응답, 도구의 입력, 또는 도구의 출력

주의해야 할 중요한 행동: 가드 상호작용 정책의 규칙은 규칙 기지 내 위치에 관계없이 평가됩니다. 상호작용에 여러 규칙이 적용되는 경우, 더 엄격한 행동이 우세합니다. 예를 들어, 하나의 규칙이 모니터링을, 다른 규칙이 차단을 지시하면 차단 작업이 적용됩니다.

단계 1 — 규칙 1 생성: Jailbreak 시도 차단

우리가 만드는 첫 번째 규칙은 탈옥 시도를 대상으로 합니다 — 사용자가 모델을 조작하여 지침을 무시하거나 안전 장치를 우회하려는 의도적인 노력. TravelBot과 같은 고객 대상 애플리케이션에는 이것이 의미있는 위험입니다: 사용자가 모델을 정의된 역할 외에서 작동하게 하거나 노출해서는 안 되는 정보를 노출시키려 시도할 수 있습니다.

시작하려면, 가드 정책 페이지로 이동하십시오. 이 작업은 기본 탐색 메뉴에서 AI 보안 > 가드 상호작용 정책을 선택하거나, 가드의 개요 페이지에서 정책 관리를 클릭하여 활성 규칙 섹션에서 직접 수행할 수 있습니다.

가드 정책 페이지에서 새로 만들기를 클릭하여 규칙 편집기를 열고 다음을 구성하십시오:

일반

• 이름: 일부 트래픽 차단
• 설명: 이것은 우리의 여행 봇으로부터 jailbreak 트래픽을 차단합니다.
• 활성화됨 토글을 켠 상태로 두십시오

가드

• E2E 샘플 사용 사례를 선택하십시오 — 이 규칙을 특정 가드로 범위를 지정하며 계정 내의 다른 가드에는 영향을 미치지 않습니다

엔진 프로필

• 민감한 식별자 선택 — 이는 프롬프트 주입 시도, 탈옥 패턴 및 모델에서 비밀이나 자격 증명을 추출하려는 시도를 식별하는 탐지 카테고리입니다

작업

• 익명화 및 차단 선택 — 가드가 일치를 감지하면, 상호작용에 존재하는 모든 민감한 데이터를 익명화하고 프롬프트가 LLM에 도달하지 않도록 차단합니다

방향

• 사용자와 도구 입력 확인 — 규칙은 사용자와 모든 도구 입력에서 오는 콘텐츠에 적용됩니다. 어시스턴트의 응답과 도구의 출력은 이 규칙의 범위 내에 포함되지 않습니다.

저장을 클릭하십시오**. 규칙은 비게시 수정본에 저장되며 아직 라이브 트래픽에 영향을 미치지 않습니다.

단계 2 — 규칙 2 생성: 의료 콘텐츠 모니터링

두 번째 규칙은 다른 접근 방식을 취합니다. 트래픽을 차단하는 대신, 상호작용이 진행되도록 허용하면서 검토를 위해 플래그를 지정합니다. 이는 본질적으로 악의적인 것은 아니지만 가시성이 필요할 수 있는 콘텐츠에 적합합니다 — 이 경우 의료 조언이나 건강 관련 데이터를 포함하는 상호작용.

TravelBot에서는 사용자가 의료 여행 조언을 요청할 때 (예: 예방접종 요구사항이나 목적지의 건강 예방책), 이는 본질적으로 유해하지 않지만 준수하거나 품질 관리 목적으로 추적할 수 있는 종류의 콘텐츠입니다.

가드 정책 페이지에서 새로 만들기를 다시 클릭하고 다음을 구성하십시오:

• 일반
  • 이름: 잠재적으로 유해한 데이터 모니터링
  • 설명: 통신이 통과하도록 허용하지만 상호작용을 모니터링합니다
    활성화됨 토글을 켠 상태로 두십시오

가드

• E2E 샘플 사용 사례 선택

엔진 프로필

• 건강 데이터 노출 선택 — 이것은 의료 지침, 건강 데이터 또는 임상 정보를 포함하는 상호작용을 탐지합니다

작업

• 익명화 및 모니터링 선택 — 상호작용은 LLM으로 정상적으로 전달되고 응답은 사용자에게 정상적으로 반환됩니다. 개인화된 정보는 개인 세부사항 보호를 위해 익명화됩니다. 상호작용은 검토를 위해 Cato에 기록됩니다.

방향

• 모든 네 방향 확인: 사용자, 어시스턴트, 도구 입력, 및 도구 출력 — 이 규칙은 모든 방향에서 트래픽을 모니터링하여 대화의 양쪽을 완전히 볼 수 있게 합니다

저장을 클릭하십시오**.

단계 3 — 정책 게시

두 규칙을 모두 저장한 후, 가드 정책 페이지는 게시되지 않은 수정본 상태와 게시 (2) 버튼을 오른쪽 상단에 표시하여 두 가지 규칙이 라이브로 갈 준비가 되었음을 나타냅니다.

중요: 게시할 때까지 활성 정책은 변경되지 않습니다. 규칙은 초안 상태로 존재하며 라이브 트래픽에 대해 강제되지 않습니다. 변경이 적용되기 전에 변경 사항을 검토할 수 있는 기회를 제공합니다.

준비가 되면, **게시 (2)**를 클릭하십시오. 두 규칙이 즉시 활성화되고 가드는 모든 들어오는 트래픽에 대해 규칙을 강제하기 시작합니다.

지금 가드가 수행하고 있는 것

두 규칙이 게시되면 E2E 샘플 사용 사례 가드를 통과하는 모든 상호작용이 이제 정책에 대한 평가를 받습니다. 실제 상황에서 다음과 같이 보입니다:

사용자가 TravelBot에 메시지를 보냅니다. 메시지가 LLM에 도달하기 전에 가드는 두 가지 규칙에 대해 검토합니다:

• 메시지에 탈옥 패턴이 포함되어 있거나 비밀을 추출하려는 시도가 있을 경우, 가드는 이를 익명화하고 차단합니다. LLM은 절대 메시지를 보지 못하며 사용자는 차단된 응답을 받습니다.
• 메시지에 의료 조언이나 건강 관련 콘텐츠가 포함되어 있으면, 가드는 이를 통과시키지만 상호작용을 검토를 위해 기록합니다.
• 메시지가 두 규칙 중 어느 것에도 일치하지 않으면, LLM으로 그대로 전달됩니다.

어시스턴트의 응답, 도구 입력 및 도구 출력의 동일한 평가가 각 규칙에 대해 구성된 방향에 따라 적용됩니다.

규칙이 활동적인지 확인

규칙이 활동적이고 가드에 적용되었음을 확인하기 위해, 가드의 개요 페이지로 이동하십시오. 활성 규칙 아래에 이제 두 규칙이 나열된 것을 볼 수 있습니다. 시간에 따른 상호작용 차트와 위반 현황 패널은 트래픽이 가드를 통과하고 감지가 발생함에 따라 데이터가 채워지기 시작합니다.

또한 가드 로그로 이동하여 개별 세션을 검토하고, 어떤 규칙이 실행되었는지 보고 플래그가 지정된 상호작용의 세부사항을 검사할 수 있습니다 — 민감한 콘텐츠를 보기 위한 필요한 권한이 있는 경우.

요약

이 두 가지 규칙으로 애플리케이션에 이제 활동적인 보안 강제가 적용되었습니다. 악성 프롬프트 시도가 모델에 도달하기 전에 차단되고, 민감한 건강 관련 상호작용은 보안 팀에 표시됩니다 — 애플리케이션 코드나 정상적인 사용자 상호작용에 대한 영향 없이.

이로써 Cato AI Security Guards로 커스터마이징된 AI 애플리케이션을 보호하는 엔드투엔드 가이드가 완료됩니다.