메인 콘텐츠로 건너뛰기
단일 툴 호출은 완벽하게 무해해 보일 수 있습니다. CRM 레코드 하나 읽기: 허용. export 툴 호출: 허용. 외부 호스트에 도달: 허용. 실행의 형태 — 50번 읽고, 그 다음 export, 그 다음 일요일 새벽 3시에 본 적 없는 호스트로의 egress — 가 공격입니다. 호출별 판정은 각 호출을 고립되게 판단하고 결코 그것을 보지 못합니다. 이 페이지는 한 번에 한 호출이 아니라 실행을 시간에 걸쳐 지켜보는 두 firewall 메커니즘을 다룹니다: 시퀀스 규칙(직접 작성하는 순서 있는 체인)과 행동 이상 탐지(워크스페이스의 학습된 정상에서의 편차). 함께라면 그것들은 어떤 단일 allow/deny 규칙도 잡을 수 없는 에이전트 공격 체인 동작을 탐지하는 방법입니다.
여기 모든 것은 콘솔(Security → Firewall)에서 구성되며, 그 관리 라우트는 세션 / 액세스 토큰을 사용합니다 — 릴레이 sk-orca-… 키가 아님. 에이전트의 /v1/* 호출은 변하지 않습니다.

​
1. 호출별 규칙이 체인을 놓치는 이유

firewall의 툴 glob과 인자 절은 설계상 무상태이고 결정론적입니다 — 핫 패스에서, 빠르게, 한 호출을 결정합니다. 그것이 “shell.exec rm -rf 차단”에 정확히 원하는 것입니다. 그것은 모든 개별 호출이 합법인 서서히 진행되는 유출에는 정확히 틀렸습니다. 두 상호 보완적 도구가 그 갭을 메웁니다:

시퀀스 규칙

시간 윈도우 안에서 호출의 순서 있는 체인에 매치하는, 직접 작성하는 규칙 — “벌크 읽기 → export → egress.” 패턴을 직접 명명합니다.

이상 탐지

firewall이 각 워크스페이스의 정상 툴 사용 형태를 학습하고 편차를 플래그 — 재시도 루프, 전에 본 적 없는 툴 경로, 그리고 볼륨/비용 급증. 작성할 규칙 없음.

​
2. 시퀀스 규칙: 공격 체인을 명명

sequence 규칙은 다른 규칙처럼 firewall 정책 안에 존재하지만, 단일 tool_name_glob 대신 순서 있는 스텝 목록을 담습니다. 각 스텝은 선택적 min_count와 선택적 egress: true를 가진 툴 glob입니다; 스텝은 순서대로 발생해야 하고(무관한 호출과의 교차는 괜찮음) 전체 체인은 window_seconds 안에 완료되어야 합니다. 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
이것은 에이전트가 50개 이상의 crm.* 레코드를 읽고, 그 다음 어떤 *.export 툴을 호출하고, 그 다음 어떤 egress 호출을 할 때 — 모두 10분 안에 — 발동합니다. 각 호출은 그 자체로는 통과합니다; 패턴이 신호입니다.
시퀀스는 그것을 완성하는 호출에서 평가됩니다. 인라인 규칙 루프는 체인 규칙을 건너뜁니다(한 호출은 다단계 체인을 만족시킬 수 없음); 호출이 체인의 마지막 스텝일 수 있을 때 매치가 실행되며, 그 시점에 firewall은 그 주체의 최근 이벤트를 끌어와 체인을 테스트합니다. 규칙에 설정한 verdict이 그 다음 완성하는 호출에 일어나는 일입니다: audit은 그것을 기록하고 통과시키고, pending_approval은 사람 검토를 위해 보류하고, deny은 그것을 차단합니다. 그래서 체인은 실시간으로 그 마지막 호출을 멈출 수 있습니다 — 맞는 판정을 고르세요. 탐지하고 경보만 하고 싶을 때 audit을 사용하고; 하드 스톱이 필요할 때 pending_approval이나 deny을 사용하세요(또는 호출별 deny / egress 규칙과 짝지으세요).
전체 sequence 필드 구문 — 시간 제한 없음을 위한 window_seconds: 0, min_count 기본값, 스텝 순서 의미 — 은 규칙 스키마에 있습니다. 시퀀스 규칙은 콘솔 규칙 편집기에서 작성하세요; 저장은 Developer+ 액션입니다.

​
3. 이상 탐지: 학습된 정상에서의 편차

시퀀스 규칙이 “이 특정 패턴이 일어났는가”를 묻는 곳에서, 이상 탐지는 “이 실행에 대한 무언가가 이 워크스페이스에 비정상인가”를 묻습니다. 그것은 규칙이 필요 없습니다 — firewall이 자체 트래픽에서 베이스라인을 구축하고 라이브 활동을 그것에 대해 채점합니다. 네 종류가 표출됩니다:
(tool, key)별 호출 볼륨이 이 주중 시간대의 학습된 베이스라인에 대해 채점됩니다. 카운트가 절대 바닥을 넘고 그리고 베이스라인 대비 높게 실행되거나, 그 z-점수가 통계적 임계값을 넘으면 행이 표출됩니다. 그래서 “일요일 새벽 3시의 db.query 호출 100건”은 화요일 오후 2시의 같은 크기의 폭발이 그러지 않을 때도 두드러집니다.
지출에 적용된 같은 아이디어: 이 주중 시간대의 학습된 베이스라인 비용의 배수를 태우는 툴. denial-of-wallet 조기 경고 — 하드 상한을 강제하기 위해 cap_cost 규칙과 짝지으세요.
좁은 윈도우에서 여러 번 반복되는 (conversation, tool, arguments) 그룹 — 느린 정당한 폴링이 아니라 같은 인자로 같은 실패하는 툴을 계속 호출하며 멈춘 에이전트.
이 워크스페이스가 전에 한 적 없는 tool_a → tool_b 전이. 에이전트가 처음으로 read_file에서 곧장 http_fetch로 가면, 두 툴이 개별적으로 허용되더라도 그 엣지가 켜집니다.

​
주중 시간대 베이스라인

베이스라인은 주중 시간대(weekday × 24 + hour)로 버킷화된 14일 롤링 평균이므로, 화요일 14:00은 평평한 전체 평균이 아니라 특정하게 과거 화요일 14:00 이력에 대해 비교됩니다 — 평평한 평균은 실제 일별 및 주별 리듬을 씻어낼 것입니다. 아직 학습된 정상이 없는 완전히 새 워크스페이스도 절대 바닥을 통해 명백한 홍수를 여전히 잡으므로, 첫날부터 보호됩니다.
피드는 툴 이름, 가려진 키 id, 카운트, 그리고 z-점수를 보고합니다 — 원시 키 자료는 결코 아닙니다. 각 이상은 제안된 교정(rate_limit, review, 또는 block_tool)을 지니므로 다음 단계는 추측이 아니라 원클릭입니다.

​
4. 하나의 구체적인 워크스루

손상된 프롬프트가 에이전트 중 하나를 좁은 실패 루프로 몰아넣은 다음, 건드린 적 없는 export 경로를 탐색한다고 합시다. 미리 작성한 규칙 없이 보게 되는 것은:
1

에이전트가 오작동

주입된 지시사항이 에이전트를 동일한 인자로 실패하는 db.query를 재시도하도록 밀어붙인 다음, report.export를 호출하고 이어서 아웃바운드 fetch — 이 워크스페이스가 실행한 적 없는 경로.
2

이상 피드 열기

Security → Firewall → Anomalies에서, 실행이 db.query의 retry_loop과 report.export → http_fetch 엣지의 novel_path를 표출합니다. 피드를 읽는 것은 Member 액션입니다 — 팀의 누구나 분류할 수 있습니다.
3

이벤트 트레이스에서 확인

이벤트 로그와 실행 분석으로 클릭해 들어가 정확한 호출 시퀀스를, 에이전트 실행과 대화에 상관시켜 보세요. 이상 피드는 Member 판독 가능하지만, 이벤트 로그와 실행 트레이스는 툴 호출 출처를 담으며 **Developer+**입니다.
4

발견을 규칙으로 전환

이제 체인을 보았으므로, 그것을 인코딩하세요: 위험한 export에 대한 deny, fetch에 대한 egress 허용 목록, 또는 다음번에 전체 패턴을 감사하는 시퀀스 규칙. 이상 탐지는 미지를 찾습니다; 규칙은 기지를 고정합니다.
튜닝하는 동안 피드가 시끄러우면 — 가령 매주 일요일 정말로 급증하는 정당한 배치 작업 — 조사하는 동안 이상 피드를 최대 7일 동안 스누즈하세요. 스누즈는 Developer+ 액션입니다; 윈도우는 서버 클램프되므로 탐지는 항상 스스로 다시 켜집니다.

​
5. 시퀀스 규칙 대 이상 탐지

그것들은 인접한 문제를 해결합니다 — 아는 것에 맞는 것을 고르세요:
시퀀스 규칙이상 탐지
직접 작성정확한 체인아무것도 — 학습함
잡는 것알려진 다단계 패턴미지 / 비정상
행동규칙의 판정을 완성하는 호출에 적용(audit / pending_approval / deny)피드에 표출
성숙한 워크스페이스는 둘 다 실행합니다: 이상 탐지는 예상치 못한 체인을 표출하는 레이더입니다 — 표출만, 결코 차단 안 함; 시퀀스 규칙은 가진 것을 성문화하는 방법으로, 레이블이 붙고, 추적되며, (pending_approval이나 deny 판정으로) 완성하는 호출을 게이트할 수 있습니다. 어떤 체인과도 무관하게 단일 호출에 하드 스톱을 하려면, 호출별 판정을 사용하세요.

​
6. RBAC & 피드 뒤의 라우트

이상 피드와 시퀀스 규칙은 워크스페이스 firewall 관리 라우트 아래에 위치합니다 — 세션 / 액세스 토큰, 결코 릴레이 키 아님:
메서드 및 경로역할목적
GET /api/workspace/firewall/anomaliesMember이상 피드 읽기(?window=).
POST /api/workspace/firewall/anomalies/snoozeDeveloper+피드 스누즈({until}, 7일로 클램프).
POST /api/workspace/firewall/rulesDeveloper+정책 아래 시퀀스(또는 모든) 규칙 생성.
POST /api/workspace/firewall/testDeveloper+의존하기 전에 샘플 호출에 대해 정책 dry-run.
피드 읽기는 모든 Member에게 개방되어 전체 팀이 분류할 수 있습니다; 규칙 작성과 피드 스누즈는 Developer+ 쓰기이며, 나머지 firewall RBAC 모델과 일관됩니다.

​
다음으로 갈 곳

규칙 스키마

전체 sequence 필드 — 스텝, min_count, window_seconds, 그리고 다른 모든 규칙 필드.

이벤트 로그

매치된 시퀀스와 이상이 떨어지는 곳 — 실행, 표면, 판정으로 필터링.

Cap cost

burn_spike 신호를 하드 실행별 지출 상한으로 전환합니다.

Egress 제어

네트워크 경계에서 체인의 마지막 유출 스텝을 멈춥니다.
이 메커니즘들이 대응하는 공격자 플레이북은 연쇄 공격, 데이터 유출, 그리고 과도한 자율성을 참조하세요. 심층 firewall 레퍼런스는 Firewall rules를 참조하세요.