AI 에이전트 스킬·iOS 앱에서 인증정보 줄줄이 샜다

AI 기능이 들어간 소프트웨어에서 API 키와 토큰이 새는 일이 예외적인 사고가 아니라 광범위한 구조적 문제일 수 있다는 연구 결과가 나왔다. 웨이크 포리스트대학교 연구진은 재사용 가능한 AI 에이전트 스킬 17,022개를 조사해 520개에서 총 1,708건의 보안 문제를 확인했다. 별도의 연구에서는 LLM(대규모 언어 모델) 기능을 탑재한 iOS 앱 444개 중 282개가 인증정보 또는 백엔드 접근 수단을 노출했다. 124

문제는 단순히 문자열 하나가 유출되는 데 그치지 않는다. 노출된 키나 토큰이 공격자의 손에 들어가면 비공개 데이터, 에이전트의 권한 있는 기능, 개발자 계정으로 과금되는 유료 모델 호출에 접근할 수 있다.

에이전트 스킬 17,022개에서 확인된 문제

연구진은 SkillsMP에 수집된 아티팩트 170,226개 중 17,022개 스킬을 층화 무작위 방식으로 추출했다. 이후 정적 분석으로 비밀정보를 찾고, 가짜 인증정보를 활용한 샌드박스 실행 테스트를 진행했으며, 스킬이 설명하는 목적과 실제 실행 동작도 대조했다. 34

분석 결과는 다음과 같다.

• 영향을 받은 스킬 520개에서 1,708건의 보안 문제가 발견됐다. 문제 유형은 10가지 인증정보 유출 패턴으로 분류됐다. 416
• 이 가운데 466개 스킬은 높은 권한 없이도 사용할 수 있는 인증정보를 노출했다. 연구진이 보고한 **즉시 악용 가능 비율은 89.6%**다. 14
• 유출 사례의 **76.3%**는 코드만 보거나 자연어 지침만 봐서는 파악하기 어려웠고, 두 요소를 함께 살펴봐야 했다.
• **3.1%**는 실행 가능한 코드 없이 자연어 프롬프트 인젝션만으로 발생했다. 4

따라서 기존의 코드 중심 보안 검토만으로는 충분하지 않다. 겉으로는 정상적인 업무를 수행하는 스킬이라도 자연어 지침이나 보조 스크립트가 실행 과정에서 비밀정보를 밖으로 내보낼 수 있기 때문이다.

디버그 로그가 모델이 읽는 정보가 될 때

특히 주목할 부분은 디버그 로그다. 일부 에이전트 프레임워크는 표준 출력 내용을 모델의 컨텍스트에 전달한다. 이 환경에서는 print나 console.log로 출력한 인증정보가 단순한 자연어 요청만으로도 모델이나 사용자에게 노출될 수 있다.

연구 요약에 따르면 디버그 로깅은 주요 유출 경로였으며, 전체 유출의 73.5%가 표준 출력이 LLM에 노출되는 방식과 관련된 것으로 분석됐다. 4

위험 요소는 코드에 하드코딩된 API 키에만 국한되지 않는다. 스크립트, 환경변수 처리, 로그, 프롬프트 지침, 그리고 코드와 자연어가 결합된 실행 흐름에서도 인증정보가 노출될 수 있다.

악의적인 개발과 부주의한 개발 모두 원인

연구진은 인증정보 유출의 원인을 크게 두 가지로 구분했다.

• 악의적인 개발: 스킬 제작자가 인증정보나 비공개 데이터를 훔치도록 지침 또는 페이로드를 의도적으로 삽입하고, 이를 원격 서버로 전송하도록 만들 수 있다.
• 부주의한 개발: 개발자가 안전한 코딩 관행을 지키지 않아 인증정보나 접근 경로를 실수로 공격자에게 열어두는 경우다. 1

두 유형은 대응 방식도 다르다. 악성 콘텐츠는 탐지와 삭제가 필요하고, 실수로 발생한 노출에는 안전한 비밀정보 관리, 로그 제한, 인증·권한 통제, 배포 전 테스트가 필요하다.

웨이크 포리스트대는 SkillsMP에 문제를 알린 뒤 확인된 악성 스킬이 모두 삭제됐고, 취약한 스킬 대부분도 수정됐다고 밝혔다. 다만 원본 저장소를 정리하는 것만으로는 충분하지 않을 수 있다. 포크된 저장소나 복제본에는 수정 전 인증정보가 계속 남아 있을 수 있기 때문이다. 14

LLM 기반 iOS 앱 10개 중 6개 이상에서 접근 경로 노출

별도로 진행된 iOS 연구에서는 LLM 기능이 포함된 앱 444개를 조사했다. 그 결과 282개, 약 64%가 네트워크 트래픽에서 악용 가능한 LLM 인증정보 또는 백엔드 접근 메커니즘을 노출했다. 25

