AI 에이전트 스킬 보안: 검사 통과보다 실행 중 권한 확인이 중요한 이유

검사를 통과한 스킬도 그대로 믿으면 안 된다

AI 에이전트 스킬 보안에서 가장 위험한 착각은 “마켓플레이스에 올라왔고 검사도 통과했으니 안전하다”는 생각입니다. 사용자는 코딩 에이전트용 스킬, 업무 자동화 플러그인, 휴대폰 작업 도우미를 설치할 때 겉으로 보이는 설명과 권한 안내를 보고 판단합니다. 문제는 악성 AI 에이전트 스킬이 설치 전에는 평범한 도구처럼 보이다가, 실제 실행될 때 다른 행동을 할 수 있다는 점입니다. 특히 스킬이 압축된 코드, 동적 생성 스크립트, 외부 호출, 숨겨진 명령을 포함한다면 단순한 정적 검사만으로는 의도를 끝까지 확인하기 어렵습니다.

The Hacker News의 2026년 7월 6일 보도는 SkillCloak 방식의 정적 검사 회피와 실행 중 행동 중심 확인 도구인 SkillDetonate 논의를 소개했습니다. 이 보도는 모든 AI 에이전트 스킬이 위험하다는 뜻이 아니라, 설치 전 모습만 보는 보안 모델이 충분하지 않을 수 있다는 신호로 읽어야 합니다. 함께 언급된 Cloak and Detonate 연구는 아직 preprint이므로 연구에서 보고한 우회와 탐지 결과를 확정된 산업 표준처럼 말하면 안 됩니다. 다만 사용자와 제품 팀이 배워야 할 점은 분명합니다. 신뢰는 설치 순간에 끝나는 것이 아니라 실행 순간에도 계속 확인되어야 합니다.

결정 기준은 간단합니다. 스킬이 무엇을 할 수 있다고 주장하는지보다, 실제로 실행될 때 어떤 데이터에 접근하고 어떤 행동을 시도하는지 봐야 합니다. “요약 도구”라고 소개된 스킬이 연락처나 토큰, 파일 경로, 메시지 내용을 읽으려 한다면 설명과 행동이 맞지 않습니다. 정적 검사 결과는 첫 번째 필터일 뿐이고, AI 에이전트 플러그인 위험을 낮추려면 실행 중 권한 확인과 행동 기록이 뒤따라야 합니다.

실행 중 행동을 봐야 보안 판단이 달라진다

실행 중 확인이 중요한 이유는 에이전트 스킬이 사용자의 요청, 외부 입력, 이전 작업 결과에 따라 다른 코드를 호출할 수 있기 때문입니다. 설치 파일만 보면 무해한 문자열 처리처럼 보이지만, 실제 사용 중에는 민감한 환경 변수나 계정 정보, 파일 내용을 다른 작업으로 넘기려 할 수 있습니다. 그래서 좋은 보안 설계는 스킬을 작은 격리 환경에서 실행하고, 네트워크 호출, 파일 접근, 비밀 정보 사용, 다른 도구 호출을 관찰해야 합니다. 이는 단순히 악성 여부를 한 번 판정하는 문제가 아니라, 실행 중 행동이 원래 목적과 맞는지 계속 확인하는 문제입니다.

SkillDetonate처럼 행동 중심 확인을 제안하는 연구 흐름은 이 점에서 의미가 있습니다. 하지만 여기서도 과장하면 안 됩니다. 특정 연구의 우회율이나 탐지율은 실험 조건, 데이터셋, 공격 방식, 구현 세부 사항에 따라 달라질 수 있습니다. 더 현실적인 교훈은 “검사기 하나가 모든 문제를 해결한다”가 아니라 “정적 분석, 격리 실행, 정보 흐름 관찰, 권한 제한, 사용자 확인을 함께 써야 한다”입니다. 특히 스킬이 다른 도구를 연쇄 호출하는 경우에는 어느 단계에서 민감한 정보가 이동했는지 추적할 수 있어야 합니다.

휴대폰 에이전트에서는 이 원칙이 더 사용자 친화적으로 표현되어야 합니다. 보안 로그가 개발자용 텍스트 더미로만 남으면 일반 사용자는 이해할 수 없습니다. 어떤 작업이 시작됐고, 어떤 권한이 요청됐고, 어떤 행동이 보류됐고, 사용자가 무엇을 승인했는지 확인 가능한 기록이 필요합니다. 이런 점에서 AI 에이전트 권한 로그처럼 사용자가 나중에 되돌아볼 수 있는 기록과 동의 지점은 보안 기능이면서 신뢰 기능입니다.

