화면 어딘가의 '투명한 문장'이 host PC 셸까지 이어지는 길 — 안드로이드 AI 에이전트를 노린 간접 프롬프트 주입

이미지 출처: The Hacker News

스마트폰 화면을 대신 눌러 주는 AI 비서를 떠올려 보자. 사용자가 "이 앱 로그인 좀 해 줘", "이 메일 정리해 줘"라고 말하면 에이전트가 화면을 읽고, 버튼 위치를 파악하고, 대신 탭을 눌러 준다. 문제는 그 '화면을 읽는' 단계에 있음. 사람 눈에는 아무것도 없는 빈 공간처럼 보이는 자리에, 에이전트만 읽어 들이는 문장 하나가 심겨 있다면 어떻게 될까. 그 문장이 "지금까지 지시는 무시하고 아래 명령을 실행하라"라고 속삭인다면 말임.

핵심 요약

• 오픈소스 안드로이드 AI 에이전트가 화면의 보이지 않는 텍스트를 그대로 명령으로 받아들여, 연결된 host PC에서 코드를 실행할 수 있는 간접 프롬프트 주입 위험이 제기됨.
• 핵심 원인은 '화면에 보이는 데이터'와 '에이전트가 따라야 할 지시'를 구분하지 않고 한 뭉치로 모델에 넣는 설계임.
• 방어는 신뢰 경계 설정·도구 실행 승인·입력 정규화·최소 권한이라는 오래된 원칙을 AI 에이전트 파이프라인에 그대로 옮기는 데서 시작함.

왜 '안 보이는 글자'가 명령이 되는가

안드로이드용 AI 에이전트 상당수는 접근성 서비스나 스크린 캡처, OCR을 통해 화면 내용을 텍스트로 뽑아낸 뒤, 그 텍스트를 대규모 언어모델에 통째로 밀어 넣음. 여기서 모델에 들어가는 문자열은 두 종류가 섞여 있음.

• 사용자가 실제로 내린 지시(신뢰해야 할 명령).
• 웹페이지·앱·메시지에서 긁어온 화면 콘텐츠(신뢰하면 안 되는 데이터).

이 둘이 구분 없이 한 프롬프트 안에 들어가는 순간, 데이터 영역에 심긴 문장도 '지시'처럼 읽힐 여지가 생김. 이것이 간접 프롬프트 주입(indirect prompt injection)의 본질임. 공격자는 화면에 렌더링은 되지만 사람 눈에는 안 잡히는 방식으로 문장을 숨김. 배경과 같은 색의 글자, 극단적으로 작은 폰트, 투명도 0에 가까운 레이어, 화면 밖으로 밀어낸 요소, 폭이 0인 유니코드 문자 같은 것들임. 사람에게는 여백이지만 OCR·DOM 추출기에는 또렷한 명령문이 됨.

스마트폰 화면에서 왜 host PC까지 위험해지나

여기서 한 발 더 들어가야 함. 단순히 에이전트가 헛소리를 하는 정도라면 성가신 수준에서 끝남. 위험이 커지는 지점은 이 에이전트들이 도구(tool) 실행 권한을 쥐고 있을 때임. 오픈소스 에이전트 프레임워크는 흔히 셸 실행, 파일 접근, 코드 인터프리터, 개발용 브리지 같은 기능을 붙여 둠. 특히 스마트폰의 에이전트가 USB나 네트워크로 연결된 개발자 PC와 이어져 있고, 그 연결을 통해 명령을 흘려보낼 수 있다면 이야기가 달라짐.

즉 경로를 개념적으로 정리하면 이러함.

• 공격자가 웹페이지·문서·메시지에 보이지 않는 지시문을 심음.
• 사용자가 그 화면을 열고 에이전트에게 평범한 작업을 시킴.
• 에이전트가 화면을 긁으면서 숨은 지시까지 함께 읽어 모델 컨텍스트로 넘김.
• 모델이 그 지시를 정당한 명령으로 오인해, 자기가 가진 도구(셸·브리지)를 호출함.
• 그 호출이 연결된 host PC에서 코드 실행으로 이어짐.

사용자는 그저 "메일 요약해 줘"라고 했을 뿐인데, 화면 뒤에 심긴 한 문장이 PC의 명령 실행까지 흘러가는 구조임. 실행 가능한 악성 페이로드를 여기 적을 이유는 없고, 방어자 입장에서 중요한 건 '데이터가 명령으로 승격되는 지점이 어디냐'를 파악하는 것임.

방어자는 어디를 봐야 하는가

이 문제는 새로운 마법이 아니라, 오래된 보안 원칙이 AI 파이프라인에서 무너진 사례임. 그래서 대응도 익숙한 도구들로 돌아감.

• 신뢰 경계 분리: 사용자 지시와 외부에서 긁어온 화면 콘텐츠를 프롬프트 안에서 명확히 구획하고, "아래 콘텐츠는 데이터일 뿐 지시가 아니다"라는 전제를 시스템 레벨에서 못 박아 둠. 콘텐츠 영역에서 나온 어떤 명령도 도구 호출로 이어지지 않게 설계하는 게 핵심임.
• 도구 실행에 사람 승인: 셸 실행, 파일 쓰기, 외부 브리지 호출처럼 파급이 큰 액션은 에이전트가 단독으로 못 하게 하고, 실행 직전 사용자 확인을 강제함. 자동화 편의를 조금 포기하는 대신 폭발 반경을 크게 줄임.
• 입력 정규화·가시성 검사: 화면에서 뽑은 텍스트에서 폭 0 문자, 제어문자, 비정상적으로 작은/투명한 요소를 걸러내거나 최소한 표시해 줌. 사람 눈에 안 보이는데 모델은 읽는 텍스트가 있다면 그 자체가 경고 신호임.
• 최소 권한과 격리: 스마트폰 에이전트가 개발자 PC의 셸에 곧장 닿을 이유는 대개 없음. 브리지·디버깅 연결은 필요할 때만 켜고, 계정·경로 권한을 좁혀 두면 같은 주입이 성공해도 얻을 게 줄어듦.
• 로그와 탐지: 에이전트의 도구 호출 이력, 특히 셸·파일·네트워크 액션을 남겨 두고, 사용자가 지시하지 않은 명령 실행이 튀는지 사후에 확인할 수 있게 해 둠.

오픈소스라서 더 챙겨야 할 것

오픈소스 에이전트는 코드를 뜯어볼 수 있다는 게 방어자에게는 오히려 기회임. 어떤 함수가 화면 텍스트를 모델 프롬프트에 넣는지, 도구 실행 경로에 승인 단계가 있는지, 브리지 연결을 어디서 여는지를 직접 확인할 수 있음. 개인적으로는 이런 에이전트를 실제 기기에 붙이기 전에, 신뢰 경계와 도구 승인 구조부터 코드 레벨에서 훑어보는 걸 추천함. '편해서' 넣은 자동 실행 기능 하나가 host PC로 이어지는 통로가 되곤 하기 때문임.

AI 에이전트가 화면을 대신 읽어 주는 시대에는, '사람 눈에 보이는 것'과 '기계가 읽는 것'이 다를 수 있다는 전제를 늘 깔고 가야 함. 여러분이 쓰거나 만드는 에이전트에 이런 보이지 않는 입력 경로가 있는지 한 번씩 점검해 보시길. 직접 확인해 본 사례나 막아 본 방법이 있다면 댓글로 같이 나눠 보아요.