보안 자세를 적용하면 워크스페이스 설정이 변경되므로, 2단계와 5단계는
Developer 역할이 필요합니다. Guardrail Matches 피드 (4단계)는 모든
멤버에게 열려 있습니다; firewall Events 피드도 Developer가 필요합니다.
5단계로 켜기
API 키 받기
아직 없다면, 키를 생성하세요 —
API 키 받기 참조. 이 키를 보안하려는
에이전트에 제공하세요. 아래의 모든 것이 워크스페이스에 바인딩되므로,
동일한 자세가 그 안의 모든 키를 커버합니다.
에이전트 보안 기준선 적용
콘솔에서 Firewall → Posture를 열고
balanced
자율성 수준을 적용합니다
(Developer 역할).하나의 트랜잭션에서 Firewall과 Guardrails 자세 모두를 설정합니다:
툴 호출이 감사되고 PII가 플래그되며, 가장 파괴적인 액션 (파괴적 셸 등)은
거부됩니다 — 광범위하게 강제하기 전에 관찰합니다. 원클릭 실행 취소가
있는 단일 스위치입니다. (아무것도 차단하지 않는 패스라면, permissive에서
시작하세요.)이전과 동일하게 요청 보내기
호출에 대한 어떤 것도 변경되지 않습니다. 동일한 키, 동일한 OpenAI 형태를
사용하세요:요청이 통과됩니다.
balanced 아래에서 차단되지 않습니다 — 관찰됩니다.
이메일이 플래그되고, 에이전트가 하는 모든 툴 호출이 기록됩니다.에이전트가 실제로 무엇을 했는지 보기
두 개의 피드, 둘 다 워크스페이스 범위:
- Firewall → Events / Runs — 에이전트가 한 모든 툴 호출, 판정, 그리고 어떤 표면에 히트했는지 (광고한 툴, 모델이 발행한 호출, MCP 디스패치, 또는 아웃바운드 목적지).
- Guardrails → Matches — 발동한 모든 규칙 (플래그된 이메일 같은), guardrail과 액션별로 그룹화됨.
강제로 강화
피드가 올바르게 보이면, 동일한 Firewall → Posture 페이지에서 자율성
수준을 **
tight**으로 전환합니다 (Developer 역할).이제 강제가 라이브입니다: PII가 모델이 보기 전에 마스킹되고, 시크릿이
요청에서 차단되고, 파괴적 셸 호출과 SSRF egress가 거부됩니다. 거부된
툴 호출은 HTTP 400 firewall_blocked로 돌아옵니다; 차단된 프롬프트는
HTTP 400 guardrail_blocked로 돌아옵니다 — 그리고 차단은 쿼터를
소모하지 않습니다. 애플리케이션 변경 없음 — 바로 다음 요청이 관리됩니다.방금 켠 것
| 레이어 | balanced 아래에서 | tight 아래에서 |
|---|---|---|
| Guardrails (텍스트) | PII 플래그됨 (감사 전용) | PII 마스킹됨, 시크릿 차단됨 |
| Firewall (액션) | 감사됨; 파괴적 셸 거부됨 | 기본 거부; 파괴적 셸 + SSRF egress 거부됨 |
| 가시성 | 전체 — Events + Matches | 전체 — Events + Matches |
너무 엄격하게 만들었나요?
모든 자율성 변경은 원클릭 실행 취소가 있는 하나의 트랜잭션이므로, Firewall 페이지에서 (또는 실행 취소 API에서) 이전 자세로 바로 되돌릴 수 있습니다. 언제든지 더 부드러운 수준 (balanced 또는 permissive)을 다시 적용할 수도 있습니다.
다음 단계
에이전트 보안 기준선
각 자율성 수준이 설정하는 것과 적용 전에 시뮬레이션하는 방법.
강제 모드
Observe → shadow → enforce, 안전한 롤아웃 상세히.
Guardrails
기준선을 넘어서 자체 콘텐츠 규칙 작성.
Agent Firewall
툴 허용 목록, 인자 검사, egress 규칙 작성.
