이미 허용된 API로의 AI 에이전트 트래픽 제한 (Rate-Limiting)

Originally published at webofmike.com on 2026-10-08. The demo repo and every command in it were run before publishing.

Egress allowlist는 에이전트가 특정 목적지에 도달할 수 있는지 여부만 결정합니다. 얼마나 자주 접근하는지에 대해서는 의견을 제시하지 않습니다. 2026년 10월 7일, Wikimedia Foundation은 어떠한 공격도 부여받지 않은 OpenAI 연구 에이전트들이 5월 12일부터 Wikipedia sandbox 페이지에 무단 편집을 했고, 호스팅된 Etherpad 인스턴스를 악용하려 시도했지만 실패했으며, 수십만 건의 쿼리를 Wikidata Query Service로 보냈다고 공개했습니다 (Simon Willison's writeup, HN discussion). 목적지 자체가 문제가 아니었습니다. 속도를 제한하는 것은 아무것도 없었습니다.

여기에 저장소(repo)가 있습니다: themsquared/agent-egress-rate-limits. 이 코드는 실제로 트래픽을 제한하는 제어 기능을 보여주는 실행 가능한 데모입니다.

허용 목록(allowlist)이 이를 다루지 못하는 이유

허용 목록은 목적지에 대한 예/아니오 결정일 뿐입니다. Wikidata가 포함되어 있거나, 아니면 그렇지 않습니다. 만약 에이전트의 업무가 공공 지식 그래프를 쿼리하는 것을 진정으로 포함한다면, 당연히 허용 목록에 포함됩니다. '허용됨(permitted)'이라는 것이 '어떤 속도로 허용됨'을 의미한다는 내용은 아무것도 없습니다.

저는 DNS를 차단된 목적지로 향하는 은밀한 채널(covert channel)로 사용한 사례와 허용된 레지스트리가 양방향 메시지 게시판 역할을 하는 사례에 대해 작성한 적이 있습니다. 두 경우 모두 에이전트가 가서는 안 될 곳에 도달하거나, 허용된 채널을 본래 목적 외의 용도로 사용하는 것에 관한 것입니다. 이번 사건은 그렇지 않습니다. Wikidata는 의도된 목적지였습니다. 문제는 규모(scale)입니다. 감시 없이 실행되는 벤치마크 하네스(benchmark harness), 백오프(backoff)가 없는 재시도 루프, 또는 여러 에이전트들이 독립적으로 동일한 공개 API에 접속하는 군집(swarm)은 악의적인 의도가 없고 어떠한 차단된 호스트도 없더라도, 위키미디어(Wikimedia)가 설명한 정확한 수준의 쿼리 볼륨을 생성할 수 있습니다.

허용 목록(allowlist)만으로는 '얼마나 자주'에 대한 답이 될 수 없습니다. 다른 무언가가 결정해야 합니다.

제어: 목적지가 아닌 경로에 대한 속도 제한 (rate limit)

agentgateway는 뒤에 무엇이 있든 상관없이 모든 HTTP 경로에 적용되는 로컬 속도 제한 정책(local rate limiting policy)을 가지고 있습니다. 동일한 백엔드와 동일한 경로를 가진 두 개의 동일한 agentgateway 인스턴스가 오직 이 블록만 다를 뿐입니다:

# config/guarded.yaml
binds:
-
port: 3000
...

maxTokens는 버스트 허용량(burst allowance)입니다. tokensPerFill과 fillInterval은 안정 상태의 재충전(steady-state refill)을 설정하며, 여기서는 초기 20회 사용 후 초당 5회 요청으로 드레인됩니다. type: requests가 중요합니다. agentgateway는 LLM 토큰 기반 제한을 위해 type: tokens도 지원하지만, 이것은 HTTP 요청 수를 계산하는 것이며, 이는 LLM 제공업체와 아무 관련이 없는 임의의 API를 호출하는 도구 호출(tool call)에 적합한 단위입니다.

이전 지점에서 정확하게 다룰 가치가 있는 부분이 있습니다. 왜냐하면 agentgateway에는 유사한 기능을 가진 예산(budget) 기능이 이미 존재하기 때문입니다. agentgateway v1.5.0은 API 키별 예산을 지원하며 이는 LLM 토큰 또는 달러 지출에 대해 범위가 지정되며, 모델 카탈로그를 기반으로 강제됩니다. 이것이 바로 '이 키로 이번 달 OpenAI 청구서를 다 태우지 않도록' 하는 데 적합한 도구입니다. 이 기능은 Wikidata 호출에 대한 의견을 갖지 않습니다. 왜냐하면 Wikidata는 LLM 제공업체가 아니며 예산의 토큰 계산 경로를 절대 건드리지 않기 때문입니다. localRateLimit은 별도의 일반적인 트래픽 정책으로, 상대방이 무엇인지 신경 쓰지 않습니다. 바로 이것이 도구 호출(tool-calling) 또는 MCP 백엔드 라우트가 필요로 하는 것입니다.

구현하기 (Reproducing it)

해당 저장소는 두 개의 agentgateway 경로 뒤에 모의 제3자 API를 구축합니다 (모든 쿼리에 응답하고 받은 요청 수를 세기 때문에, 상위(upstream) 숫자는 추정치가 아닌 정확한 수치입니다). 하나는 정책이 없는 경우이고, 다른 하나는 위에서 언급된 정책을 적용한 경우입니다.

git clone https://github.com/themsquared/agent-egress-rate-limits.git
cd agent-egress-rate-limits
docker compose up -d
...

curl이 보낼 수 있는 속도로 40개의 요청을 각 경로를 통해 전송합니다:

1. 보호되지 않은(UNGUARDED) 경로: localRateLimit 정책 없음.
   curl이 보낼 수 있는 가장 빠른 속도로 40개 요청 전송:
  40 x 200, 0 x 429
...

두 경로 사이에서 목적지에 대한 변화는 전혀 없었습니다. 동일한 모의 API이며, 어느 쪽으로든 허용됩니다. 보호되지 않은 상위(upstream) 경로는 모든 요청을 받았습니다. 반면, 보호된 경로는 클라이언트가 그 이후에 아무리 많은 요청을 보내더라도 정확히 할당된 버스트 허용량만 받았고 그 이상은 받지 못했습니다. 제한된 응답에는 표준 속도 제한 헤더가 포함됩니다:

HTTP/1.1 429 Too Many Requests
x-ratelimit-limit: 20
x-ratelimit-remaining: 0
...

scripts/verify.sh는 데모 출력을 육안으로 확인하는 대신 주장을 직접 검증합니다: 각 경로를 통해 60개의 요청을 발생시키고 보호되지 않은(unguarded) 상위 스트림이 모두 60개를 받았는지, 보호된(guarded) 상위 스트림은 더 적게 받았는지, 그리고 오직 보호된 경로만이 429 응답을 반환했는지만 확인합니다. 이번 실행 결과: 보호되지 않은 쪽은 60개 중 60개를 받고, 보호된 쪽은 18개를 받았습니다.

이것이 다루지 않는 것들

localRateLimit은 메모리 내(in-memory)이며 인스턴스별로 작동합니다. 복제본(replicas) 간에 카운터를 공유하지 않거나 재시작 후에도 유지되지 않습니다. 이는 단일 게이트웨이에는 문제가 없지만, 전체 플릿(fleet)에 걸친 정확한 전역 카운트를 위해서는 그렇지 않습니다. agentgateway는 해당 경우를 위해 Envoy rate-limit gRPC 프로토콜을 기반으로 공유 스토어에서 지원되는 원격 속도 제한(remote rate limiting)도 지원하며, 이는 본 저장소의 범위를 벗어납니다.

또한 이 시스템은 트래픽이 발생한 이유를 알려주지 않습니다. 원인에 관계없이—재시도 폭풍(retry storm), 벤치마크 하네스(benchmark harness), 또는 스웜(swarm)—이를 제한합니다. 이것이 실제 핵심입니다: 요청의 의도를 정확하게 분류할 필요 없이 폭발 반경(blast radius)을 제한할 수 있다는 것입니다. 그리고 모의 상위 스트림은 Wikidata가 아닙니다. 이는 요청 수를 세는 Python HTTP 서버입니다. 여기서의 버스트 크기(수십 개의 요청)는 '수십만 건의 쿼리'와는 거리가 멀며, 정책의 효과가 노트북에서 몇 초 만에 눈에 띄도록 크기가 조정되었습니다. 허용된 목적지 앞에 있는 토큰 버킷(token bucket) 메커니즘이 확장되는 것이지, 이 특정 수치들이 아닙니다.

본 저장소 어디에서도 에이전트 프레임워크는 보이지 않습니다. 루프 안의 curl은 에이전트의 툴 호출 루프를 대신합니다. 왜냐하면 게이트웨이는 연결의 클라이언트 측에 무엇이 있는지 알거나 신경 쓰지 않기 때문입니다. 이것이 바로 제어가 어떤 모델, 프레임워크 또는 오케스트레이션 계층이 호출을 하든 관계없이 작동하는 이유입니다.

이것이 들어맞는 곳 (적용 범위)

허용 목록(allowlist)은 '허용 여부'만을 결정합니다. DNS 필터링과 은닉 채널 탐지(covert-channel detection)는 허용된 채널이 본래 목적 외의 용도로 오용되는지를 감시합니다. 하지만 속도 제한(rate limit)은 이 모든 것이 커버하지 못하는 질문에 답합니다. 즉, '에이전트가 여기에 존재할 수 있는가?' 그리고 '그것이 의도했던 것보다 훨씬 빠른 속도로 요청하고 있지는 않은가?'입니다. Wikidata 사례의 해결책은 더 똑똑한 허용 목록을 만드는 것이 아니었습니다. 그것은 '허용됨'이라는 의미가 '무제한'으로 간주되는 빈도를 제한하는 것이었습니다.

Repo: themsquared/agent-egress-rate-limits. 저는 Solo.io에서 근무하며 agentgateway를 만듭니다.

자주 묻는 질문 (Frequently asked questions)

에그레스 허용 목록(egress allowlist)이 AI 에이전트가 허용된 API를 과부하하는 것을 막을 수 있나요?

아닙니다. 허용 목록은 단 하나의 질문, 즉 '이 에이전트가 이 호스트에 접근하는 것이 허용되는가?'만을 답할 뿐입니다. 빈도에 대해서는 아무것도 말해주지 않습니다. 목적지는 공용 API처럼 완전히 합법적일 수 있지만, 여전히 재시도 루프(retry loop)에 갇힌 에이전트나 독립적으로 동일한 엔드포인트가 유용하다고 판단하는 에이전트 무리로부터 피해를 입을 수 있습니다.

agentgateway로 제3자 API의 AI 에이전트 트래픽을 속도 제한하려면 어떻게 해야 하나요?

해당 백엔드 앞의 라우트에 localRateLimit 정책을 연결하세요. maxTokens는 버스트 크기(burst size)를 설정하고, tokensPerFill과 fillInterval은 재충전율(refill rate)을 설정하며, type: requests는 LLM 토큰 대신 요청 횟수를 계산합니다. 제한을 초과하는 요청은 업스트림에 도달하기 전에 게이트웨이로부터 HTTP 429 응답을 받게 됩니다.

agentgateway의 속도 제한 기능이 LLM 제공업체 호출에만 국한되나요?

아닙니다. agentgateway는 LLM 토큰 및 달러 지출에 따라 API 키별 예산(budget)도 가지고 있지만, localRateLimit은 별도의 일반적인 트래픽 정책입니다. 이는 모든 HTTP 라우트와 백엔드에 연결될 수 있으며, 이것이 바로 이를 LLM 제공업체뿐만 아니라 임의의 제3자 API를 호출하는 도구 호출이나 MCP 백엔드에 적합한 제어 장치로 만드는 이유입니다.

OpenAI 에이전트가 Wikimedia 인프라에 어떤 영향을 미쳤나요?

Wikimedia Foundation은 2026년 10월 7일, OpenAI 연구 에이전트가 공격 목적 없이 일반적인 연구 작업을 수행하는 과정에서 5월 12일부터 위키피디아(Wikipedia) 샌드박스 페이지에 무단 편집을 가하고, 호스팅된 Etherpad 인스턴스를 악용하려 시도했으며, Wikidata Query Service로 수십만 건의 쿼리를 전송했다고 공개했습니다.

정식 버전은 기계가 읽을 수 있는 마크다운 형식으로 https://webofmike.com/agent-egress-rate-limits/index.md에서 확인할 수 있습니다: https://webofmike.com/agent-egress-rate-limits/