휴대폰에서 스킬 위험이 더 커지는 이유

폰 AI 에이전트 권한이 민감한 이유는 휴대폰이 개인 생활의 중심이기 때문입니다. 메시지, 연락처, 알림, 사진, 파일, 위치, 캘린더, 계정, 결제 앱, 설정이 한 기기에 모여 있습니다. 데스크톱 플러그인이 문서를 잘못 요약하는 것과, 휴대폰 에이전트가 잘못된 사람에게 메시지를 보내거나 알림 내용을 외부로 넘기거나 설정을 바꾸는 것은 위험의 종류가 다릅니다. 폰 에이전트에 실행 중 확인이 필요한 이유는 바로 이 차이입니다. 같은 “도구 호출”이라도 휴대폰에서는 실제 사생활과 계정 행동에 바로 연결될 수 있습니다.

OWASP GenAI 보안 프로젝트가 다루는 prompt injection, 공급망 취약점, 불안전한 플러그인 설계, 과도한 권한 위임, 민감정보 노출은 휴대폰 에이전트에도 그대로 중요한 경고가 됩니다. 예를 들어 사용자가 웹페이지를 요약해 달라고 했는데, 페이지 안에 숨겨진 지시가 에이전트에게 연락처를 읽으라고 유도할 수 있습니다. 또는 편리한 자동화 스킬이 실제로는 알림과 파일 내용을 불필요하게 수집할 수 있습니다. Android 권한은 이런 위험을 줄이는 중요한 장치지만, 사용자 확인과 제품 설계를 대신하지는 않습니다.

민감한 휴대폰 맥락이 어디서 처리되는지도 판단 기준입니다. 일부 작업은 기기 안에서 처리하는 편이 자연스럽고, 무거운 추론이나 외부 정보가 필요한 작업은 클라우드가 도움을 줄 수 있습니다. 하지만 어느 쪽이든 데이터가 어디로 가는지, 어떤 권한이 쓰이는지, 어떤 행동이 실제로 실행되는지 설명되어야 합니다. 클라우드 AI 에이전트와 로컬 AI 에이전트를 비교할 때도 핵심은 절대적인 구호가 아니라 민감한 휴대폰 정보와 행동이 어떤 경계 안에서 처리되는지입니다.

좋은 권한 설계는 작게 허용하고 크게 확인한다

AI 에이전트 플러그인 위험을 줄이는 실용적인 권한 모델은 “처음부터 많이 허용”이 아니라 “필요할 때 작게 허용”입니다. 알림을 요약하는 스킬이 연락처 전체 접근을 요구한다면 의심해야 합니다. 캘린더 확인이 필요한 작업이 파일 저장소 전체 권한을 요청한다면 이유를 설명해야 합니다. Android 권한은 시스템이 관리하는 명시적 기능이며, 권한마다 민감도가 다릅니다. Android Developers의 권한 설명이 보여주듯, 앱과 서비스는 사용자가 허용한 능력 안에서만 움직여야 합니다.

두 번째 원칙은 작업 직전 확인입니다. 스킬을 설치할 때 한 번 허용했다고 해서 모든 미래 행동을 자동 승인한 것으로 보면 안 됩니다. 메시지 전송, 위치 공유, 설정 변경, 파일 삭제, 계정 연결 같은 행동은 실행 직전에 다시 확인되어야 합니다. 세 번째 원칙은 결과 기록입니다. 무엇이 요청됐고, 어떤 권한이 사용됐고, 어떤 행동이 완료됐고, 무엇이 실패했는지 남아야 합니다. 기업 환경에서는 더 넓은 정책, 계정 관리, 보안 모니터링이 필요하며, 이런 큰 틀은 기업 AI 에이전트 보안에서 다루는 통제와 연결됩니다. 소비자 휴대폰에서도 그 축소판인 권한 안내, 확인, 기록은 필요합니다.

