메인 콘텐츠로 건너뛰기
대부분의 팀은 에이전트 보안을 너무 늦게, 한 번에 한 평면씩 사용합니다 — 여기 프롬프트에 regex 하나, 저기 툴 거부 목록 하나. 결과는 구멍이 있는 자세입니다: shell.exec을 결코 보지 못하는 텍스트 스크리닝, 또는 프롬프트에서 나가는 신용카드 번호를 결코 알아채지 못하는 툴 firewall. 완전한 에이전트 보안 기준선으로 가는 가장 빠른 방법은 두 평면을 한 번에 설정하는 것입니다. OrcaRouter의 자율성 컨트롤 — Secure Agents 기준선 — 이 정확히 그것을 합니다: firewall 정책 과 guardrail을 함께, 한 트랜잭션에서, 원클릭 실행 취소와 함께 쓰는 단일 워크스페이스 수준 스위치. 보호받기 위해 규칙을 작성하지 않습니다; 수준을 고르고 나중에 튜닝합니다.
두 평면은 중복이 아니라 상호 보완적입니다. Guardrails는 프롬프트/응답 텍스트(PII, 시크릿, 탈옥 및 인젝션 의도)를 스크리닝합니다; firewall은 에이전트가 취하는 액션(어떤 툴, MCP 호출, 그리고 호스트)을 통제합니다. 어느 하나만으로는 다른 하나가 메우는 갭을 남깁니다 — Guardrails vs. Firewall 참조.

​
1. 왜 하나의 기준선이 두 미봉책을 이기는가

실제 에이전트 실행은 단일 요청에서 두 평면을 모두 가로지릅니다. 모델은 프롬프트(텍스트)를 읽고, db.query을 호출하기로 결정하고(액션), 툴의 결과가 다음 턴으로 되돌아옵니다(다시 텍스트). 한 평면만 보안하면 다른 하나는 무방비로 남습니다:

Firewall만

파괴적 셸을 거부하지만, 프롬프트가 여전히 고객의 SSN을 모델로 곧장 나릅니다 — 그리고 툴 인자가 여전히 API 키를 누출합니다.

Guardrails만

프롬프트의 PII를 마스킹하지만, 에이전트가 여전히 rm -rf를 호출하고, 클라우드 메타데이터 엔드포인트에 도달하거나, 폭주 툴에서 루핑합니다.
자율성 컨트롤은 선택을 제거합니다. 한 수준이 두 평면 전반에 일관된 자세를 설정하므로, 하나는 구성되고 다른 하나는 아닌 윈도우가 없습니다.

​
2. 에이전트 보안 기준선: 세 수준

각 수준은 같은 두 평면을 커버합니다. 하나를 고르세요; 그것이 바닥이며, 나중에 규칙으로 정밀도를 더합니다.
수준FirewallGuardrailsObserve mode
tight기본 거부; 파괴적 셸 + fetch 형태 툴 거부PII Shield + Secrets Blocker 강제끔
balanced기본 감사; 파괴적 셸 거부감사 전용의 PII Shield(PII 플래그)끔
permissive강제 정책 없음없음켬 — 모든 호출을 갭으로 로깅
각 수준이 실제로 무엇을 잡는지를 형성하므로 못 박을 가치가 있는 몇 가지 세부:
tight은 firewall 정책의 기본 판정을 deny로 찍은 다음, 파괴적 명령을 담는 셸/exec 툴 이름 — shell.*, bash, cmd, powershell, exec — 과 SSRF를 담는 fetch 형태 툴 이름 — http_fetch, web_search, fetch_url, request(그리고 그들의 <server>.* MCP 네임스페이스 변형) — 에 대한 deny 규칙을 쌓습니다. 이 툴 이름을 거부합니다; CIDR나 클라우드 메타데이터 egress 규칙은 제공하지 않습니다. 169.254.169.254나 RFC-1918 범위를 목적지로 거부하고 싶으면, 자체 egress 규칙을 작성하세요 — Egress 제어 참조.
PII Shield와 Secrets Blocker guardrails 둘 다 활성이고 강제합니다. PII Shield는 요청이 모델에 도달하기 전에 PII를 마스킹합니다; Secrets Blocker는 요청의 자격 증명을 잡습니다. 툴 인자의 시크릿은 요청에서 이 guardrail에 의해 잡힙니다 — firewall은 기본적으로 그것을 벗겨내지 않습니다.
balanced은 모든 것을 감사하므로(기본 판정 audit) 에이전트의 실제 동작을 보면서, 여전히 가장 파괴적인 단일 부류 — 파괴적 셸 — 을 거부합니다. PII Shield는 감사 전용 모드로 실행됩니다(PII 플래그, 차단 안 함). 예상치 못한 block의 위험이 거의 없는 전체 추적을 얻은 다음, 추측이 아니라 가시성으로부터 조입니다.
permissive은 아무것도 강제하지 않습니다 — 우발적 block의 위험 제로로 완전히 새 에이전트를 관찰하기 위해 존재합니다. Observe mode는 켜진 채로 유지되므로, 모든 툴 호출은 여전히 커버리지 갭으로 로깅됩니다(Discovered Tools에서 보임). 에이전트의 형태를 학습한 다음, balanced이나 tight으로 이동하세요.

