지난 5월, 누군가 모스 부호(Morse code)를 전송하여 AI 트레이딩 에이전트로부터 약 20만 달러를 탈취했습니다.

취약점 공격(Exploit)도, 탈취된 키(Keys) 문제도 아니었습니다. 공격자는 Grok에게 모스 부호 메시지를 번역해 달라고 요청했고, Grok은 친절하게도 이를 송금 지침으로 해독하여 트레이딩 봇을 태그했습니다. 그리고 봇은 이를 실행했습니다. 다른 AI가 보낸 공개 답장이 권한이 있는 사람의 명령과 정확히 일치해 보였기 때문입니다. 사고 분석에 따른 근본 원인은 소스 검증(Source validation)의 부재였습니다.

3주 전에는 더 황당한 일이 있었습니다. Zscaler는 악성 웹페이지가 자율 브라우징 에이전트(Autonomous browsing agents)를 속여, 존재하지 않는 Python 패키지에 대한 가짜 "$3.00 개발자 API 라이선스" 비용과 공격자의 지갑으로 소량의 ETH 팁을 지불하도록 유도하는 실시간 캠페인을 포착했습니다. 테스트된 26개 모델 중 4개가 실제로 결제했습니다. AI 에이전트가 가짜 인보이스(Invoice)에 속아 기계의 속도로 사기를 당한 것입니다.

저는 2024년 이후 문서화된 모든 AI 에이전트 보안 사고의 타임라인을 관리하고 있으며, 모든 항목에는 날짜와 출처가 명시되어 있습니다. 이 모든 사례를 분류한 결과, 아무도 솔직하게 말하고 싶어 하지 않는 사실을 발견했습니다. 그것은 매번 동일한 버그라는 점입니다. 에이전트가 명령을 받아서는 안 될 곳으로부터 텍스트를 받았고, 그 명령을 수행했다는 것입니다. 웹페이지, GitHub 댓글, 다른 봇의 답장, SharePoint 양식 필드 등 콘텐츠는 매우 다양합니다. 하지만 출처 검증 실패(Provenance failure)라는 본질은 동일합니다.

콘텐츠 검사(Content inspection)는 예정대로 계속 패배하고 있습니다

업계의 해답은 텍스트를 더 철저히 읽는 것이었습니다. 스캐너(Scanners), 차단 목록(Denylists), 인젝션 분류기(Injection classifiers), 명령 문자열에 대한 가드(Guards) 등이 동원되었습니다. 타임라인에 따르면, 6월 30일 연구진은 11개의 오픈 소스 코딩 에이전트를 대상으로 패턴 기반 명령 가드를 테스트했습니다. 10개 모델에서 우회(Bypass)가 가능했는데, 그 이유는 Bash가 가드가 원시 문자열(Raw string)을 읽은 후 명령을 확장(Expands), 치환(Substitutes), 따옴표 제거(Unquotes)하기 때문입니다. 가드는 텍스트를 읽었지만, 텍스트는 거짓을 말했습니다. 수십 년 된 셸 트릭(Shell trick)이 AI를 상대로 다시 태어난 것입니다.

그리고 지난주, 내부 조사(internal probes)를 진행하던 연구원들은 왜 이런 일이 끊이지 않는지 마침내 밝혀냈습니다. LLM(대규모 언어 모델)은 태그(tags)로부터 역할을 식별하는 것이 아니라, 문체(writing style)로부터 역할을 식별합니다. 작동 중인 공격에서 인간이 거의 알아차릴 수 없는 수준의 문체적 표식(stylistic markers)을 제거하자, 공격 성공률이 61%에서 10%로 급락했습니다. 모델은 신분증(IDs)을 확인한 것이 아니었습니다. 그저 직원처럼 차려입은 사람이 누구인지를 확인하고 있었던 것입니다. 옷차림으로 사람을 식별하는 구성 요소(component)로는 스푸핑(spoofing, 속이기) 문제를 해결할 수 없습니다.

한편, Google은 4개월 동안 공개 웹(open web)에서 악성 프롬프트 인젝션(prompt injection) 페이지가 32% 증가했음을 측정했습니다. 공격자들은 어느 쪽이 승기를 잡고 있는지 알고 있습니다.

답을 알 수 있는 질문

타임라인에 있는 모든 사건이 모스 부호 강도 사건(Morse code heist)과 공통적으로 가진 점은 다음과 같습니다. 실패하는 순간, 소프트웨어의 어떤 부분은 해당 악성 텍스트가 어디에서 왔는지 100% 확신하며 알고 있었다는 사실입니다. 오케스트레이션 계층(orchestration layer)이 해당 웹페이지를 가져왔습니다. 해당 GitHub 댓글을 불러왔습니다. 해당 봇의 답변을 수신했습니다. 출처(Provenance)는 결코 미스터리가 아니었습니다. 단지 참조(consulted)되지 않았을 뿐입니다.

