거버넌스 게이트로 레드티밍된 AI 에이전트 게이트하기

수백 개의 에이전트를 하나의 표준화된 배포 게이트로 통과시켜서, 모든 배포가 최신 레드티밍 증거로 뒷받침되게 해요.

출처: 문서

본문

개요

에이전트 하나는 안전하게 유지하기 쉬워요 — 레드티밍하고, 리포트를 읽고, 결정하면 되죠. 수백 개의 에이전트는 다른 문제예요. 보안 팀이 하나하나 검토하기엔 너무 많고, 저마다 자기 일정으로 출시하며, 팀마다 레드티밍 방식이 조금씩 달라서 "이 에이전트를 배포해도 안전한가?"라는 질문이 더는 신뢰할 만한 답을 갖지 못해요.

이 가이드는 모든 에이전트를 하나의 표준화된 배포 게이트로 통과시켜요. 레드티밍 요구사항을 거버넌스 컨트롤로 한 번 정의하면, 모든 에이전트의 프로젝트가 그것을 상속하고, 각 파이프라인이 배포 전에 같은 게이트를 호출해요. 누구도 손으로 검토하지 않고, 게이트 통과는 에이전트 #1과 에이전트 #400에게 같은 의미예요.

같은 패턴은 배포 전 평가 컨트롤로 평가 증거에도 동작해요 — 이번에는 자격을 갖춘 테스트 런으로 게이트하죠. 이 가이드는 보안 쪽을 다뤄요: 배포 전 레드티밍 컨트롤로, 자격을 갖춘 리스크 평가로 게이트합니다.

이 가이드에서 배울 것:

모든 릴리스 후보를 자동으로 레드티밍 — CI나 일정에 맞춰요.
어느 평가가 릴리스를 게이트하는지 결정 — 최신 것, 또는 평가를 승격한다면 최신 공식 것을 써요.
요구사항을 한 번만 정의 — 모든 에이전트 프로젝트가 상속하는 정책에 배포 전 레드티밍 컨트롤로 넣어요.
모든 파이프라인에서 같은 게이트 실행 — 빠졌거나, 오래됐거나, 실패한 평가가 해당 에이전트의 배포를 막게 해요.

flowchart LR
    subgraph Fleet["Hundreds of agents"]
        A1["Agent 1"]
        A2["Agent 2"]
        AN["Agent N"]
    end

    Fleet --> RT["Red teaming<br/>(DeepTeam or platform)"]
    RT --> Gate["Standardized gate<br/>deepeval gate"]
    Policy["Base policy<br/>pre-deployment red teaming control"] --> Gate
    Gate --> Deploy["Deploy allowed"]

    classDef fleet fill:#f8fafc,stroke:#334155,stroke-width:2px,color:#0f172a
    classDef step fill:#eef2ff,stroke:#4f46e5,stroke-width:1px,color:#1e293b
    class A1,A2,AN fleet
    class RT,Policy,Gate,Deploy step

레드티밍과 AI 거버넌스는 모두 Enterprise 기능이에요. 게이트는 프로젝트의 Project API Key로 실행되므로, 에이전트를 출시하는 백 개 팀은 조직 수준 자격 증명이 필요 없어요 — 정책을 소유한 플랫폼 팀만 있으면 됩니다.

실제로 어떤 모습인가요

표준화된 게이트는 그 뒤의 요구사항이 구체적일 때만 유용해요. 대규모 플릿에서 보통 취하는 형태들이에요:

하나의 프레임워크, 하나의 기준. 모든 에이전트가 같은 프레임워크로 레드티밍돼요 — Confident AI에서 끌어오므로 문자 그대로 같은 취약점·공격 구성이에요 — 그리고 컨트롤은 게이트 평가의 통과율이 90% 같은 고정 임계값을 넘어야 요구해요. 프레임워크가 공유되므로 그 백분율은 어디서나 같은 의미예요: 에이전트 #12의 90% 달성은 에이전트 #300과 같은 부류의 공격을 맞은 결과예요. 공유 프레임워크 없이는 각 팀의 통과율이 서로 다른 테스트로 측정되어 숫자가 비교 불가능해져요.

모든 릴리스가 재테스트. 컨트롤은 프로젝트의 최신 리스크 평가를 판단하므로, 레드티밍이 게이트 직전의 같은 파이프라인에서 실행돼요. 그 순서 덕분에 증거가 누군가 세 릴리스 전에 테스트한 것이 아니라 배포되는 빌드에 속하게 되죠 — 그리고 규모가 커지면 중요해요. 에이전트는 누구든 손으로 보안 테스트를 다시 돌리는 것보다 훨씬 자주 변하니까요.

