ASE 2026에 채택된 논문 — ["How Your Credentials Are Leaked by LLM Agent Skills: An Empirical Study">(https://arxiv.org/abs/2604.03070) (Chen et al.)] — 는 대부분의 에이전트 보안 논의가 하지 못했던 일을 해냈습니다. 바로 측정(measure)을 한 것입니다. 저자들은 17,022개의 제3자 에이전트 "기술(skills)"을 샘플링하여 그 안에서 자격 증명(credentials)이 유출되는지 조사했습니다. 그 결과는 깊이 고민해 볼 가치가 있습니다.

수치

• 520개의 기술이 1,708개의 개별 이슈를 통해 자격 증명을 유출했습니다.
• 유출된 자격 증명의 **89.6%**는 **즉시 악용 가능(immediately exploitable)**했습니다. 그중 92.5%는 권한 상승(privilege escalation) 없이 일상적인 실행 과정에서 악용될 수 있었습니다.
• **107개의 상위 리포지토리(upstream repositories)**에서 제거된 비밀 정보(secrets)가 **50개 이상의 포크(forks)**에 걸쳐 지속되었습니다. 즉, "우리가 패치했다"는 말이 하위 스트림(downstream)에서는 실제로 문제를 해결하지 못했다는 뜻입니다.

하지만 가장 유용한 단일 발견은 바로 그 _메커니즘(mechanism)_입니다.

지배적인 원인은 지루하며, 바로 그것이 핵심입니다

유출의 73.5%는 디버그 로깅(debug logging)에서 발생했습니다.

교묘한 익스플로잇(exploit)도, 새로운 공격 방식도 아닙니다. 디버그 로깅입니다. 이것이 들리는 것만큼 어리석지 않은 이유는 다음과 같습니다. 대부분의 에이전트 프레임워크에서 도구의 표준 출력(stdout)은 모델의 컨텍스트 윈도우(context window)로 직접 파이프(pipe) 연결되며, 거기서부터 여러분의 트레이스(traces)와 로그(logs)로 이어집니다. 따라서 기술(skill)이 디버깅을 위해 무언가를 출력하는 순간, 그리고 그 내용에 API 키나 토큰이 포함되어 있다면, 해당 비밀 정보는 모델에게 전달되고 여러분의 로그에 기록됩니다. 누군가 유출하기로 결정한 것이 아닙니다. 배관(plumbing)이 그렇게 작동한 것입니다.

이는 에이전트의 데이터 위생(data hygiene)에 대해 생각하는 방식을 재정립합니다. 우리는 프롬프트 인젝션(prompt injection), 신뢰할 수 없는 문서, 오염된 도구 설명 등 들어오는 정보에 대부분의 주의를 기울입니다. 하지만 도구의 **출력(output) 또한 유출 채널(leakage channel)**이며, 반대 방향으로 작동합니다. 그리고 이 연구는 실제 환경에서 이 채널이 가장 많은 피해를 주고 있음을 발견했습니다.

실제로 취해야 할 조치

영향력(leverage)이 큰 순서대로 세 가지를 제안합니다:

1. 도구 출력 경로(tool-output path)에서 비밀 정보(secrets)를 삭제(Redact)하세요 — 컨텍스트 윈도우(context window)나 로그에 도달하기 전에 수행해야 합니다. 신뢰할 수 없는 입력(untrusted input)에 적용하는 것과 동일한 규율을 반대 방향으로 적용하는 것입니다. stdout에 포함된 비밀 정보 형태의 문자열은 프레임워크가 이를 어디론가 전달하기 전에 반드시 삭제(scrub)되어야 합니다.
2. 자격 증명(credentials)의 권한 범위를 제한(capability-scoped)하고 유효 기간을 짧게 유지하세요. 연구 결과에 따르면 유출된 비밀 정보의 89.6%가 즉시 악용 가능한 상태였는데, 이는 주로 권한이 광범위하고 유효 기간이 길었기 때문입니다. 유출된 15분짜리 읽기 전용(read-only) 토큰은 유출된 상시 관리자 권한(standing god-credential)보다 훨씬 작은 문제입니다.
3. 스킬(skills)을 검증(Vet)하고, 다시 검증하세요. 포크-지속성(fork-persistence) 발견은 당신이 승인한 스킬이 당신도 모르는 사이에 변경될 수 있음을 상기시켜 줍니다. 스킬을 고정(Pin)하고, 지문(fingerprint, 코드/설명의 해시값)을 생성하며, 로드될 때마다 다시 확인하세요.

이 중 어느 것도 새로운 인프라를 필요로 하지 않습니다. 도구 입력(tool input)에 이미 적용하고 있는 것과 동일한 의심을 도구 출력(tool output)에도 적용하기만 하면 됩니다.

이 연구는 자율형 AI 에이전트 보안을 위한 개방형, 벤더 중립적 프레임워크인 *BRACE*의 근거 자료 중 하나입니다. BRACE의 런타임 가이드(run-time guide)는 바로 이 점을 다룹니다 — 데이터 위생(data hygiene)은 양방향으로 작동하며, 도구 출력은 유출 채널(leakage channel)이 됩니다. BRACE는 사고 사례와 연구를 분석하며 매번 다음과 같은 질문을 던지며 구축되었습니다: '어떤 구체적인 통제(control)가 이 사건을 방지하거나 억제할 수 있었을까?'_