에이전트 보안 기준선

​

1. 자율성 제어가 하는 것

​

2. 수준을 적용하는 방법

# tight 시뮬레이션 — 전체 정책 diff를 반환하고, 아무것도 적용되지 않음
GET /api/workspace/firewall/simulate?level=tight

POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }

POST /api/workspace/firewall/autonomy/undo/:audit_id

​

3. 권장 경로

1. balanced 적용 — 전체 감사 추적을 얻게 됩니다; 파괴적 셸만 거부되고, 다른 모든 것은 감사됩니다. 하루나 이틀 동안 에이전트를 정상적으로 실행합니다.
2. tight 시뮬레이션 — GET /api/workspace/firewall/simulate?level=tight를 실행하고 거부될 것과 Events 피드에서 본 것을 비교합니다. 파괴적 셸 호출이나 SSRF 스타일의 아웃바운드 요청이 정상 트래픽의 일부라면, 먼저 에이전트에서 그것들을 수정하세요.
3. Events와 Matches 관찰 — Firewall → Events가 모든 툴 호출 판정을 보여주고; Guardrails → Matches가 콘텐츠 정책 히트를 보여줍니다. 둘 다 판정, 툴, 실행, 세션으로 필터링 가능합니다.
4. tight 적용 — 시뮬레이션 출력에 놀라움이 없으면, tight를 적용합니다. 프로덕션에서 무언가 깨지면 실행 취소가 한 번의 호출 거리입니다.
5. 규칙으로 조정 — Firewall 규칙을 사용하여 예외를 만들거나 프리셋 수준이 커버하지 않는 제어를 추가합니다. 자율성 수준이 기저이고; 커스텀 규칙이 정밀도를 추가합니다.

​

4. 역할 요구사항

​

5. 이것이 아닌 것

• 블랙 박스가 아닙니다. 자율성 수준을 적용하면 실제 firewall 정책과 guardrail (수준의 이름을 딴)을 작성하고 워크스페이스의 라이브 자세로 만듭니다. 나중에 열어서 검사하고 편집할 수 있습니다 — 잠긴 프리셋이 아닌 빠른 시작점입니다.
• 제한 내에서 되돌릴 수 있습니다. 원클릭 실행 취소는 감사 스냅샷에서 이전 Firewall과 Guardrails 상태를 복원합니다. 스냅샷이 감사 로그 크기 제한을 초과하는 매우 큰 워크스페이스의 경우, 적용은 여전히 성공하지만 그 변경에 대한 실행 취소가 불가능합니다 — 대신 원하는 수준을 다시 적용합니다. 드물지만 알아둘 가치가 있습니다.
• 범위 지정 키의 대체가 아닙니다. 자율성 제어는 워크스페이스의 기본 자세를 설정합니다. 개별 API 키는 더 세밀한 제어를 위해 특정 정책에 여전히 연결될 수 있습니다. Guardrails vs. Firewall에서 레이어가 구성되는 방법을 참조하세요.