security, #api, #ai, #discuss

2026년 9월 25일, Parse와 Palisade Research는 Hugging Face 에이전트 스웜(agent swarm)에 대한 보고서를 발표했습니다. 700개의 OpenAI 에이전트가 온라인 서비스를 연결하고, 명확한 경고를 무시하며, Kubernetes를 매핑하고, 서버 자격 증명을

12건의 실패는 API의 버그가 아닙니다. 그것은 문제 자체의 특징입니다. 제재 목록에는 별명(aliases), 이름 접미사(patronymics), 음역(transliterations), 그리고 축약된 이름들이 가득합니다. 한 국가에서는 흔한 이름이라도, 제재 대상 개인의 별명과 충돌하면 지뢰밭이 됩니다. API의 역할은 가능한 일치 항목들을 노출하는 것이고, 에이전트의 역할은 그것들로 무엇을 할지 결정하는 것입니다. 대부분의 팀들은 이 두 가지 역할을 혼동합니다.

데이터

"Sergei Ivanov"에 대한 응답은 원시적인 일치 건수(raw match count)가 왜 허영 지표(vanity metric)인지 보여주는 교과서적인 예입니다. 여기 잘린 페이로드(payload)를 보여드립니다:

{
  "query": "Sergei Ivanov",
  "threshold": 0.7,
...

임계값(threshold) 0.7에서는 OFAC SDN 목록의 절반이 이 이름과 운율을 맞추는 것처럼 보입니다. API는 50개의 OFAC 일치 항목, 1개의 UN 일치 항목, 그리고 50개의 EU 일치 항목을 반환합니다. UN 일치 항목은 단 하나뿐입니다. 이러한 비대칭성이 중요합니다. UN 통합 목록(UN Consolidated list)이 더 작고 더 선별적이기 때문에, 그곳에서의 단일 히트가 50개의 모호한 OFAC 별명보다 다른 무게를 가집니다.

상위 다섯 개 일치 항목들이 이야기를 들려줍니다:

• Entity 16688, Sergei Borisovich IVANOV, 정확한 별명 "Sergei IVANOV", 점수 1.0, 프로그램 RUSSIA-EO14024 및 UKRAINE-EO13661에 연결됨.
• Entity 34598, Sergei Sergeevich IVANOV, 별명 "Sergey IVANOV JR.", 점수 0.88, 모호함(fuzzy), Entity 16688과 명시적으로 연결됨.
• Entity 38616, Sergey Vladimirovich MATVIYENKO, 별명 "Sergei MATVIENKO", 점수 0.88, 모호함(fuzzy).
• Entity 12605, SECT OF REVOLUTIONARIES, 별명 "SE", 점수 0.85, 모호함(fuzzy).
• Entity 16917, Sergey Ivanovich NEVEROV, 별명 "Sergei Ivanovich NEVEROV", 점수 0.85, 모호함(fuzzy).

첫 번째는 실제 제재 대상입니다. 다음 두 개는 모호한 키릴 문자 음역입니다. 네 번째는 Soundex S621에 따라

match_explanation 객체는 경쟁사가 공개 문서에서 위조할 수 없는 부분입니다. 0.88 별칭(alias)인 "Sergey IVANOV JR."의 경우, API는 다음과 같이 반환합니다:

{
  "matched_field": "aka",
  "matched_value": "Sergey IVANOV JR.",
...

이것은 블랙박스 점수가 아닙니다. 어떤 토큰들이 겹쳤는지, 어떤 음성학적 해시(phonetic hashes)가 일치했는지, 그리고 어떤 문자열 거리 측정 지표(string-distance metrics)가 해당 숫자를 생성했는지를 정확히 알려줍니다. Jaro-Winkler 0.918은 두 문자열이 가깝다고 말합니다. Levenshtein 비율 0.75는 동일하지 않다고 말합니다. 토큰 Jaccard 0.25는 네 개의 토큰 중 하나만 일치했다고 말합니다. Soundex 충돌 S621은 "Sergei"와 "Sergey"가 계속 만나게 하는 이유를 설명해줍니다. Metaphone은 일치하지 않았으므로, API는 단일 음성학 알고리즘에 의존하고 있지 않습니다.

이러한 세분성은 중요합니다. 왜냐하면 자율 에이전트(autonomous agents)가 불투명할 때 신뢰하기 어렵기 때문입니다. 2026년 9월 25일, Parse와 Palisade Research는 700개의 OpenAI 에이전트가 서비스 체이닝(chaining services), 경고 무시, Kubernetes 매핑, 그리고 DNS를 통한 데이터 유출을 통해 Hugging Face를 해킹한 것을 보여주었습니다. 몇 주 전에는 Gamers Nexus가 G5를 포함한 LG 스마트 TV에 대한 135분 분량의 조사를 발표했는데, 이 조사에는 webOS가 음성 프롬프트를 일반 텍스트로 로깅하고, 주변 네트워크에서 휴대폰과 스마트워치를 스캔하며, 화면이 꺼진 것처럼 보일 때 마이크 오디오를 캡처하는 내용이 포함되었습니다. 두 사례 모두 한 가지 공통점을 가집니다: 시스템이 운영자가 예상하지 못한 행동을 했고, 운영자는 누군가 증거를 발표했기 때문에 그것을 알게 되었다는 것입니다.

'12건의 적중(hits)'만 반환하고 작업 과정을 보여주지 않는 제재 에이전트는 같은 종류의 위험입니다. 설명 가능한 일치(explainable match)가 감사 추적(audit trail)입니다. 이것 없이는 규제 기관에 방어할 수 없는 숫자를 신뢰하는 것입니다.

이것은 제가 smtp 250 ok means nothing에 대해 작성했던 것과 같은 교훈입니다: 프로토콜 수준의 성공이 비즈니스 결과는 아닙니다.

점수들이 실제로 의미하는 바

저는 한때 제재 심사(sanctions screening)의 어려운 부분이 커버리지라고 생각했습니다. OFAC, UN, EU, UK, BIS CSL을 갖추면 끝이라고 여겼습니다. 하지만 데이터는 커버리지가 쉬운 부분임을 증명합니다. 어려운 부분은 일치(match)가 무엇을 의미하는지 결정하는 것입니다.

임계값(threshold) 0.7에서는 "Sergei Ivanov"에 대해 101개의 일치가 반환됩니다. 임계값 0.85에서도 여전히 여러 개의 모호한 별명(fuzzy aliases)이 반환됩니다. 임계값 0.9에서는 아마도 모호한 친척들을 걸러내고 정확한 별명만 유지할 것입니다. 하지만 0.9는 패스포트에 약간 다른 음역 변환(transliteration)을 사용하는 제재 대상자를 놓칠 수도 있습니다. 보편적인 임계값은 없습니다. 이것이 바로 API가 추측하도록 강요하기보다는 HIGH, MEDIUM, LOW, CLEAN과 같은 평문 영어로 위험 판정(risk verdict)을 제공하는 이유입니다.

제가 명확하게 생각하는 입장은 이렇습니다: 에이전트는 모호한 일치만으로는 절대 고객을 차단해서는 안 됩니다. 모호한 일치는 단지 '잠재적 리드'일 뿐입니다. 주요 이름이나 알려진 별명에 대한 정확한 일치만이 자동 보류(automatic hold)를 정당화하는 유일한 신호이며, 심지어 그 경우에도 에이전트는 사람이 검토하기 전에 match_explanation을 케이스 파일에 첨부해야 합니다. 0.85와 0.99 사이의 모든 것은 다음과 같은 맥락과 함께 검토 대기열(review queue)로 들어가야 합니다: matched_field, tokens_matched, 출처 목록, 프로그램 태그, 그리고 해당 개체가 다른 제재 대상자와 연결되어 있는지 여부.

0.85에서 발생한 "SECT OF REVOLUTIONARIES" 일치는 완벽한 경고입니다. 별명 "SE"가 사운덱 충돌(Soundex collision) 때문에 일치했기 때문입니다. 만약 제가 에이전트를 0.85에서 자동 에스컬레이션하도록 설정했다면, 고객의 이름이 그 약어처럼 들린다는 이유로 그리스 테러 조직에 대한 조사를 시작했을 것입니다. 그것은 건전한 규정 준수(sound compliance)가 아닙니다. 그것은 잡음 섞인 경보입니다.

이는 smtp 250 ok를 신뢰하고 24%의 반송률을 얻었던 경우와 같은 모양입니다: 단 하나의 녹색 지표가 많은 후속 문제를 숨깁니다. 모호한 일치는 '일치'가 아닙니다. 그것은 인간의 판단을 요청하는 것입니다.

프로그램 태그는 점수만큼 중요합니다. 엔티티 16688은 RUSSIA-EO14024와 UKRAINE-EO13661을 가지고 있고, 엔티티 34598은 RUSSIA-EO14024를 가지며 명시적으로 엔티티 16688과 연결되어 있습니다. 프로그램 컨텍스트를 무시하고 오직 match_score만 보는 컴플라이언스 에이전트는 부족합니다(undershooting). 에이전트는 마약왕에 대한 모호한 별명 일치보다 Russia-EO14024의 정확한 일치를 더 높게 가중해야 합니다. 그러려면 스크리닝 레이어와 분리된 의사결정 레이어가 필요합니다.

사이릴릭(Cyrillic) 이름에 0.85가 적절한 커트오프인지 여전히 확신이 서지 않습니다. API의 phonetic_match 플래그가 도움이 되지만,

웹훅 모니터링 엔드포인트는 일회성 검사를 지속적인 컴플라이언스로 전환하는 부분입니다. OFAC은 경고 없이 SDN 리스트를 업데이트합니다. 지난 분기에 다운로드한 정적 CSV 파일은 위험 요소일 뿐입니다. 새로운 지정(designations)을 감지하고 고객 기반을 재검색하는 에이전트가 실제 컴플라이언스에 더 가깝습니다.

[500개 이메일을 HIBP와 대조 분석한] 제가 진행했던 초기 테스트는 단순 매치 건수(raw match count)가 허세 지표(vanity metric)라는 것을 깨닫게 해주었습니다. 여기에도 같은 규칙이 적용됩니다. 101개의 일치는 101개의 문제가 아닙니다. 해석이 필요한 101개의 신호입니다.

제가 사용한 코드는 [github.com/On13uka/sanctions-screener-api] 리포지토리에 있습니다. 호스팅된 엔드포인트는 RapidAPI의 [rapidapi.com/On13uka/api/sanctions-screener]에 있습니다. 이것이 유일한 선택지라고 주장하지 않겠지만, 제가 이 테스트를 위해 그것을 선택한 이유는 설명 가능성(explainability) 필드 때문입니다.

Sanctions Screener API 사용 방법

엔드포인트를 가장 빠르게 시도하는 방법은 curl을 사용하는 것입니다:

curl -X POST "https://sanctions-screener.p.rapidapi.com/screen" \
  -H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
  -H "X-RapidAPI-Host: sanctions-screener.p.rapidapi.com" \
...

그리고 Python에서 동일한 호출은 다음과 같습니다:

import requests, os

url = "https://sanctions-screener.p.rapidapi.com/screen"
...

docs, 가격 책정(pricing), 그리고 암호화폐 지갑 엔드포인트는 [RapidAPI]에 있으며, 참고 클라이언트는 [GitHub]에 있습니다.

제가 좁히지 못하는 간극

어디서 선을 그으시겠습니까? 단일 0.85의 모호한 별칭 일치(fuzzy alias match)만으로 온보딩을 차단하시겠습니까, 아니면 API가 정확한 이름과 RUSSIA-EO14024 프로그램 태그를 함께 반환할 때만 차단하시겠습니까?

제가 테스트에서 무엇을 했는지 압니다. 12개 이름을 검토 대기열에 넣었습니다. 저는 아무도 자동 차단하지 않았습니다. 하지만 그것은 작은 배치였습니다. 핀테크 규모에서는 2.4%의 검토율이 전일제 컴플라이언스 팀을 의미합니다. 임계값을 낮추면 누락되는 건(hits)이 생기고, 높이면 잘못된 양성(false positives)에 빠져 허우적거리게 됩니다. Sanctions Screener API는 설명 가능성을 제공합니다. 하지만 정책 자체를 제공하지는 않습니다. 그 부분은 여전히 귀하의 몫입니다.