​
3. 하나의 구체적인 예: balanced 적용, 두 피드 관찰

수준 적용은 단일 콘솔 액션(Firewall → Posture)이거나 하나의 API 호출입니다. 라우트는 세션하에 실행되며 **Developer+**를 요구합니다. 
# Configure in the console, or POST under your session token (Developer+):
POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
응답은 **audit_id**를 담습니다 — 그것을 유지하세요; 그것이 실행 취소에 전달하는 것입니다. 일단 적용되면, 기준선은 다음 툴 호출에 라이브입니다. 재배포 없음, 에이전트 코드 변경 없음. 이제 두 평면을 한 번에 관찰합니다:
  • Firewall → Events — 모든 툴 호출 판정(audit, 거부된 파괴적 셸 호출). 이벤트 로그 참조.
  • Guardrails → Matches — 모든 콘텐츠 정책 히트(PII Shield 플래그).
balanced이 실제의, 편집 가능한 firewall 정책과 실제 guardrail(각각 수준 이름으로 명명됨)을 쓰므로, 그 후 어느 쪽이든 열어 튜닝할 수 있습니다 — 기준선은 잠긴 프리셋이 아니라 시작점입니다.
약속하기 전에 미리 보세요. GET /api/workspace/firewall/simulate?level=tight(Member, 읽기 전용)은 현재 상태에 대해 tight이 무엇을 변경할지 정확히 보여줍니다 — 아무것도 적용되지 않습니다. balanced에서 하루 이틀 후 그것을 실행하여 tight이 정상 트래픽의 일부인 호출을 거부하지 않음을 확인하세요.

​
4. 실행 취소는 한 호출

모든 자율성 변경은 감사 스냅샷에서 되돌릴 수 있으며, 일반 리셋이 아니라 정확한 이전 상태 — 정책, 규칙, guardrails, 그리고 설정 — 를 복원합니다. 
# Developer+; :audit_id is the value returned when you applied the level.
POST /api/workspace/firewall/autonomy/undo/:audit_id
스냅샷이 감사 로그 크기 제한을 초과하는 매우 큰 워크스페이스의 경우, 적용은 여전히 성공하지만 그 변경에 대해 원클릭 실행 취소를 사용할 수 없습니다 — 대신 원하는 수준을 다시 적용합니다. 이는 드물지만, 바쁜 프로덕션 워크스페이스를 조이기 전에 알아둘 가치가 있습니다.

​
5. 권장 경로

넓게 시작하고, 관찰하고, 그 다음 가시성의 위치에서 조이세요:
1

balanced 적용

전체 감사 추적; 파괴적 셸만 거부됨; PII 플래그됨. 에이전트를 하루 이틀 정상적으로 실행하세요.
2

tight Simulate

GET /api/workspace/firewall/simulate?level=tight 그리고 그 deny를 Events 피드가 실제로 보인 것과 비교하세요. fetch 형태나 파괴적 셸 호출이 정상 흐름의 일부라면, 먼저 에이전트를 고치세요.
3

tight 적용

simulate가 놀라움을 담지 않으면, tight으로 전환하세요. 프로덕션이 깨지면 실행 취소가 한 호출 거리에 있습니다.
4

규칙으로 튜닝

기준선은 바닥입니다. 예외를 깎아내거나 그것이 커버하지 않는 컨트롤을 firewall rules와 명명된 guardrails로 추가하세요. 더 미세한 범위를 위해 특정 정책이나 guardrail을 개별 키에 연결하세요.

​
6. 결합된 기준선의 역할

자율성 컨트롤은 두 평면에 걸치지만, 모든 액션은 역할 게이트됩니다.
액션최소 역할
수준 Simulate / guardrail Matches 보기 / Discovered Tools 보기Member
firewall Events & Runs 보기Developer+
자율성 수준 적용Developer+
자율성 변경 실행 취소Developer+
모든 구성은 세션하에 콘솔에서(/api/workspace/firewall/*와 /api/guardrail/*) 실행됩니다. /v1/* 릴레이 호출만 sk-orca-… 키를 사용합니다; 게이트웨이 키 라우트는 별도의 범위입니다. 범위: 키, 정책, 워크스페이스 참조.

​
7. 기준선 이후: 각 평면을 어디서 튜닝하는가

기준선은 처음 30분 만에 보호받게 합니다. 거기서부터, 각 평면은 정밀 작업을 위한 자체 레퍼런스를 가집니다:

Firewall 개요

판정, 표면, 인자 술어, 승인 — 액션 평면.

Guardrails

키워드, regex, PII, llm_judge, 그리고 grounding 규칙 — 콘텐츠 평면.

Shadow mode

강제하기 전에 조인 firewall 정책을 감사 전용으로 롤아웃합니다.

Secure Agents 기준선

자율성 컨트롤과 그 실행 취소 의미에 대한 개념 페이지.
기준선은 두 평면을 한 번에 닫는 바닥입니다; 규칙은 천장을 올리는 방법입니다. 계층이 어떻게 조합되는지는 AI 에이전트 보안과 제어 스택을, 이 기준선이 가장 직접 답하는 위협은 과도한 자율성을 참조하세요.