승인된 구성만 인정. 필터는 게이트 평가가 승인된 애플리케이션·모델·공격 구성으로 실행됐을 것을 요구해요. 이렇게 하면 명백한 허점이 막혀요: 스텁 엔드포인트, 더 싸고 오래된 모델, 단일 약한 공격으로 레드티밍한 팀이 실제 대상에 대한 전체 스윕과 같은 게이트를 통과하면 안 되니까요.

리스크 등급마다 다른 기준. PII를 다루는 고객 접점 에이전트는 더 높은 통과율 기준을 가진 더 엄격한 정책에 있고, 내부 툴링은 조직 전체 기준만 담은 같은 기본 정책을 확장해요. 각 프로젝트는 여전히 하나의 게이트를 통과해요 — 등급은 상속할 컨트롤을 정할 뿐이죠.

필요한 곳엔 휴먼 승인. 소수의 고위험 에이전트는 평가를 공식으로 표시해서, 게이트가 가장 최근 실행이 아니라 보안 엔지니어가 승격한 평가를 판단하게 해요. 나머지 플릿은 파이프라인이 방금 만든 것을 전부 자동으로 처리해요.

만들어 보기

평가가 어디서 오는지 정하기

게이트는 그것을 공급하는 평가만큼만 신선할 수 있어요. 그래서 레드티밍이 누군가 기억날 때가 아니라 스스로 돌아야 해요. 평가를 만드는 방법은 두 가지이고, 플릿은 보통 둘 다 돌려요:

CI에서 DeepTeam으로

코드 주도 레드티밍을 릴리스 후보를 대상으로 파이프라인 단계로 실행해요. DeepTeam을 사용해요. 스크립트를 한 번 쓰면 모든 에이전트 저장소가 같은 것을 돌려요.

파이프라인 안에만 존재하는 에이전트이거나, 커스텀 취약점·공격을 원할 때 가장 좋아요. 다음 단계가 이 스크립트를 작성해요.

플랫폼에서 일정으로

에이전트가 네트워크로 닿을 수 있다면 AI Connection을 구성하고 프레임워크에 반복 평가를 예약해요. Confident AI가 공격을 생성하고 실행해 주므로 유지할 스크립트가 없어요.

배포된 에이전트, 비-Python 스택, 릴리스 사이의 지속적인 커버리지에 가장 좋아요. 이 방식을 택하면 다음 단계는 건너뛰세요 — 쓸 스크립트가 없어요.

레드티밍 스크립트 작성하기

이것이 모든 에이전트의 파이프라인이 실행하는 스크립트예요. DeepTeam을 설치하고 CONFIDENT_API_KEY를 에이전트의 프로젝트로 지정해서, 결과 리스크 평가가 게이트가 평가할 프로젝트에 들어가게 해요:

pip install -U deepteam
export CONFIDENT_API_KEY="confident_us_proj_..."

이제 플릿을 표준화하는 부분이에요: 각 저장소에 하드코딩하는 대신 Confident AI에서 프레임워크를 끌어와요. 보안 프레임워크를 플랫폼에서 한 번 구성한 뒤, 모든 에이전트 스크립트가 id로 같은 프레임워크를 끌어오게 해요. DeepTeam이 구성된 취약점 유형과 공격 메서드와 함께 모든 리스크 범주를 내려받으므로, 400개 에이전트 전체가 동일한 테스트 스위트로 공격을 받아요 — 그리고 보안팀이 프레임워크에 취약점을 추가하면 아무도 파이프라인을 건드리지 않아도 다음 실행에서 플릿 전체가 받아요.

from deepteam import red_team
from deepteam.frameworks import RedTeamingFramework
from deepteam.test_case import RTTurn, ToolCall

from my_app import my_agent

framework = RedTeamingFramework()
framework.pull("your-framework-id")

async def model_callback(input: str) -> RTTurn:
    # Point this at the agent build you're about to ship
    response = await my_agent(input)
    return RTTurn(
        role="assistant",
        content=response.output,
        retrieval_context=response.retrieved_docs,
        tools_called=[ToolCall(name=t) for t in response.tools_used],
    )

red_team(
    model_callback=model_callback,
    framework=framework,
    identifier="release-candidate",
    run_all_attacks=True,
)

여기서 제대로 맞춰야 할 세 가지가 있어요. 모두 DeepTeam으로 레드티밍에서 다룹니다:

프레임워크 id는 플랫폼 프레임워크 구성 페이지 URL의 마지막 세그먼트예요.
콜백은 적대적 입력을 단일 문자열로 받아 role="assistant"를 가진 RTTurn을 반환해요. 에이전트가 RAG나 에이전트 시스템이면 retrieval_context와 tools_called를 넘겨서, 공격이 최종 텍스트만이 아니라 에이전트가 실제로 검색하고 호출한 것에 대해 판단되게 해요.
identifier 는 리스크 프로필에서 평가의 이름을 지어요. 파이프라인마다 안정적인 것을 쓰세요 — 여기선 "release-candidate" — 그래서 게이트된 파이프라인에서 온 평가와 누군가 실험으로 만든 것을 한눈에 구분할 수 있어요.

