메인 콘텐츠로 건너뛰기
정적 firewall 규칙은 명명할 줄 알았던 호출을 잡습니다. 그것들은 개별적으로 허용되지만 집계상 틀린 호출은 잡을 수 없습니다 — 일요일 새벽 3시의 db.query 호출 200건, 좁은 루프에서 하나의 실패하는 툴을 두드리는 에이전트, 이 워크스페이스가 전에 한 적 없는 툴 간 홉. 각 호출은 모든 규칙을 통과합니다; 패턴이 문제입니다. Firewall 이상 탐지는 행동 계층입니다. 게이트웨이는 워크스페이스의 정상 툴 사용 형태를 학습하고 라이브 활동을 그것에 대해 채점하여, 모든 Member가 읽을 수 있는 피드에 편차를 표출합니다. 그것은 본 적 없는 형태에 대한 규칙을 미리 작성하지 않고도 손상된 에이전트나 폭주 루프를 알아채는 방법입니다. 이 페이지는 그 firewall 이상 탐지 피드를 위한 집중 랜딩입니다; Firewall 개요가 심층 레퍼런스입니다.
이상 피드는 탐지이지 강제가 아닙니다. 그것은 무엇이 어긋나 보이는지 알려줍니다 — 차단하지 않습니다. 패턴이 실제일 때, 그것을 규칙이나 속도 제한 판정으로 전환하여 다음 발생을 인라인으로 멈춥니다. 피드 읽기는 모든 Member에게 개방됩니다; 발견을 정책으로 전환하는 것은 Developer+입니다.

​
1. firewall 이상 탐지가 무엇을 플래그하는가

네 신호 종류, 각각 다른 실패 모드에 묶임:
툴별 호출 볼륨이 학습된 주중 시간대 베이스라인에 대해 채점됩니다. 툴은 그 카운트가 절대 바닥을 넘고 그리고 그 시간대의 베이스라인 대비 높게 실행되거나, 그 z-점수가 임계값을 넘으면 rate_spike를 발동합니다. (하루 시간이 아니라) 주중 시간대로 키가 지정된다는 것은 화요일 14:00이 과거 화요일 14:00에 비교됨을 의미하므로, 정당한 평일 피크 트래픽은 급증으로 읽히지 않지만 일요일 새벽 3시의 같은 볼륨은 그렇습니다.
같은 주중 시간대 비교를, 호출 카운트가 아니라 누적 비용에 적용. 지출이 학습된 비용 정상을 훌쩍 넘는 툴이 burn_spike로 표출됩니다 — 파괴적이기 전에 비싼 에이전트를 위한 조기 경고 신호.
좁은 윈도우 안에서 여러 번 반복되는 (conversation, tool, arguments) 그룹 — 회복하는 대신 같은 실패하는 툴 호출을 재발행하며 멈춘 에이전트. 느린 정당한 폴링은 그것을 발동하지 않습니다; 신호는 좁은 루프입니다.
이 워크스페이스가 학습된 베이스라인이 없는 tool_a → tool_b 연속 전이. 에이전트가 처음으로, 가령 crm.read → http.fetch로 가면, 그 엣지는 새롭습니다 — 정확히 데이터 유출 체인이 취하는 종류의 스텝.
이상 탐지는 시퀀스 규칙을 보완합니다. 시퀀스 규칙은 미리 정의한 체인에 매치합니다; novel_path는 정의하지 않은 전이를 플래그합니다 — 그것은 시퀀스 규칙을 작성할 가치가 있는 체인을 발견하는 방법입니다.

​
2. 14일 베이스라인

검출기는 고정 임계값이 아닙니다 — 학습된 정상입니다. 각 (tool, hour-of-week) 버킷에 대해 게이트웨이는 14일 룩백에서 백필된 롤링 예상 호출 카운트와 비용을 유지합니다(각 주중 시간대 버킷의 약 두 발생 — 주별 형태를 잃지 않고 단일 이상한 날을 매끄럽게 하기에 충분). novel_path는 병렬 전이 베이스라인을 사용합니다: 그 주중 시간대의 각 tool_a → tool_b 엣지에 대한 학습된 발생 카운트. 완전히 새 워크스페이스는 아직 베이스라인이 없습니다. 괜찮습니다: 학습된 정상이 없으면, 볼륨 검출기는 절대 바닥으로 폴백하므로, 시간대별 정상이 채워지는 동안에도 명백한 홍수는 첫날에 여전히 잡힙니다.
신호무엇에서 학습하는가
rate_spike / burn_spike(tool, hour-of-week)별 카운트와 비용, 14일 롤링.
novel_path(tool_a → tool_b, hour-of-week)별 전이 카운트.
retry_loop베이스라인 없음 — (conversation, tool, args)에 대한 윈도우 반복 임계값.
피드는 툴 이름, 가려진 토큰 id, 그리고 카운트만 보고합니다. 원시 API 키 id는 결코 나타나지 않습니다 — 각 항목은 호출하는 토큰의 단방향 다이제스트를 담으므로, 피드가 그 뒤의 키를 결코 누출하지 않고 두 이상을 구별할 수 있습니다.