그러니 출처를 참조하십시오. 그것이 바로 출처 기반 사전 조치 권한 부여(provenance-based pre-action authorization)입니다. 세션 콘텐츠의 모든 조각이 어디에서 왔는지(사용자의 요청, 자체 시스템 데이터, 또는 제3자가 영향을 미칠 수 있는 모든 것)를 기록하고, 에이전트가 중대한 작업을 수행하려 할 때 토큰 스트림(token stream) 외부에서 해당 기록을 바탕으로 결정하십시오. 게이트(gate)는 페이로드(payload)를 읽지 않습니다.

이는 우회할 수 있는 표현 방식이 없다는 것을 의미합니다. 모스 부호, 숨겨진 CSS, 위조된 추론(forged reasoning), 완벽한 가짜 송장까지: 아무도 읽지 않기 때문에 모두 무용지물입니다. 당신의 말을 들을 수 없는 보안 요원(bouncer)에게는 감언이설이 통하지 않습니다.

동일한 도구 호출(tool call), 두 번:

first = gate.authorize("send_email", user_id="alice", role="user",
                       parameters={"to": "bob@corp.com"})
print(first.allowed)           # True
...

바이트 단위로 동일한 호출. 출처(Provenance)는 다름. 결과는 다름.

솔직하게 말하는 문제점

이는 유틸리티(Utility) 비용을 발생시키며, 그 양은 전적으로 워크로드(Workload)의 형태에 따라 달라집니다. 저는 실행 전 예측값을 미리 등록해 둔 AgentDojo에서 벤치마크를 수행했기에 손실을 숨길 수 없었습니다. Travel suite의 경우: 공격 성공률 0%, 유틸리티는 정상(Benign) 상한선의 79%까지 회복되었으며, 방어된 에이전트는 공격 상황에서 방어되지 않은 에이전트보다 더 나은 성과를 보였습니다. 차단된 인젝션(Injection)이 에이전트의 탈선을 막아주었기 때문입니다. Slack suite의 경우: 공격의 유무와 상관없이 유틸리티가 4.76%로 바닥을 쳤는데, 이는 모든 정상적인 Slack 작업이 쓰기(Write) 전에 채널을 읽기(Read) 때문이며, 이것이 바로 게이트(Gate)가 막으려는 바로 그 패턴이기 때문입니다. 해당 워크로드에서는 방어 비용이 공격 비용보다 더 많이 듭니다.

만약 에이전트의 정상적인 흐름(Benign flow)이 공격자가 접근 가능한 콘텐츠에 대해 '읽기 후 쓰기(Read-then-write)' 방식이라면, 출처 게이팅(Provenance gating)은 비용이 많이 들며, 이를 배포하기 전에 반드시 알아야 합니다. 이는 벤더의 의견 문제가 아니라, 여러분의 자체 트래픽을 통해 측정 가능한 사실입니다.

향후 전망

CaMeL은 제어 흐름(Control flow)과 데이터(Data)를 분리합니다. FIDES는 정보 흐름(Information-flow) 레이블을 사용합니다. 역할 인지 프로브(Role-perception probes)는 모델 내부 방어(In-model defense)가 왜 계속 실패하는지를 표현(Representation) 수준에서 설명합니다. 서로 다른 어휘를 사용하지만 결론은 하나입니다: 모델은 스스로 보안 경계(Security boundary)가 될 수 없으므로, 모델 외부에서, 행동이 일어나기 전, 출처(Provenance)에 기반하여 강제해야 합니다.

다음 사고는 이미 어딘가에서 진행 중입니다. 그것이 타임라인에 등장할 때, 근본 원인(Root cause)을 확인해 보십시오. 단언컨대, 그것은 똑같은 버그일 것입니다.

저는 출처 기반의 사전 동작 권한 부여 (provenance-based pre-action authorization)를 적대적 벤치마크로 검증한 오픈 소스 참조 구현체인 AgentLock을 구축했습니다. AGPL-3.0 라이선스이며, pip install agentlock으로 설치할 수 있습니다. 손실 (loss) 값을 포함하여 위의 모든 벤치마크 수치는 사전 등록된 AgentDojo 평가에서 가져온 것이며, 허용 후 거부 (allow-then-deny) 전환 실행은 이 Colab에서 실시간으로 확인할 수 있습니다. 사고 타임라인은 여기에 있으며, 출처가 명시된 항목이 포함된 PR (Pull Request)을 환영합니다.