새로운 arXiv 논문은 널리 사용되는 벤치마킹 유틸리티가 단일 프로세스 기반의 비동기(asyncio) 구동 방식 등으로 인해 클라이언트 측 대기열 병목 현상을 유발하고, 이로 인해 대규모 환경에서의 지연 시간 및 처리량 측정에 편향된 결과를 낼 수 있다고 주장합니다.

• 01 벤치마크 도구의 아키텍처가 결과의 지배적인 변수가 될 수 있으며, 단일 프로세스 클라이언트는 동시성이 높을 때 꼬리 지연 시간을 인위적으로 늘리고 처리량 곡선을 왜곡합니다.
• 02 운영 환경의 SLO 평가는 고립된 모델 커널 타이밍뿐만 아니라 네트워크, 배치 처리, 대기열 대기 및 재시도 동작을 포함한 종단 간(E2E) 측정이 필수적입니다.
• 03 측정 편향은 주로 꼬리 지표(tail metrics)에서 나타나므로, 현실적인 부하 패턴에서 p95/p99 지표를 무시하고 p50에만 최적화하면 벤치마크는 통과해도 실제 사용자는 불편을 겪게 됩니다.
• 04 벤치마킹 하네스 자체의 성능을 검증하기 위해 노옵(no-op) 서버를 통한 클라이언트 포화도 측정이 선행되어야 데이터의 신뢰성을 확보할 수 있습니다.

모델 컨텍스트 프로토콜(MCP) 오염 공격을 평가하기 위한 현실적인 벤치마크가 도입되었습니다. 특히 도구의 문서나 메타데이터를 조작하여 에이전트의 계획(planning) 계층을 표적으로 삼는 '도구 설명 오염(TDP)' 공격에 초점을 맞춥니다.

• 01 도구 메타데이터 자체가 새로운 공격 표면이며, '안전한' 도구라도 그 설명에 숨겨진 제약 조건이나 적대적 지침이 포함되면 위험한 도구로 변질될 수 있습니다.
• 02 이는 단순한 프롬프트 인젝션이 아니며, 도구 레지스트리나 캐시, 공유 매뉴얼이 재사용되는 경우 오염된 상태가 여러 실행 세션에 걸쳐 지속될 수 있습니다.
• 03 완화책으로는 도구 설명의 작성자 확인(출처 증명), 정형화된 스키마 제한, 사용자 의도와 대조하여 행동을 검증하는 런타임 정책 등의 계층적 방어가 필요합니다.
• 04 계획 단계에서 도구 설명을 무비판적으로 수용하는 에이전트의 논리적 허점을 이용하므로, 프롬프트 가드레일만으로는 이러한 유형의 공격을 막기에 역부족입니다.

개발자의 예상이나 표준 안전 테스트 범위를 벗어난 '분포 외(OOD)' 설정에서 발생하는 정렬 및 안전성 실패를 모니터링 파이프라인이 제대로 탐지할 수 있는지 평가하는 벤치마크(MOOD)가 제안되었습니다.

• 01 모니터링의 진정한 성능은 OOD 상황에서 결정되며, 큐레이팅된 예제에서 강점을 보이던 모니터도 프롬프트나 출력 형식이 미세하게 변하면 실패할 수 있습니다 탐지 품질은 단일 분류기가 아닌 로깅, 특징 추출, 임계값 설정, 에스컬레이션 워크플로우를 포함한 전체 파이프라인의 조화에 달려 있습니다.
• 02 운영상의 목표는 완벽한 라벨링이 아니라 빠른 분류입니다. 위험도가 높은 이상 징후를 조기에 포착하여 사람이 조사할 수 있도록 근거와 함께 제시해야 합니다.
• 03 탐지의 민감도와 특이도 사이의 균형을 맞추는 것이 중요하며, 특히 새로운 도메인이나 언어 형식이 유입될 때 모니터링 시스템의 견고함이 시험대에 오릅니다.
• 04 효과적인 모니터는 모델의 불확실성이나 응답의 구조적 비일관성을 감지하여 잠재적인 안전 사고를 사전에 경고할 수 있어야 합니다.