네 번째 원칙은 실패를 안전하게 처리하는 것입니다. 권한이 없거나 사용자가 거절하면 에이전트는 우회 경로를 찾으려 하지 말고 이유를 설명해야 합니다. “알림 접근 권한이 없어 요약할 수 없습니다. 설정에서 허용하거나 다른 방식으로 진행하세요”처럼 명확히 말하는 편이 안전합니다. 좋은 폰 AI 에이전트 권한 설계는 사용자를 귀찮게 만드는 것이 아니라, 위험한 행동과 낮은 위험 행동을 구분해 중요한 순간에만 강하게 확인하는 것입니다.

사용자가 확인할 AI 에이전트 스킬 점검표

AI 에이전트 스킬은 안전한가를 판단할 때는 공포심보다 체크리스트가 더 도움이 됩니다. 먼저 출처를 봐야 합니다. 누가 만든 스킬인지, 업데이트 기록이 있는지, 어떤 저장소나 마켓플레이스에서 배포되는지 확인해야 합니다. 둘째, 설명과 권한이 맞는지 봐야 합니다. 요약 도구가 네트워크 전송과 파일 전체 접근을 요구한다면 이유가 필요합니다. 셋째, 설치 전 검사 결과만 믿지 말고 실행 중 어떤 행동을 하는지 알려주는지 확인해야 합니다. 넷째, 사용자가 취소하거나 거절할 수 있는지 봐야 합니다.

휴대폰 에이전트라면 질문을 더 구체적으로 바꿔야 합니다. 이 에이전트가 메시지를 읽을 수 있는가. 연락처를 선택할 수 있는가. 알림 내용을 볼 수 있는가. 설정을 바꿀 수 있는가. 파일을 열거나 공유할 수 있는가. 계정과 결제 앱에 닿을 수 있는가. 각각의 행동에 대해 권한 요청, 실행 직전 확인, 완료 뒤 기록이 있는지 확인해야 합니다. 특히 “한 번 허용하면 앞으로 자동 처리”라는 흐름은 편리해 보이지만 민감한 작업에는 위험할 수 있습니다.

개발자와 제품 팀도 같은 기준을 써야 합니다. 스킬 이름과 설명을 명확히 쓰고, 필요한 권한만 요청하고, 외부 호출을 설명하고, 위험한 행동에는 별도 확인을 넣고, 사용자가 나중에 기록을 볼 수 있게 해야 합니다. 보안 기능은 문서 끝에 적는 면책 문구가 아니라 제품 흐름 안에 들어가야 합니다. 사용자가 이해할 수 없는 권한 요구는 결국 신뢰를 잃게 만듭니다.

FoneClaw 관점에서 보는 안전한 휴대폰 행동

FoneClaw를 이 주제에 연결할 때는 경계를 분명히 해야 합니다. 이 글은 FoneClaw가 SkillCloak에 영향을 받았거나, FoneClaw가 제3자 스킬을 검사한다거나, 인용된 보안 연구나 매체가 FoneClaw를 보증한다는 뜻이 아닙니다. FoneClaw는 독립적인 Android 휴대폰 AI 에이전트로서 지원되는 휴대폰 작업을 사용자가 더 잘 수행하도록 돕는 방향에 있어야 합니다. 핵심은 모든 것을 자동화한다고 말하는 것이 아니라, 지원 범위와 권한 경계를 분명히 보여주는 것입니다.

좋은 FoneClaw 경험은 네 가지 질문에 답해야 합니다. 지금 어떤 작업이 진행 중인가. 어떤 데이터나 앱 권한이 필요한가. 사용자가 승인해야 할 행동은 무엇인가. 완료된 뒤 무엇이 기록되는가. 예를 들어 알림 요약은 곧바로 보여줄 수 있지만, 메시지 전송은 초안 생성과 최종 전송을 분리해야 합니다. 설정 변경은 변경 전 상태와 변경 후 결과를 보여줘야 합니다. 연락처나 파일을 다루는 작업은 최소한의 접근만 요청해야 합니다. 이 흐름이 있어야 악성 AI 에이전트 스킬이나 불필요한 권한 요구가 사용자 눈에 드러납니다.

출처: SkillCloak와 SkillDetonate 논의는 The Hacker News 보도와 Cloak and Detonate preprint를 신호로 참고했습니다. 일반적인 GenAI 보안 위험은 OWASP GenAI 보안 프로젝트의 분류를, Android 권한 원칙은 Android Developers 권한 문서를 기준으로 정리했습니다. 연구 결과와 보도는 FoneClaw와의 제휴나 보증을 의미하지 않으며, 런타임 확인이 모든 위험을 제거한다는 뜻도 아닙니다.