​
3. 하나의 구체적인 읽기

에이전트 키가 루핑을 시작한다고 합시다. Security → Firewall → Anomalies에서 콘솔에서 피드를 끌어오거나, 직접 읽으세요 — 모든 Member가 할 수 있습니다: 
curl https://api.orcarouter.ai/api/workspace/firewall/anomalies \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN"

{
  "data": {
    "items": [
      {
        "id": "3f1c9a7b0e2d4a86",
        "kind": "retry_loop",
        "tool_name": "db.query",
        "token_id_redacted": "sk-***-9f2a",
        "count": 412,
        "baseline": 0,
        "z_score": 0,
        "suggested_action": "rate_limit",
        "first_seen": 1749470400,
        "last_seen": 1749470520
      }
    ],
    "snoozed_until": 0
  }
}
retry_loop 항목은 baseline이나 z_score를 담지 않으며(그 필드는 0으로 유지됨 — 그것들은 볼륨/비용 검출기에 속함), 안정적인 불투명 id를 담으므로 같은 툴의 두 구별되는 루프가 한 행에서 충돌하지 않습니다. rate_spike는 역입니다: 학습된 baseline과 z_score를 보고하고, id를 비워둡니다.
$ORCA_SESSION_TOKEN은 콘솔 세션 / 액세스 토큰입니다 — 모든 /api/workspace/firewall/* 관리 라우트와 같은 auth. 그것은 릴레이 sk-orca-… 키가 아니고(그것들은 /v1/* 모델 호출 전용) firewall-gateway 키도 아닙니다. 이 라우트의 릴레이 키는 거부됩니다.
각 항목은 툴, 가려진 토큰, 얼마나 많은 호출이 발동했는지, z-점수(볼륨/비용 신호만), 그리고 suggested_action(rate_limit, block_tool, 또는 review)을 명명합니다. 여기서부터 행동합니다: 툴에 deny 규칙을 떨어뜨리거나, 그 인자를 검증하거나, 이벤트 로그를 열어 에이전트가 정확히 무엇을 했는지 보세요.

​
4. 피드 스누즈

알려진 부하 테스트나 계획된 백필은 피드를 켤 것입니다. 노이즈를 쫓기보다, 스누즈하세요 — 최대 7일 동안: 
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/anomalies/snooze \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"until": 1749643200}'
스누즈가 활성인 동안 피드는 항목을 반환하지 않고 snoozed_until을 보고합니다; 마감이 지나는 순간 스스로 해소됩니다. 상한은 하드 천장입니다 — 더 멀리 잘못 입력되거나 적대적인 until은 클램프되므로 이상 탐지가 무한정 침묵될 수 없습니다. 과거나 지금의 until을 POST하면 기존 스누즈를 해소합니다.
피드 읽기는 Member 액션입니다; 그것을 스누즈하는 것은 **Developer+**입니다 — 워크스페이스 전역 안전 신호를 음소거하는 것은 읽기가 아니라 쓰기입니다.

​
5. RBAC 한눈에 보기

분석 표면은 일반적인 읽기/행동 라인을 따라 나뉩니다:
액션역할
이상 피드 읽기Member
설정, 정책, discovered tools 읽기Member
피드 스누즈Developer+
Events, runs, aggregate, traceDeveloper+
발견에서 규칙 작성Developer+
더 가벼운 집계 뷰 — 설정, 정책, 그리고 discovered-tools 커버리지 맵 — 도 Member 읽기입니다; 행 수준 이벤트와 실행 세부는 호출별 인자 데이터를 담으므로 Developer+입니다.

​
6. 신호에서 정책으로

피드는 끝이 아니라 루프의 시작입니다:
1

패턴 발견

novel_path나 rate_spike가 예상하지 못한 형태를 보입니다. 그것이 일회성이 아니라 실제인지 확인하기 위해 이벤트 로그에 대해 읽으세요.
2

규칙 작성

발견을 강제로 전환하세요 — block, 인자 절, 체인을 위한 시퀀스 규칙, 또는 burn을 위한 비용 상한.
3

안전하게 롤아웃

규칙을 먼저 shadow mode하에서 안착시켜 단일 호출을 차단하기 전에 폭발 반경을 측정한 다음, 강제하세요.

​
다음으로 갈 곳

Firewall 개요

전체 이상 탐지 레퍼런스와 정책 평면의 나머지.

이벤트 로그

이상에서 그 뒤의 정확한 호출로 파고듭니다.

툴 차단

발견을 강제 규칙으로 전환합니다.

강제 모드

탐지, 감사, shadow, 강제가 어떻게 함께 들어맞는가.
이 신호들이 노출하는 위협은 데이터 유출과 과도한 자율성을 참조하세요.