위험 & 미승인 툴 호출

프롬프트 인젝션을 받거나, 잘못 구성되거나, 단순히 너무 많은 자유도를 부여받은 에이전트는 절대 건드려서는 안 될 툴을 호출하거나 — 또는 위험한 인자로 합법적인 툴을 호출할 수 있습니다: rm -rf /로 shell.exec, 과도한 이체 금액으로 결제 API, 프로덕션 복제본을 대상으로 하는 데이터베이스 툴. 이것은 에이전트 툴 남용이며, 툴 호출이 종종 되돌릴 수 없는 실제 세계 사이드 이펙트를 가지기 때문에 에이전트 시스템에서 가장 중대한 위험 중 하나입니다. Agent Firewall에는 세 가지 레이어드 방어가 있습니다. 독립적으로 또는 조합하여 배포할 수 있습니다.

1. 허용 목록: 명시적으로 허가하지 않은 모든 것을 거부

가장 강력한 제어는 허용 목록입니다. 모든 위험한 툴을 열거하려는 대신, 이 에이전트가 합법적으로 필요한 툴을 열거하고 — 그 외 모든 것을 거부합니다. 이것이 제로 트러스트 기준선입니다. default_verdict: deny와 각 승인된 툴에 대한 명시적 allow 규칙이 있는 정책이 이것을 달성합니다. 예시: CRM에서만 읽어야 하는 에이전트:

[
  {
    "priority": 10,
    "label": "allow crm reads",
    "tool_name_glob": "crm.get*",
    "verdict": "allow"
  },
  {
    "priority": 20,
    "label": "allow crm search",
    "tool_name_glob": "crm.search",
    "verdict": "allow"
  },
  {
    "priority": 9999,
    "label": "deny everything else",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]

shell.exec, db.delete, payment.transfer에 대한 모든 호출은 — 의도적으로 발행되든 주입된 지시사항에 의해 트리거되든 — * 캐치-올에 히트하고 HTTP 400 firewall_blocked 오류를 반환합니다. 에이전트가 구조화된 툴 오류를 보고 재시도할 수 없습니다 (차단은 skip-retry로 표시됨), 따라서 거부 주변을 루프할 수 없습니다.

전체 허용 목록 강제를 위해 정책의 default_verdict를 deny로 설정하세요. 기본 audit 판정으로는, 매칭되지 않은 호출이 허용되고 로깅되지만 차단되지 않습니다 — 롤아웃 중에는 유용하지만 그 자체로는 보안 제어가 아닙니다.

글로브 패턴을 사용하면 하나의 규칙으로 전체 툴 패밀리를 허용할 수 있습니다. 일반적인 패턴:

패턴	커버하는 것
`crm.*`	`crm` 네임스페이스의 모든 툴
`*.read`	모든 서버에 걸쳐 read 동사 툴
`db.query`	정확히 이 하나의 툴
`*`	모든 것 (캐치-올 deny에 사용)

툴 매칭은 오름차순 우선순위 순서로 첫 매치 승리입니다. 특정 allow 규칙을 낮은 우선순위 번호에, 캐치-올 deny를 높은 번호에 놓으세요.

2. 인자 검증: 툴은 허용하고, 위험한 호출은 차단

툴 이름의 허용 목록은 조잡합니다 — shell.exec를 완전히 차단합니다. 때로는 툴을 허가하되 어떻게 호출될 수 있는지 제한하고 싶을 수 있습니다. 인자 절을 사용하면 JSONPath와 연산자 집합을 사용하여 툴 호출 인자 내의 특정 필드를 매칭할 수 있습니다. 예시: shell.exec를 허용하되 rm -rf는 차단

{
  "priority": 10,
  "label": "block destructive rm",
  "tool_name_glob": "shell.exec",
  "args_match": {
    "clauses": [
      {
        "path": "$.command",
        "op": "regex",
        "value": "rm\\s+-[^\\s]*r[^\\s]*f|mkfs|dd\\s+if=|:\\(\\)\\{.*\\}"
      }
    ]
  },
  "verdict": "deny"
}

이 규칙은 shell.exec가 호출되고 $.command 인자가 파괴적 명령 정규식에 매칭될 때만 발동합니다. 안전한 명령으로 실행되는 일반 shell.exec 호출은 다음 규칙 (또는 기본 판정)으로 넘어갑니다. 이 규칙을 일반적인 allow shell.exec 규칙보다 낮은 우선순위 번호에 놓아 먼저 발동하게 하세요. 인자 연산자 전체 세트:

연산자	사용 시점
`eq`	스칼라 값 (문자열 또는 숫자)에 대한 정확한 매치
`contains`	부분 문자열 매치 — 예: `$.query` `contains` `DROP TABLE`
`regex`	RE2 패턴 매치 — 핫 경로에서 안전, 역추적 없음
`in`	값이 주어진 배열에 있어야 함 — 예: 특정 환경만 허용
`cidr_match`	CIDR 블록의 IP 주소 — egress 목적지 검사에 유용
`gt` / `lt`	숫자 비교 — 예: 결제 한도에 `$.amount` `gt` `10000`

args_match 블록의 모든 절은 AND입니다. 경로가 호출의 인자에 존재하지 않으면, 절은 false로 평가되고 규칙이 발동하지 않습니다 — 호출이 다음 규칙이나 기본값으로 넘어갑니다. 결제 가드 예시 — 임계값을 초과하는 금액의 결제 툴 호출 거부:

{
  "priority": 5,
  "label": "cap payment amount",
  "tool_name_glob": "payment.*",
  "args_match": {
    "clauses": [
      { "path": "$.amount_cents", "op": "gt", "value": 100000 }
    ]
  },
  "verdict": "deny"
}

3. 사람이 개입하는 승인: 위험도 높은 호출을 승인 대기로 보류

진정으로 필요하지만 위험도가 높은 툴에 대해 — 배포 트리거, 환불 승인, 대량 이메일 발송 — 호출이 진행되기 전에 사람의 서명을 요구할 수 있습니다. pending_approval 판정이 호출을 보류하고 에이전트에 firewall_approval_pending 응답을 반환합니다:

{
  "priority": 20,
  "label": "hold deployment calls for review",
  "tool_name_glob": "deploy.*",
  "verdict": "pending_approval"
}

에이전트 (또는 프레임워크)가 승인 id를 폴링합니다. 검토자가 콘솔에서 또는 웹훅 콜백을 통해 승인하거나 거부합니다. 승인되면, 에이전트가 일회용 승인 토큰으로 원래 호출을 재제출하고 게이트웨이가 한 번 통과시킵니다. pending_approval은 인자 절과 호환됩니다 — 임계값에 매칭하는 호출만 보류하고, 일반적인 것은 통과시킬 수 있습니다:

[
  {
    "priority": 10,
    "label": "hold large deploys",
    "tool_name_glob": "deploy.release",
    "args_match": {
      "clauses": [
        { "path": "$.environment", "op": "eq", "value": "production" }
      ]
    },
    "verdict": "pending_approval"
  },
  {
    "priority": 20,
    "label": "allow staging deploys",
    "tool_name_glob": "deploy.*",
    "verdict": "allow"
  }
]

4. 차단된 호출의 모습

inbound 표면 (요청에서 광고된 툴)의 거부된 호출은 오류 코드 firewall_blocked와 함께 HTTP 400을 반환합니다. 응답에는 구조화된 metadata — 매칭된 규칙 레이블, 이유 코드, 위험 요인 — 이 포함되며 skip-retry로 표시되어 루프가 동일한 거부된 호출을 반복할 수 없습니다. response 표면 (모델이 이미 tool_calls를 발행함)에서 차단된 호출은 모델에게 툴 오류를 반환하여, 모델이 반응할 기회를 줍니다 — 다른 툴 선택, 사용자에게 질문, 또는 중단 — 크래시 대신.

5. 첫 매치 승리 순서

우선순위 순서가 중요합니다. 엔진이 오름차순 우선순위 순서로 규칙을 거치며 첫 번째 매치에서 멈춥니다. 일반적인 패턴:

우선순위	규칙	판정
5	`shell.exec` + 파괴적 regex	`deny`
10	`shell.*` (일반)	`allow`
20	`crm.*`	`allow`
9999	`*` (캐치-올)	`deny`

우선순위 5가 우선순위 10 전에 발동합니다 — 따라서 파괴적 명령으로 shell.exec가 shell.*에 대한 일반 allow가 있더라도 거부됩니다. 낮은 우선순위 거부가 없으면, allow shell.* 규칙이 먼저 이깁니다.

6. Shadow mode로 안전하게 롤아웃

새 정책을 강제로 전환하기 전에, shadow mode를 켜세요. 정책이 모든 툴 호출을 프로덕션에서와 정확히 동일하게 평가하고 로깅하지만, 모든 강제 판정 (deny, pending_approval, sanitize)이 audit으로 강등됩니다 — 아무것도 차단되지 않습니다. 이벤트 로그의 이유에 [shadow] would deny가 접두되어 Events와 Runs 뷰에서 영향을 측정할 수 있습니다. 정책이 예상한 것에 발동하고 — 의도하지 않은 것에는 발동하지 않음을 확인한 후 — shadow mode를 끄세요. 다음 호출이 강제됩니다.

tight 자율성 수준은 block_destructive_shell 프리셋을 자동으로 적용합니다. 규칙을 작성하지 않고 빠른 자세가 필요하다면, 콘솔에서 tight를 적용하면 한 단계에서 파괴적 셸 호출에 대한 거부 정책이 제공됩니다. 그 다음 자체 허용 목록 규칙을 위에 레이어할 수 있습니다. 자율성 수준 참조.

7. 관련 위협

에이전트 툴 남용은 드물게 단독으로 도달합니다. 미승인 툴 호출은 종종 다른 공격 벡터의 결과입니다:

프롬프트 인젝션 — 공격자가 검색된 콘텐츠에 지시사항을 삽입하여 에이전트를 건드려서는 안 될 툴로 유도합니다.
과도한 권한 — 에이전트가 작업에 필요한 것보다 더 많은 툴 접근을 부여받아, 모든 인젝션이나 잘못된 구성이 즉시 위험합니다.
위협 모델 — 에이전트 시스템의 전체 공격 표면에서 툴 남용이 어디에 맞는지.

Agent Firewall이 강제 레이어이고; 최소 권한 원칙 (좁은 툴 허용 목록, 범위 지정 키)이 그것을 효과적으로 만드는 설계 자세입니다.

Firewall 규칙 레퍼런스

완전한 매칭 언어 — 툴 glob, 인자 절, 모든 연산자, 판정, API.

Firewall 개요

정책, 표면, 자율성 수준, HITL 승인, 관측성.

​1. 허용 목록: 명시적으로 허가하지 않은 모든 것을 거부

​2. 인자 검증: 툴은 허용하고, 위험한 호출은 차단

​3. 사람이 개입하는 승인: 위험도 높은 호출을 승인 대기로 보류

​4. 차단된 호출의 모습

​5. 첫 매치 승리 순서

​6. Shadow mode로 안전하게 롤아웃

​7. 관련 위협

Firewall 규칙 레퍼런스

Firewall 개요

1. 허용 목록: 명시적으로 허가하지 않은 모든 것을 거부

2. 인자 검증: 툴은 허용하고, 위험한 호출은 차단

3. 사람이 개입하는 승인: 위험도 높은 호출을 승인 대기로 보류

4. 차단된 호출의 모습

5. 첫 매치 승리 순서

6. Shadow mode로 안전하게 롤아웃

7. 관련 위협