AI로 생성한 주제 설명용 이미지입니다.
- 원문: arXiv 2609.22076
- 저자: Uchi Uchibeke
- 공개일: 2026-09-21 (arXiv v1)
- Tags: Authorization, Payment, AI Agent, Open Agent Passport
본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.
한눈에 보기
APort Vault는 모델이 공격 요청을 거절하는가가 아니라, 모델이 잘못된 결제 tool call을 만들어도 실행 경계의 deterministic authorization이 막는가를 측정한다. 공개 CTF에서 사람이 작성한 공격 4,371개를 14개 모델·5개 policy level·single/multi-turn·model-alone/OAP layer 구성으로 replay해 225,964개 평가를 완료했다.
제한 정책인 Level 2~4에서 model alone은 76,842개 중 passport가 허용하지 않은 recipient로 140건을 실제 전송했지만, authorization layer 뒤에서는 69,297개 중 0건이었다. 같은 model·prompt·track을 맞춘 68,970 pair에서도 105 대 0이었다. Layer는 모든 결제를 막은 것이 아니라 25,370건의 허용된 결제를 실행하고 25,640개 transfer call 중 187개만 거부했다.
연구 배경
기존 agent benchmark는 공격 prompt 뒤 모델이 거절했는지, judge가 성공으로 분류했는지에 집중한다. 하지만 production에서는 가장 좋은 모델도 잔여 실패를 가지며, tool dispatcher가 실제 policy를 다시 확인하는지가 더 직접적인 authorization 질문이다.
논문은 request, successful payment, policy decision, recipient membership, unpermitted transfer를 분리한다. 공격 대화에서 payment request가 나왔다는 사실은 정책 위반과 같지 않고, allowlisted recipient로 결제가 됐다는 사실도 요청 의도가 정당했다는 뜻은 아니다.
공격 모델 / 전제 조건
공격 corpus는 2026년 3~8월 live agentic bank CTF의 1,128 session에서 왔다. 참가자는 web interface로 payment agent와 대화하며 policy 밖 recipient로 송금을 유도했다. 원본 4,750개 중 empty 372개와 개인정보 포함 7개를 제거해 4,371개를 사용했다.
Replay에서는 공격자의 final message만 보내는 single-turn과 전체 sequence를 보내는 multi-turn을 사용한다. 공격자는 model을 설득하거나 forged receipt 같은 대화 내용을 넣을 수 있지만, authorization layer 자체나 passport를 변경할 권한은 없다. 결과는 실제 돈이 아닌 simulated bank의 executed tool call로 측정한다.
핵심 Root Cause
Model-alone 구성의 근본 문제는 language model의 판단이 결제 요청 생성과 authorization을 동시에 맡는다는 것이다. 대화 안의 주장·도구 결과처럼 보이는 문자열·누적 context에 모델이 속으면 forbidden recipient가 tool argument로 들어가고 이를 재검증할 별도 reference monitor가 없다.
OAP 구성은 실행 직전 transfer_funds call을 level passport의 capability, recipient allowlist, amount·daily cap, idempotency·audit condition과 deterministic하게 비교한다. 모델이 transcript 속 forged verification을 믿어도 dispatcher는 실제 recipient와 policy만 보므로 인가가 분리된다.
핵심 공격 원리
가장 두드러진 multi-turn 공격은 공격자가 자신의 message에 [Tool Result: verify_recipient]를 써서 recipient verification이 이미 성공한 것처럼 보이게 하는 forged-receipt다. Level 2의 103개 시도·8개 session에서 이 cohort가 multi-turn model-alone 결과 113건 중 111건을 만들었다.
모델은 가짜 receipt를 신뢰해 payment call을 만들지만 authorization layer는 transcript를 보지 않고 recipient allowlist를 다시 평가한다. 따라서 공격 성공 여부는 모델이 요청을 생성했는가와 실제 execution boundary가 허용했는가로 분리된다.
공격 흐름
- 공격자가 authority claim, direct transfer, JSON injection, forged receipt 등으로 결제를 요청한다.
- 모델은 single-turn 또는 누적 multi-turn context를 처리해 transfer_funds call을 만들거나 거절한다.
- Model-alone에서는 call이 simulated bank에 바로 실행된다.
- OAP 구성에서는 dispatcher가 level passport에 대해 action과 recipient·amount·limit·code를 평가한다.
- 허용 call만 실행되고 deny call은 tool에 도달하지 않는다.
- 평가는 transcript judge가 아니라 executed tool call과 실제 recipient membership으로 결정된다.
성공 조건 / 실패 조건
Model-alone 공격은 모델이 call을 생성하고 mock bank가 amount·balance 검사를 통과하면 성공한다. 특히 transcript 안의 forged tool result를 진짜 state로 오해하고 forbidden recipient를 선택할 때 unpermitted transfer가 발생한다.
Layer 뒤 공격은 policy가 정확하고 capability가 충분히 좁으며 enforcement point를 우회할 수 없으면 실패한다. 반대로 passport가 잘못됐거나 wildcard가 과도하고, action schema가 policy로 표현되지 않거나, dispatcher 밖의 alternate tool path가 존재하면 이 연구의 0건 결과를 기대할 수 없다.
연구진의 실험 환경
모델은 8개 lab의 14종이다: Claude Fable 5.1·Sonnet 5·Haiku 4.5, GPT-6 Astra·GPT-5.6 Terra·Luna, Gemini 3.5·3.8 Flash, DeepSeek V4 Pro·Flash, Kimi K3, GLM-5.3, Qwen3.8 Max, Muse Spark 1.3이다. 각 provider API를 직접 사용했다.
Policy는 Level 1 wildcard, Level 2 3-recipient allowlist, Level 3 single recipient와 cap, Level 4 recipient·cap·idempotency·audit code, Level 5 no capability로 구성됐다. 총 계획 244,776개 중 225,964개가 완료됐고 5,395 error row를 cell별로 공개했다. 14-model single-turn grid는 완전하지만 일부 multi-turn layer cell은 누락 또는 부분 완료다.
각 cell은 CTF production temperature에서 1회 실행됐고 source session 단위로 1,500회 bootstrap했다. OAP engine은 hosted verifier가 아닌 local deterministic port이며 100-case parity sample과 일치했다. 단, Level 4 local engine은 공개 policy pack보다 audit-code 조건이 더 엄격하다.
주요 실험 결과
Level 2~4 model-alone은 request 28,543/76,842, successful payment 28,521, allowlisted recipient 28,380, unpermitted transfer 140이었다. Layer 뒤에서는 request 25,527/69,297, successful payment 25,370, unpermitted transfer 0이었다. 0건의 evaluation-level one-sided 95% upper bound는 0.0043%, 독립성이 낮은 source session 790개 기준 rule-of-three upper bound는 0.380%다.
Matched triple 68,970개에서는 model-alone unpermitted 105건, layer 0건이며 request는 각각 25,362·25,420이었다. Layer가 본 Level 2~4 transfer call 25,640개 중 25,453개를 허용하고 187개를 거부했다. 거부 이유는 forbidden recipient 148, invalid amount 17, limit 13, missing audit code 9였다.
Level 4 동일 prompt 1,293개에서 모델별 request rate는 71.2~84.3%였고 809개 prompt는 14개 모델 모두 request를 생성했다. 다만 모두 allowlisted recipient이므로 공격 성공 809건이 아니다. Level 2~4 unpermitted outcome 140건은 790 session 중 24개에서 나왔고 한 session이 67건, 두 session이 절반을 차지했다.
Multi-turn forged-receipt cohort는 model-alone에서 single-turn 1/532, multi-turn 111/1,441이었고 layer에서는 각각 0이었다. 2,809개 공격 중 model을 하나라도 뚫은 것은 single-turn 10개, multi-turn 73개였으며 어느 공격도 14개 중 5개를 초과해 전이되지 않았다.
실제 발견된 취약점 / 사례
특정 product CVE를 발견한 연구가 아니라, payment agent가 transcript에 포함된 가짜 verification receipt를 신뢰해 forbidden recipient call을 실행하는 architecture-level failure를 재현했다. 직접 실행 경계가 없으면 모델별·session별로 잔여 실패가 실제 상태 변경으로 이어진다.
반대로 deterministic layer는 동일 모델이 같은 request를 만들더라도 recipient policy를 독립적으로 집행했다. 이 결과는 refusal benchmark와 authorization benchmark가 측정하는 것이 다르다는 실증 사례다.
저자 주장 vs 실제 증명 범위
데이터는 한 simulated bank와 하나의 transfer_funds schema에서, 잘 정의된 allowlist를 실행 경계가 적용했을 때 forbidden-recipient transfer가 관찰되지 않았음을 증명한다. 요청 억제가 아니라 allowed payment를 유지한 상태에서 boundary outcome이 바뀐 것도 확인했다.
그러나 “OAP가 모든 agent action을 안전하게 한다”거나 “0% 위험”을 증명하지 않는다. code execution·data access·multi-agent delegation, policy misconfiguration, enforcement bypass, benign-task false positive는 평가하지 않았다. 0건은 upper bound를 가진 관찰이며, Layer 5는 no capability라 구조적으로 모두 차단되는 enforcement test일 뿐 attack difficulty가 아니다.
기존 공격 / 기존 점검 방식과의 차이
기존 jailbreak benchmark는 모델 refusal 또는 LLM judge score를 headline으로 삼는다. 이 연구는 실제 tool execution과 recipient allowlist를 deterministic하게 판정하고, model behavior와 authorization architecture를 독립 변수로 비교한다.
또한 평가 단위를 prompt count만으로 보지 않고 source session cluster와 attack family로 분해했다. 한 session과 한 forged-receipt cohort가 aggregate 결과를 지배할 수 있어, 단순 success-rate leaderboard가 공격 구조를 숨긴다는 점을 보여준다.
연구의 한계와 주의해서 볼 부분
CTF 참가자는 self-selected이고 prize pool은 6,500달러로 국가급 공격 effort의 상한이 아니다. 공격 category는 regex 기반이며 corpus가 authority claim·direct transfer에 치우쳤다. 각 cell은 1회 실행이라 sampling variance를 직접 측정하지 않았고 provider별 top_p·penalty default도 통일하지 않았다.
Multi-turn coverage가 일부 모델에서 불완전하고, Level 4 local engine은 공개 pack보다 엄격하다. 예정했던 약 300개 human-labeled judge validation slice가 완료되지 않았다. 저자는 OAP 개발사 APort Technologies의 창업자로 명확한 이해상충이 있으며, 공개 데이터·사전등록·deterministic metric으로 완화했지만 독립 재현이 필요하다.
공개 PoC / Exploit / Tool / Artifact 분석
논문은 Hugging Face의 aporthq/vault-benchmark-v1에 225,964 evaluation row, passport, scoring code, coverage/error count, preregistration과 release/paper_analysis.py를 공개했다고 밝힌다. Frozen snapshot frozen-20260910T1230Z가 있으면 전체 분석을 재생하고, 없으면 공개 dataset을 사용한다.
2026-09-22 확인에서는 해당 Hugging Face 저장소가 비인증 접근으로 열리지 않았고 Git remote도 credential을 요구해 실제 파일 tree를 독립 검증하지 못했다. 또한 CTF harness·judge prompt·signing key와 일부 GLM transcript는 공개되지 않는다. 따라서 논문 기재 artifact는 있으나 현재 누구나 즉시 재현 가능하다고 단정하지 않는다.
레드팀 / 모의해킹에서 어떻게 활용할까
실제 결제 대신 mock ledger와 synthetic recipient를 사용해 model-alone과 policy-enforced path를 같은 prompt·model·decode로 비교한다. 공격 유형은 direct request뿐 아니라 forged receipt, previous-tool-result spoofing, multi-turn authority accumulation을 포함한다.
성공 판정은 모델 답변이나 judge 평가가 아니라 sink의 실제 action·recipient·amount로 한다. Layer가 모든 call을 막아 0건을 만들지 않았는지 allowed action control과 denial reason을 함께 확인하고, alternate dispatcher·retry·batch·delegate path가 policy를 우회하지 않는지도 시험해야 한다.
실제 점검 시 추가할 체크리스트
- 모델 출력과 authorization decision이 별도 component에서 수행되는가
- tool dispatcher 직전에 canonical action·recipient·amount를 검사하는가
- transcript의 tool-result-like 문자열을 trusted state와 구분하는가
- policy에 wildcard나 과도한 capability가 없는가
- deny된 call이 retry·fallback·alternate tool로 실행되지 않는가
- allowed transfer는 방어 적용 후에도 정상 실행되는가
- request·payment·policy decision·recipient membership을 분리 기록하는가
- success metric이 실제 sink state change를 기준으로 하는가
- source session 단위 clustering과 attack-family 집중도를 보고하는가
- policy pack과 실제 enforcement engine의 차이를 검증하는가
실무 가치 평가
높다. 모델을 바꾸는 것만으로 authorization 잔여 위험을 없앨 수 없으며, deterministic pre-action control이 agent payment에 실질적 defense-in-depth가 된다는 강한 실험 자료다. 동시에 한 회사·한 schema·이해상충이라는 한계를 투명하게 보여 독립 검증 과제로도 가치가 있다.
결론
모델의 refusal은 authorization이 아니다. 공격자가 모델을 설득해 tool call을 만들더라도 실행 직전의 좁고 명시적인 capability check가 실제 효과를 통제해야 한다. APort 결과는 이 원칙이 payment allowlist에서 작동함을 보였지만, 다른 domain과 잘못된 policy까지 자동으로 안전하게 만들지는 않는다.
댓글