확인된 주요 노출 방식은 다음과 같다.

• 재사용 가능한 JWT 기반 토큰: 48%
• 인증되지 않은 백엔드 프록시: 33%
• 평문 API 키 전송: 19% 3

이런 취약점은 앱을 평소처럼 사용하는 과정에서도 드러날 수 있다. 공격자가 키를 가로채거나 토큰을 재사용하거나 개방된 프록시를 찾아내면, 개발자의 LLM 계정으로 요청을 보내 유료 추론 서비스를 사용할 수 있다. 그 결과 클라우드 자원 남용이나 예상치 못한 사용료가 발생할 수 있다. 25

계정 한도와 공격 지속 시간에 따라 피해가 심각하거나 사실상 제한 없이 커질 가능성은 있다. 다만 제공된 근거만으로 ‘수십만 달러’와 같은 구체적인 손실액이 실제 발생했다고 단정할 수는 없다. 더 정확한 표현은 노출된 인증정보가 개발자 계정에서 대규모 과금성 LLM 사용을 가능하게 한다는 것이다.

수정 속도도 문제였다. 책임 있는 공개 절차를 통해 취약점이 알려진 지 3개월 뒤에도 영향을 받은 iOS 앱 중 수정된 앱은 28%에 불과했다. 나머지 72%는 후속 조사에서 여전히 악용 가능한 상태로 남아 있었다. 311

‘바이브 코딩’이 빨라질수록 보안 검토는 더 중요해진다

두 연구가 공통으로 보여주는 점은 AI 기능을 추가하거나 재사용 가능한 에이전트 스킬을 설치하는 일이 단순한 편의성 확대가 아니라는 사실이다. 다음과 같은 공격면이 함께 넓어질 수 있다.

• 클라이언트 앱이나 에이전트 컨텍스트에 삽입된 모델 제공업체 API 키
• 파일, 서비스, 비공개 데이터에 접근할 수 있는 권한 있는 도구
• 모델이 읽을 수 있는 컨텍스트로 변하는 로그
• 인증이 충분하지 않은 백엔드 엔드포인트
• 공격자가 반복 사용할 수 있는 토큰
• 개발자 계정에서 발생하는 LLM 사용료

AI가 생성한 코드를 빠르게 조합하는 이른바 ‘바이브 코딩’이 확산될수록 이 문제는 더 커질 수 있다. 개발 속도가 인증, 비밀정보 처리, 권한 부여, 로깅, 의존성 검토, 위협 모델링을 대신할 수는 없기 때문이다.

에이전트 스킬 연구에서는 하드코딩된 인증정보가 발견된 사례의 72%에서 AI 지원 개발의 흔적이 확인됐다. 이는 생성형 도구가 만든 안전하지 않은 패턴이 빠르게 반복·확산될 가능성을 시사하지만, 개별 사례의 원인을 AI 사용만으로 단정한다는 뜻은 아니다. 4

연구가 제시한 ‘보안 설계 우선’ 원칙

연구 결과를 바탕으로 AI 제품을 개발하거나 에이전트 스킬을 배포하는 팀은 다음과 같은 기본 수칙을 마련할 필요가 있다.

1. 장기 사용 API 키를 클라이언트와 모델 컨텍스트에서 분리한다. 민감한 모델 호출은 인증된 서버를 거치도록 구성한다.
2. 짧은 수명의 최소 권한 인증정보를 사용한다. 토큰을 가진 것만으로 권한을 인정하지 말고, 토큰의 유효성과 범위를 검증한다.
3. 로그와 표준 출력에서 비밀정보를 마스킹한다. 에이전트 컨텍스트로 전달되는 모든 정보는 모델이나 사용자가 복구할 수 있다고 가정해야 한다.
4. 코드·설정·프롬프트·의존성을 함께 검사한다. 에이전트 스킬 연구 결과처럼 자연어 지침과 실행 코드는 공동 검토가 필요하다.
5. 네트워크 트래픽과 백엔드 권한을 테스트한다. 가로챈 요청을 재사용하거나 인증 없는 프록시를 통해 우회할 수 없는지 확인한다.
6. 노출된 인증정보를 즉시 교체하고 포크와 복제본도 확인한다. 원본 저장소에서 비밀정보를 삭제해도 배포된 모든 사본이 정리되는 것은 아니다.
7. 배포 전 플랫폼 차원의 심사를 도입한다. 마켓플레이스 검수, 개발자 지침, 책임 있는 취약점 공개, 자동화된 검사로 개인의 주의만으로는 부족한 부분을 보완해야 한다. 34

핵심은 분명하다. AI 보안은 제품 출시 뒤 덧붙이는 기능이 아니다. 인증정보, 에이전트 권한, 모델 컨텍스트, 과금 통제는 기획과 설계 단계부터 제품 보안의 핵심 요소로 다뤄야 한다.