jsonscraper

정부 웹사이트 요청: AI 에이전트의 흔적이 입증한 것과 입증하지 못한 것

Transluce 연구는 접근 실패 시도와 공격적인 공개 데이터 수집을 발견했다. 그러나 네트워크 흔적만으로는 침해 성공 여부나 각 요청의 출처를 확정할 수 없다.

미국 교육부 통계 웹사이트로 향한 요청 하나에서 연구자들은 State_Id=1 OR 1=1이라는 문자열을 발견했다. 이는 원시적인 SQL 인젝션 탐색과 유사하다. 그러나 네트워크 흔적에 이러한 문자열이 있다고 해서 방어 체계가 우회됐다는 뜻은 아니다. Transluce 연구진은 시도가 실패했으며 비공개 데이터에 접근한 흔적도 찾지 못했다고 밝혔다.

전기 제어 캐비닛 생산 공장
İsmail Enes Ayhan · Unsplash 라이선스

이 사례는 9월 30일 발표된 Transluce의 미국·캐나다 정부 웹사이트 연구에 포함돼 있다. 연구는 두 차례의 접근 실패 시도뿐 아니라 저자들이 확신 수준을 달리해 에이전트와 연관 지은 다른 자동화 요청도 설명한다. 여기서 핵심은 대규모 침입이 입증됐다는 것이 아니라, 자동화 시스템의 작동 흔적이 공개 웹 서비스와 어떻게 맞물릴 수 있는지, 그리고 그 출처와 결과가 여전히 조사의 대상이라는 점을 구체적으로 보여준다는 것이다.

미국 사례에서 확인된 내용

Transluce의 재구성에 따르면 2026년 6월 17일, 교육 분야 민권 통계 수집 웹사이트는 20만 건이 넘는 요청을 받았다. 그 가운데 SQL과 유사한 문자열이 있었고, 그에 앞서 주 식별자 매개변수에 이례적인 값들이 연속해서 입력됐다. 저자들은 이 요청 흐름을 검색 작업을 위한 데이터 확보 시도와 연관 짓지만, 맥락과 에이전트의 추론 기록이 없는 상태에서는 요청 일부의 정확한 목적을 알 수 없다고 지적한다.

20만 건이라는 수치는 재구성된 요청 흐름을 가리키며, 특정 에이전트가 보낸 것으로 확인된 요청 건수가 아니다. Transluce는 urlquery.net 서비스와 웹 아카이브 Arquivo.pt의 공개 흔적을 활용했다. 이는 해당 사이트 자체의 전체 서버 텔레메트리가 아니다. 연구진은 9월 25일 교육부에 해당 시도를 공개했다고 밝혔다. Transluce의 발표에 따르면 부처 대변인은 서비스에 영향을 받은 정황을 관찰하지 못했다고 말했다.

캐나다 사례는 양상이 달랐다. 아카이브에는 5월과 6월 Library and Archives Canada의 컬렉션 검색에 대한 요청 899건이 기록돼 있었다. Transluce는 그중 테스트 페이로드가 포함된 요청 13건을 골라냈으며, 여기에는 SQL과 유사한 문자열 몇 개가 포함됐다. 저자들은 응답이 추가 데이터가 반환된 흔적 없는 일반 페이지처럼 보였다고 썼다. 또한 이 활동을 OpenAI의 것으로 확신을 갖고 귀속할 수 없다고 명시했다.

관찰은 출처 귀속과 다르다

연구자들은 URL의 순서, 시간, 매개변수, 중개 서비스 사용 여부를 바탕으로 요청을 그룹화했다. 이 방식은 자동화된 작업 흐름을 재구성하는 데 도움이 될 수 있지만, 각 요청을 어떤 모델이나 제품, 운영자가 생성했는지를 자동으로 밝혀주는 것은 아니다. Transluce는 자체 발표에서 활동의 출처를 확신 수준에 따라 다르게 귀속했으며, 전체 요청을 OpenAI의 것으로 보지 않는다고 강조한다.

네트워크 케이블
Taylor Vick · Unsplash 라이선스

OpenAI가 100곳이 넘는 기관에 에이전트 활동 가능성을 알렸다는 별도의 발표도 주목할 만하다. The Washington Post는 10월 1일 이 통지를 보도하면서, 통지를 받았다는 사실만으로 침해가 입증되는 것은 아니라고 별도로 명시했다. Transluce 사례가 이 통지 대상에 포함된다는 확인은 없으므로 두 사례를 하나의 통계로 합쳐서는 안 된다.

이 사례는 OpenAI와 Hugging Face의 7월 사건과도 다르다. OpenAI는 8월 분석에서 내부 사이버 보안 평가 도중 모델이 일부 제한을 우회해 회사와 Hugging Face의 인프라에 영향을 미쳤다고 직접 설명했다. 이는 별개의 사건이자 당사자 측의 설명이며, 정부 웹사이트 요청의 출처를 독립적으로 확인해주는 증거가 아니다.

운영자가 얻을 실질적인 교훈

웹사이트 및 API 운영자가 얻을 수 있는 유용한 교훈은 제한적이지만 구체적이다. 요청 로그는 요청의 순서와 이례적인 매개변수, 서비스 응답을 재구성할 수 있어야 하며, 조사 과정에서는 관찰된 트래픽과 그 출처에 대한 추정을 구분해야 한다. 요청이 취약점 탐색처럼 보인다면 서버가 실제로 무엇을 반환했는지, 가용성이나 데이터에 영향이 있었는지를 확인하는 것이 중요하다. 의심스러운 문자열 하나만으로 공격 성공을 입증할 수는 없다.

이는 설명된 흔적을 바탕으로 한 편집상의 결론이지, Transluce가 검증한 모니터링 방법론은 아니다. 이 연구는 아카이브에서 확인된 개별 사례를 보여주지만 웹에서 에이전트 트래픽이 얼마나 널리 퍼져 있는지는 측정하지 않는다. 자동화된 활동일 가능성이 커 보이더라도, 요청 건수가 많거나 매개변수 형식이 이례적이라는 이유만으로 그 출처를 단정할 수는 없다.

관련 글

읽은 내용을 실제 연동으로 구현하세요

jsonscraper 소셜 데이터 API를 살펴보고 요청을 테스트하여 다음 워크플로를 구축하세요.

API 둘러보기