스크립트를 실행하면 리스크 평가가 프로젝트의 리스크 프로필에 자동으로 업로드돼요. 게이트를 CI에 연결하기 전에 로컬에서 한 번 실행하고 평가가 올바른 프로젝트에 나타나는지 확인하세요 — 컨트롤은 증거가 도착해야만 통과할 수 있어요.

deepteam은 사전 정의된 프레임워크(OWASPTop10, NIST, MITRE 등)도 제공해서 red_team()에 직접 넘길 수 있어요. 단일 프로젝트에는 괜찮지만, 끌어온 프레임워크가 플릿을 동기화 상태로 유지해요 — 플랫폼에서 한 커스터마이즈가 모든 에이전트에 닿는 반면, 하드코딩된 것은 모든 저장소에서 편집해야 하거든요.

레드티밍은 적대적 입력을 생성하려는 모델이 필요해요. 대부분의 정렬된 모델은 거절해서 errored 테스트 케이스로 나타나요. 시뮬레이션용 권장 모델을 보세요.

어느 평가가 릴리스를 게이트하는지 정하기

프로젝트는 평가를 쌓아요 — 스크래치 런, 일회성 실험, 예약된 스윕. 컨트롤은 프로젝트의 최신 완료 리스크 평가를 판단하므로, 기본적으로 누가 마지막으로 실행한 것이 릴리스가 게이트되는 증거예요.

그게 너무 느슨하면 평가를 공식으로 표시해요: 그러면 컨트롤은 최신 공식 평가를 대신 판단해서, 스크래치 런이 조용히 배포 결정의 근거가 될 수 없어요. 표시는 리스크 프로필 페이지에서 해요.

완전 자동화된 플릿은 보통 최신 평가를 유지해요. 그것을 만드는 건 파이프라인 뿐이고, 릴리스 후보마다 실행되거든요. 공식은 보안 엔지니어가 릴리스가 판단될 평가를 승격시키길 원하는 고위험 에이전트에 아껴 두세요.

요구사항을 한 번만 정의하기

게이트를 표준화하는 단계가 바로 이것이에요: 보안 기준을 소유한 사람들이 한 곳에 한 번 작성하고 — 수백 개 파이프라인에 복사해서 각자 표류하게 두지 않아요.

모든 에이전트가 통과해야 하는 정책을 만들고 컨트롤을 추가해요:

조직의 Governance 페이지로 가서 정책을 열거나(또는 만들고) 만들어요.
배포 전 레드티밍 컨트롤을 추가해요.
이전 단계에서 정한 평가들 — 최신 또는 최신 공식 — 을 가리키게 해요.
필터를 추가해서 평가가 통과율 기준을 넘고, 실제로 승인한 애플리케이션·모델·공격 구성과 일치하게 해요.
Importance를 Critical 또는 High로 설정하고 저장해요.

필터가 기술적으로 통과한 게이트가 무의미해지는 것을 막아요. 필터가 없으면 스텁 엔드포인트를 단일 약한 공격으로 친 평가가 프로덕션에 대한 전체 OWASP 스윕만큼이나 컨트롤을 충족해요.

Importance는 컨트롤이 무엇이든 막을 수 있는지 결정해요. Low 중요도 컨트롤은 게이트를 절대 실패시키지 않아요 — FAIL, ERROR, NO_DATA를 보고하고 배포는 진행돼요. Low는 자문용 요구사항에만 쓰세요.

이 컨트롤을 기본 정책에 두고 각 팀의 정책이 그것을 확장하게 해요. 상속은 라이브이고 순수하게 가산적이어서, 플릿의 모든 에이전트가 조직 전반 보안 기준(과 나중에 강화된 것)을 받는 동안 팀은 그 위에 자체 컨트롤을 추가할 수 있어요. 기본 정책을 보세요.

같은 정책에 배포 전 평가 컨트롤을 추가하면 하나의 게이트가 품질과 보안을 모두 커버하고, 런타임 컨트롤은 배포 후 회귀를 잡아요.

모든 에이전트의 프로젝트 등록하기

정책은 프로젝트가 그것에 배정되기 전까지 효과가 없고, 어떤 정책에도 속하지 않은 프로젝트는 게이트가 오류를 내요. 플릿 규모에서 손으로 배정하는 것은 정확히 지우려고 하는 수작업 단계예요.

