- 원문: arXiv:2609.27857
- 저자: Arash Vashagh
- 공개일: 2026-08-20
- 분야: LLM Agent Security, Asynchronous Systems, Tool Scheduling
- Tags: ChronosAttack, ToolScheduling, TimingAttack, AsyncAgent, OrderSensitivity
본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.
한눈에 보기
ChronosAttack은 tool response의 내용·개수·진위를 바꾸지 않고 일부 응답을 짧게 지연시켜 도착 순서만 바꾸는 공격입니다. 세 개의 authentic observation으로 세 후보 중 하나를 고르는 두 controlled scenario에서 66ms 또는 136ms의 non-negative delay가 최종 선택 비율을 크게 바꿨습니다.
GPT-5.6 Sol은 stateful Cloud scenario에서 target 선택이 0%→83.3%, Shipping에서 10.0%→66.7%로 이동했고 Claude Sonnet 4.6은 Cloud에서 46.7%→93.3%로 이동했습니다. 반면 Gemini 3.6 Flash는 같은 schedule에서 Cloud 100%→6.7%로 반대 방향으로 움직였고 DeepSeek V4 Flash는 변화가 작았습니다. 논문이 강하게 입증한 것은 order sensitivity이며, 특정 target으로의 schedule transfer가 모든 모델에서 통한다는 것은 아닙니다.
연구 배경
비동기 에이전트는 여러 tool call을 병렬로 보내고 완료되는 응답부터 context에 추가하거나 intermediate state를 갱신할 수 있습니다. 시스템은 latency를 단순 성능 문제로 취급하지만 LLM은 같은 증거도 serialization position과 이전 대화 state에 따라 다르게 가중할 수 있습니다.
기존 prompt injection, tool poisoning, memory poisoning은 공격자가 내용이나 명령을 바꿉니다. ChronosAttack은 payload integrity를 유지한 채 scheduler·queue·proxy의 지연 권한만으로 observation order를 조작한다는 점에서 공격 표면을 시간 축으로 확장합니다.
공격 모델 / 전제 조건
에이전트가 받는 authentic observation 집합 O={o1,...,om}과 각 natural arrival time ti가 있습니다. 공격자는 각 응답에 0≤δi≤ε의 지연만 더해 t'i=ti+δi로 만들 수 있습니다. 응답을 수정·추가·삭제·복제하거나 natural time보다 앞당길 수 없습니다.
공격 권한은 asynchronous middleware, request queue, proxy 또는 침해된 scheduler에서 선택된 response를 잠시 보류할 수 있는 수준입니다. tool 자체나 model weight, prompt를 바꿀 필요는 없습니다. 에이전트가 arrival order를 그대로 sequential state나 최종 prompt serialization에 반영해야 공격 표면이 생깁니다.
Cloud scenario의 natural order는 reliability→risk→cost이고 attack order는 risk→cost→reliability이며 reliability를 136ms 지연했습니다. Shipping은 delivery→claims→price에서 claims→delivery→price로 바꾸기 위해 delivery를 66ms 지연했습니다. payload hash는 SHA-256으로 검증했습니다.
비판적 검토 / 아쉬운 점
가장 큰 문제는 scenario가 두 개뿐이고 각 scenario가 세 observation·세 후보의 인위적 decision task라는 점입니다. 실제 agent workflow에는 dependent tool call, timeout, retry, failure, partial result, human approval이 섞입니다. 더 많은 task family와 실제 framework에서 decision-level business impact를 측정해야 외적 타당성이 생깁니다.
두 번째로 공격 schedule은 주 모델에서 찾은 뒤 다른 모델로 그대로 옮겼습니다. 따라서 Gemini의 reverse shift와 DeepSeek의 낮은 효과는 timing attack 저항성일 수도 있지만 단순히 schedule 방향이 해당 모델의 preference와 맞지 않았기 때문일 수 있습니다. 논문도 model-specific black-box schedule search를 향후 과제로 남겼습니다.
세 번째로 각 condition의 반복 수가 30회 또는 10~15회로 작고 cloud API 모델의 backend nondeterminism, provider update, temperature·seed 통제 수준이 상세하지 않습니다. 모델명이 같은 기간에도 backend가 바뀔 수 있으므로 exact model snapshot, decoding parameter, 응답 timestamp를 공개해야 재현성이 높아집니다.
네 번째로 target selection 변화가 곧 보안 피해는 아닙니다. 두 scenario는 후보 선택 분포 변화를 보여 주지만 공격자가 경제적·권한상 이득을 얻는 실제 workflow나 policy violation은 평가하지 않았습니다. security severity를 주장하려면 choice와 자금 이동·접근 승인·배포 같은 side effect 사이의 binding이 필요합니다.
핵심 Root Cause
구조적 원인은 같은 logical decision step의 병렬 evidence가 완전한 집합으로 정규화되지 않고 transport arrival order에 따라 model context와 intermediate state로 직렬화된다는 점입니다. 네트워크 timing이라는 비신뢰 메타데이터가 evidence importance와 decision trajectory에 영향을 주는 의미론적 입력으로 승격됩니다.
깨진 보안 불변조건은 “같은 authentic observation 집합은 허용된 bounded delay 안에서 도착 순서가 바뀌어도 같은 보안 결정 또는 허용 가능한 동등 결정 집합을 만들어야 한다”입니다. stateful agent에서는 초기 observation이 provisional choice와 summary를 남겨 뒤의 증거 해석을 편향하고, stateless agent에서도 단순 serialization order가 position bias를 만듭니다.
핵심 공격 원리
공격자는 원하는 permutation을 실현하기 위해 각 response에 필요한 최소 non-negative delay를 계산하고 consecutive arrival 사이에 1ms 간격을 둡니다. payload는 그대로 두므로 content integrity check를 통과하지만 LLM에 보이는 evidence order는 바뀝니다.
중요한 점은 delay 크기 자체보다 만들어진 순서입니다. 0·1·2 pairwise inversion 실험에서 한 번의 inversion이 두 번보다 더 큰 효과를 내는 경우가 있었습니다. 따라서 latency threshold만 감시하기보다 decision이 feasible schedule에 대해 일관적인지 확인해야 합니다.
공격 흐름
- 에이전트가 같은 logical step에서 세 tool을 비동기로 호출합니다.
- 각 tool은 수정되지 않은 authentic response를 반환합니다.
- 공격자가 proxy·queue·scheduler에서 선택된 response만 66ms 또는 136ms 보류합니다.
- 에이전트는 바뀐 arrival order대로 observation을 순차 처리하거나 한 prompt에 직렬화합니다.
- 모델의 provisional state·position bias가 evidence weighting을 바꿉니다.
- 모든 evidence가 동일한데도 최종 candidate 선택 분포가 달라집니다.
- barrier 또는 permutation consistency가 없다면 바뀐 선택이 downstream action으로 이어질 수 있습니다.
성공 조건 / 실패 조건
성공하려면 여러 tool response가 같은 decision에 영향을 주고, 공격자가 일부 delivery를 bounded delay로 제어할 수 있으며, agent가 arrival order를 canonicalize하지 않고, target model·task가 해당 permutation에 민감해야 합니다. 공격 schedule이 모델의 baseline preference와 반대 방향으로 작용하면 target attack은 실패하거나 reverse shift가 발생합니다.
Causal barrier가 같은 decision step의 observation을 모두 모은 뒤 canonical tool order로 한 번에 제공하면 timing으로 serialization을 바꿀 수 없어 실패합니다. 모든 feasible permutation을 평가해 6개 중 4개 이상이 같은 후보에 동의하지 않으면 abstain하는 order-consistency 방어도 공격자 통제를 줄입니다. 다만 model이 원래 target을 일관되게 선호하면 이 방어가 target 선택 자체를 제거하지는 않습니다.
연구진의 실험 환경
대상 모델은 GPT-5.6 Sol, Gemini 3.6 Flash, DeepSeek V4 Flash, Claude Sonnet 4.6입니다. 같은 prompt, payload, natural schedule, attack schedule을 네 모델에 공통 적용했고 model-specific schedule search는 하지 않았습니다.
stateful main experiment는 모델·scenario별 natural 30회와 attack 30회입니다. stateless serialization과 simultaneous control은 각 10회, inversion level 0·1·2는 각 15회, barrier defense는 15회, order-consistency는 10회이며 각 회마다 3!인 6개 permutation을 모두 실행했습니다. execution job 순서는 fixed random seed로 섞었습니다.
Stateful에서는 observation마다 history hj를 갱신하고 마지막에 결정하며 이전 provisional choice를 수정할 수 있습니다. Stateless에서는 모든 observation을 한 model call에 넣고 텍스트 순서만 바꿉니다. 모든 prompt는 arrival position을 중요도·품질·신뢰 지표로 사용하지 말라고 명시했습니다.
주요 실험 결과
Stateful fixed schedule에서 GPT-5.6 Sol의 target rate는 Cloud 0/30→25/30(83.3%), Shipping 3/30(10.0%)→20/30(66.7%)였습니다. Claude는 Cloud 14/30(46.7%)→28/30(93.3%), Shipping은 0/30→0/30이었습니다.
Gemini는 Cloud 30/30→2/30(6.7%), Shipping 30/30→24/30(80.0%)로 target 반대 방향의 큰 변화를 보였습니다. DeepSeek은 Cloud 2/30(6.7%)→4/30(13.3%), Shipping 4/30(13.3%)→6/30(20.0%)로 변화가 작았습니다.
Stateless Cloud에서도 GPT-5.6 Sol 1/10→6/10, Claude 0/10→10/10, DeepSeek 0/10→5/10으로 바뀌어 sequential memory가 필수 조건은 아님을 보였습니다. Shipping stateless 효과는 GPT 0/10→2/10, Gemini 6/10→9/10, DeepSeek 0/10→1/10, Claude 0/10→0/10으로 더 약했습니다.
inversion 분석에서 GPT Cloud는 0회 0%에서 1회 93.3%, 2회 93.3%였고 Shipping은 6.7%→86.7%→60.0%였습니다. Claude Cloud는 26.7%→100%→93.3%였습니다. 더 큰 perturbation이 항상 강하지 않았습니다.
Barrier는 GPT·Claude 두 scenario 모두 target rate를 0%로 만들었습니다. Gemini는 barrier에서도 100%였지만 simultaneous control에서도 원래 100% target preference였으므로 공격자 timing 통제로 해석할 수 없습니다. Order consistency는 GPT·Claude에서 target 결정을 0%로 만들었고 Claude Cloud의 10회는 모두 3:3 split로 abstain했습니다.
실제 발견된 취약점 / 사례
논문은 특정 상용 agent framework의 CVE나 production incident를 공개하지 않습니다. 발견된 것은 네 provider model을 동일 controlled harness에 넣었을 때 authentic evidence의 order만으로 decision distribution이 달라지는 동작 특성입니다.
가장 강한 사례는 GPT-5.6 Sol Cloud와 Claude Cloud이며, small delay와 single inversion만으로 target rate가 크게 상승했습니다. Gemini는 같은 schedule에서 반대 방향으로 이동해 “고정 공격 schedule의 보편성”이 아니라 “모델별 temporal sensitivity”를 보여 주는 사례입니다.
저자 주장 vs 실제 증명 범위
“tool-response timing이 agent decision interface의 일부가 될 수 있다”는 주장은 stateful·stateless·simultaneous control과 4개 모델의 반복 결과가 뒷받침합니다. “한 번의 scheduling inversion도 큰 변화를 낼 수 있고 delay 크기와 공격 강도가 단조 관계가 아니다”라는 주장도 inversion 실험으로 증명됩니다.
하지만 임의의 실제 agent를 특정 결정으로 조종할 수 있다거나, 66ms 지연이 production exploit에 충분하다는 것은 입증되지 않았습니다. 두 synthetic scenario, 고정 schedule, 제한된 반복의 결과이며 API update와 operational noise를 포함한 end-to-end 시스템은 평가하지 않았습니다.
기존 공격 / 기존 점검 방식과의 차이
Prompt injection과 tool poisoning은 observation content나 instruction을 악성으로 바꿉니다. ChronosAttack은 content hash가 동일한 진짜 응답만 사용하고 delivery time을 control variable로 삼습니다. 일반 integrity test는 모두 통과할 수 있습니다.
기존 position-bias 연구가 정적인 prompt에서 option 순서를 바꿨다면, 이 논문은 비동기 tool execution과 bounded delay를 통해 그 순서가 시스템 수준에서 공격 가능함을 연결합니다. stateful trajectory와 stateless serialization을 분리해 sequential memory 없이도 영향이 남는지 봤습니다.
연구의 한계와 주의해서 볼 부분
저자가 인정한 한계는 두 controlled task, 세 tool, 짧은 trajectory, 고정 schedule transfer, production system 부재입니다. network jitter, timeout, retry, dependent call, monitoring component가 상호작용하는 더 큰 workflow는 측정하지 않았습니다.
추가로 model API 버전과 backend가 변경되면 동일 결과가 재현되지 않을 수 있습니다. 논문의 모델명과 반복 수만으로는 decoding parameter, exact endpoint snapshot, provider-side routing을 완전히 고정할 수 없습니다. 방어의 비용도 평가하지 않았습니다. barrier는 latency를 늘리고, 6개 permutation 실행은 tool count가 커지면 factorial cost가 발생합니다.
공개 PoC / Exploit / Tool / Artifact 분석
ChronosAttack 공식 저장소는 저자가 공개한 재현 코드입니다. helper.py는 scenario, payload, scheduling, prompt, stateful execution, SHA-256 integrity check를 담고, chronos_multimodel_full.py는 confirmation·budget·barrier·consistency 실험을 실행하며 chronos_provider_adapter.py가 provider interface를 제공합니다.
Python 3.10 이상과 OpenAI·Gemini·DeepSeek·Anthropic provider credential이 필요합니다. README는 기본 반복 수, preflight, provider 선택, resume 옵션을 설명하지만 old exploratory result와 API ledger·checkpoint는 포함하지 않습니다. 따라서 코드는 공개됐지만 논문 수치를 재현하려면 유효한 유료 API 접근과 당시 model behavior가 필요합니다. 2026-09-25 확인 시 저장소는 공개 접근 가능했습니다.
레드팀 / 모의해킹에서 어떻게 활용할까
승인된 staging에서 같은 logical decision step의 tool response를 recording proxy로 지연시키고 payload hash, natural arrival, delivered arrival, model-visible order, provisional state, final choice를 모두 기록합니다. 먼저 content를 바꾸지 않는 one-inversion test로 시작하고 안전한 synthetic candidate만 사용합니다.
검증 기준은 한 번의 다른 답이 아니라 natural·permuted schedule의 반복 분포와 order-consistency입니다. 권한 승인, 자금 이동, 배포 같은 실제 side effect와 연결하지 말고 dry-run decision에서 멈춥니다. timeout·retry·중복 실행 또는 예상하지 못한 외부 action이 발생하면 즉시 중단합니다.
실제 점검 시 추가할 체크리스트
- 병렬 tool call이 같은 logical decision step에 속하는지 명시적으로 추적합니다.
- natural completion order와 model-visible serialization order를 별도 로그로 남깁니다.
- payload hash가 같아도 order change가 decision을 바꾸는지 반복 측정합니다.
- stateful history에 provisional choice나 early summary가 고착되는지 확인합니다.
- stateless prompt에서도 canonical tool ID 순서가 보장되는지 확인합니다.
- 0·1·2 inversion과 bounded delay를 사용해 비단조 민감도를 측정합니다.
- attacker가 queue priority, retry, backpressure, proxy buffer를 제어할 수 있는지 검토합니다.
- security-critical decision 전에 barrier synchronization을 적용합니다.
- feasible permutation 일부를 재평가해 consensus가 낮으면 abstain·human review로 보냅니다.
- barrier latency와 permutation 비용을 고려해 고위험 action에 선택적으로 적용합니다.
실무 가치 평가
비동기 에이전트 설계에서 latency를 보안 입력으로 재분류하게 한다는 점에서 실무 가치가 높습니다. tool 결과의 내용 검증만으로 충분하지 않고 같은 evidence set의 canonicalization과 schedule robustness가 필요하다는 점을 간단한 공격으로 보여 줍니다.
다만 현재 증거는 vulnerability class의 초기 실험에 가깝습니다. 실제 위험은 scheduler control 가능성, model·task별 sensitivity, decision과 side effect의 결합을 확인한 뒤 평가해야 하며, 논문의 큰 percentage shift를 곧바로 production exploit rate로 사용하면 안 됩니다.
결론
ChronosAttack은 authentic tool response도 언제 어떤 순서로 보이느냐에 따라 공격 입력이 될 수 있음을 보여 줍니다. 한 번의 작은 지연이 큰 decision shift를 만들 수 있지만 방향은 모델과 task마다 다르므로 핵심 위험은 보편적 target control보다 schedule sensitivity입니다.
동일 decision step의 결과를 barrier로 모아 canonical order로 제공하고, 고위험 결정은 여러 feasible order에서 일관성을 확인해야 합니다. 비동기 실행의 성능 최적화와 보안 결정의 의미론을 분리하는 것이 실무적 대응의 핵심입니다.
댓글