짧은 답: Guardrails는 텍스트를 관리하고; Firewall은 액션을 관리합니다.
이들은 보완적입니다 — 단일 요청이 둘 다를 통과합니다 — 그리고 함께
구성하는 가장 빠른 방법은 자율성 수준 입니다.
이 페이지의 나머지는 어떤 레이어가 특정 위협을 소유하는지 알아야 하는
경우를 위한 것입니다.
역할 필요. 모든 워크스페이스 멤버가 정책과 guardrail Matches 피드를
읽을 수 있습니다; firewall Events 피드는 Developer 역할이 필요합니다.
Guardrails나 firewall 정책 생성 또는 편집도 Developer 이상이 필요합니다.
1. 한 줄 구분 레이어 관리하는 것 보는 것 Guardrails 텍스트 — 모델이 읽고 쓰는 것 프롬프트 콘텐츠, 응답 콘텐츠 Agent Firewall 액션 — 에이전트가 하는 것 툴 호출, MCP 디스패치, 아웃바운드 네트워크 목적지
Guardrails는 업스트림 호출 전에 (프롬프트에서) 그리고 그 후에 (응답에서)
발동합니다. Firewall은 모델이 발행하거나 에이전트가 발행하는 모든 툴 호출에서
발동합니다 — 해당 턴을 서비스한 모델이나 프로바이더와 무관하게.
2. 나란히 비교 차원 Guardrails Agent Firewall 관리하는 것 프롬프트 텍스트와 모델 응답 텍스트 툴 호출, MCP 디스패치, egress 목적지, 에이전트 비용 보는 것 사용자 메시지, 시스템 프롬프트, 모델의 응답 툴 이름, 호출 인자, 모델이 발행하는 툴 호출, 아웃바운드 호스트/IP 연결 방법 API 키의 guardrail_id API 키의 firewall_policy_id 규칙 타입 keyword, regex, pii, max_chars, external, llm_judge, grounding툴 이름 glob + 인자 절 + egress 범위 + 스킬 소유권 위협 예시 프롬프트의 PII, 응답의 API 시크릿, 탈옥, 주제 이탈 출력, 과도한 컨텍스트 위험한 툴 호출, SSRF, 데이터 유출, 폭주 에이전트 비용 루프, 미승인 MCP 서버 판정 / 액션 block (HTTP 400 guardrail_blocked), mask, flagallow, audit, deny (HTTP 400 firewall_blocked), sanitize, pending_approval, cap_cost발동 시점 입력 단계: 모델 호출 전; 출력 단계: 모델 응답 후 모델이 발행하거나 에이전트가 발행하는 모든 툴 호출에서 Shadow / observe mode 없음 — guardrails는 발동하거나 발동하지 않습니다 있음 — shadow mode가 안전한 롤아웃을 위해 강제 판정을 audit으로 강등합니다
3. 위협 → 어느 레이어 이 표를 사용하여 새로운 보안 요구사항을 올바른 제어로 라우팅하세요:
위협 선택 사용자 메시지의 PII Guardrails — input pii 규칙 (mask / block)모델 응답의 시크릿 Guardrails — output secrets 규칙위험한 툴 호출 (shell.exec rm -rf /) Firewall — 툴 glob + 인자 절에 denySSRF / 아웃바운드 URL을 통한 데이터 유출 Firewall — egress 허용/거부 목록신뢰할 수 없는 콘텐츠에서 프롬프트 인젝션 둘 다 — input guardrail + firewall 허용 목록툴 인자의 시크릿 Firewall sanitize + Guardrails secrets 규칙탈옥 / 정책 우회 Guardrails — llm_judge / keyword / regex과도한 프롬프트 또는 토큰 비용 Guardrails — max_chars 규칙폭주 에이전트 지출 (비용 루프) Firewall — cap_cost 판정미승인 MCP 서버 Firewall — MCP 표면 deny / pending_approval툴 결과에서 민감한 데이터 Guardrails — 응답에 대한 output 규칙
각 페어링에 대한 심층적인 “왜”는
위협 심층 분석 페이지에 있습니다.
4. 둘 다 사용 — 자율성 수준이 함께 설정합니다 Guardrails와 Firewall은 경쟁이 아닌 구성되도록 설계되었습니다. 단일
요청이 두 플레인을 모두 통과합니다:
Input guardrail 실행 — 프롬프트 텍스트가 검사되고 선택적으로 마스킹됩니다.모델 호출 — (아마 정화된) 프롬프트가 업스트림 모델에 도달합니다.Firewall — 모델이 발행하는 모든 툴 호출이 평가됩니다.Output guardrail 실행 — 모델의 응답 텍스트가 검사됩니다.
두 가지를 한 번에 구성하는 가장 빠른 방법은 자율성 수준 입니다 — 원클릭
실행 취소로 전체 워크스페이스에 대해 Firewall 정책과 Guardrails 정책을
원자적으로 작성하는 단일 설정:
자율성 수준 Firewall 자세 Guardrails 자세 tight기본 거부; 파괴적 셸 + SSRF egress 차단 PII Shield + Secrets Blocker 켬 balanced기본 감사; 파괴적 셸 거부 PII Shield 감사 전용 (PII 플래그) permissive강제 규칙 없음; observe mode 켬 강제 없음
Firewall 콘솔에서 자율성 수준을 적용하고 (POST /api/workspace/firewall/autonomy,
Developer+), 그 다음 각 플레인을 독립적으로 조정하세요.
5. 요약 Guardrails는 텍스트를 소유하고; Firewall은 액션을 소유합니다 — 둘 다 실행하고,
자율성 수준이 이들을 연결하게 두고, 에이전트의 실제 트래픽을 볼 수 있을 때
각 플레인을 독립적으로 강화하세요.
Guardrails 규칙 타입, PII 탐지, LLM 심판, eval 하니스, API 레퍼런스.
Agent Firewall 판정, 표면, 자율성 수준, HITL 승인, API 레퍼런스.