에이전트마다 프로젝트를 이미 프로비저닝한다면 — 에이전트용 프로젝트를 즉시 프로비저닝 참고 — 거버넌스 정책에 프로젝트를 즉시 배정으로 같은 프로비저닝 코드에서 각각을 정책에 등록해요. 배정은 파이프라인 실행마다 다시 실행해도 안전하므로, 에이전트는 첫 배포부터 거버넌스를 받고 아무도 추가할 일을 기억할 필요가 없어요.

각 프로젝트는 정책 하나에만 속하므로, 배정하는 정책은 그 에이전트가 충족해야 하는 요구사항 전체 집합을 나타내야 해요 — 그래서 공유 기준이 팀 정책이 확장하는 기본 정책에 있어야 하는 이유예요.

모든 파이프라인에서 같은 게이트 실행하기

모든 에이전트의 파이프라인은 레드티밍 후에 그 프로젝트의 Project API Key를 써서 동일한 두 줄을 실행해요. 에이전트별로 구성할 것이 없어요 — 요구사항이 정책에서 오므로, 파이프라인 스니펫은 전부에 복붙이에요:

Python

export CONFIDENT_API_KEY="confident_us_proj_..."
deepeval gate

TypeScript

export CONFIDENT_API_KEY="confident_us_proj_..."
npx deepeval gate

deepeval gate는 프로젝트 정책의 모든 컨트롤 — 기본 정책에서 상속한 것을 포함 — 을 평가하고, 정책 전체가 통과할 때만 0으로 종료해요. 다른 어떤 종료 코드도 배포를 멈춰요.

종합하면, 이것이 표준화할 워크플로예요 — 모든 에이전트 저장소가 받는 것. 릴리스 후보를 레드티밍한 뒤 거버넌스 게이트가 배포 결정을 내리게 해요:

name: Red team and gate

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  red-team-and-gate:
    runs-on: ubuntu-latest
    env:
      CONFIDENT_API_KEY: ${{ secrets.CONFIDENT_API_KEY }}
      OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install DeepTeam and DeepEval
        run: pip install -U deepteam deepeval

      - name: Red team the release candidate
        continue-on-error: true
        run: python tests/red_team.py

      - name: Run governance deployment gate
        run: deepeval gate

      - name: Deploy
        run: ./scripts/deploy.sh

전체 설계를 좌우하는 세부 사항 두 가지:

레드티밍 단계는 continue-on-error를 써요. 실패한 평가가 게이트가 실행되기 전에 작업을 중단하면 안 돼요 — 원시 종료 코드가 아니라 게이트가 판단하게 하세요. 게이트가 조직의 임계값과 중요도 수준을 아는 존재니까요.
단계는 순차 실행되는데, 그게 컨트롤의 "최신 평가"를 올바른 것으로 만들어요. GitHub Actions는 게이트를 시작하기 전에 레드티밍 단계를 끝내므로, deepeval gate가 돌 때 프로젝트의 최신 리스크 평가는 이 작업이 방금 업로드한 것이에요.

완료! 현재의, 올바르게 구성된 레드티밍 증거 없이는 플릿의 어떤 에이전트도 출시할 수 없고, 게이트 통과는 모든 에이전트에게 같은 의미예요.

레드팀 종료 코드가 아니라 정책으로 게이트하기

레드티밍 스크립트 결과로 배포를 직접 막고 싶은 유혹이 들어요. 그것만으로 빌드를 실패시키면 훨씬 약한 게이트를 얻어요:

크래시되거나 건너뛴 평가가 통과처럼 보여요. 컨트롤이 NO_DATA로 해석되어 실패해요. 결과를 업로드하지 않은 스크립트는 마음대로 종료하지요.
오래된 증거에 얹혀가는 게 보여요. 게이트 실행마다 판단한 평가를 기록하므로, 아무도 다시 실행하지 않은 평가로 통과하는 에이전트가 거버넌스 기록에 나타나요. 이번에 레드티밍을 건너뛴 파이프라인은 아무 말도 하지 않아요.
약화된 구성이 실제 테스트처럼 보여요. 필터는 승인된 애플리케이션·모델·공격 구성을 요구해요. 종료 코드는 전체 OWASP 스윕과 이를 테라도 없는 공격 하나를 구분하지 못해요.
요구사항이 한 곳에 있어요. 보안이 Confident AI에서 정책을 소유하고, 거버넌스되는 모든 프로젝트가 같은 기준을 상속해요. 수백 개 에이전트의 표준을 강화하는 것은 여러분이 소유하지 않은 파이프라인에 대한 수백 개 풀 리퀘스트가 아니라 기본 정책 한 번의 편집이에요.
기준이 팀마다 표류할 수 없어요. 각 파이프라인이 자기 임계값을 코딩하면 "게이트 통과"가 모든 저장소에서 조금씩 다른 의미가 돼요 — 그것이 정확히 백 개 에이전트에서 무너지는 지점이에요.

거버넌스 게이트로 레드티밍된 AI 에이전트 게이트하기