AI 에이전트의 스킬(Skill)은 반복 업무에 필요한 지침과 참고 자료, 때로는 실행 스크립트를 묶은 작업 패키지다. 회사에서 안전하게 사용하려면 도입 전에 내용과 출처를 검토하고, 실행할 때 접근 가능한 데이터와 도구를 제한하며, 업데이트와 폐기까지 관리해야 한다. 악성 스킬 검사는 이 과정의 중요한 한 단계다.
예를 들어 ‘회의록 정리 스킬’을 설치했다고 해 보자. 지정한 회의록을 읽고 요약 파일을 만드는 데 필요한 권한은 비교적 작다. 그런데 이 스킬이 모든 업무 폴더를 검색하고 외부 서버로 진단 자료를 전송하도록 요구한다면, 설명된 목적과 실제 행동 사이에 차이가 생긴다. 이 차이를 도입 심사에서 찾고, 놓친 요청은 실행 환경에서 막는 구조가 필요하다.
이 글은 2026년 10월 1일 확인한 공식 문서를 토대로 스킬의 공격 경로, 검사 도구의 역할과 한계, 기업이 적용할 운영 기준을 정리한다. 아래 운영 모델과 예시는 조직에 맞게 조정할 수 있는 제안이며, 특정 제품의 기본 보안 설정이나 탐지 성능을 측정한 결과는 아니다.
1. 스킬은 무엇을 가져오는가: 지침, 코드, 의존성
Agent Skills 규격에서 중심 파일은 SKILL.md다. 이름과 설명 같은 메타데이터, 작업 절차를 적은 본문이 들어간다. 여기에 scripts, references, assets 같은 보조 디렉터리가 붙을 수 있다. 따라서 검사 범위는 마크다운 문서 한 장보다 넓다. Agent Skills 규격
스킬은 업무 절차를 알려 주고, 에이전트는 자신에게 연결된 도구로 그 절차를 수행한다. MCP는 외부 도구나 자원과 연결하는 방식이고, 플러그인은 여러 기능을 배포하는 묶음이 될 수 있다. 스킬 하나가 MCP 도구를 사용하거나 플러그인 안에 포함될 수 있어, 실제 도입 심사에서는 연결된 구성 요소까지 살펴야 한다.
스킬이 곧바로 운영체제 관리자 권한을 갖는 것은 아니다. 위험의 크기는 에이전트가 읽을 수 있는 파일, 사용할 수 있는 자격증명, 호출 가능한 도구에 따라 달라진다. 같은 스킬도 공개 자료만 읽는 환경과 운영 DB를 변경할 수 있는 환경에서 결과가 크게 다르다.
또한 스킬 전체가 처음부터 모델에 보인다고 가정하면 검토를 놓치기 쉽다. 메타데이터, 활성화된 지침, 필요할 때 읽는 보조 자료로 나누어 로딩하는 방식이 사용된다. 첫 파일이 평범하더라도 뒤에서 불러오는 문서나 스크립트가 행동을 바꿀 수 있다. 프로젝트 저장소에 포함된 스킬의 신뢰를 별도로 확인하라는 권고도 공식 구현 안내에 있다. Agent Skills 구현 안내
회사에서 관리해야 할 대상은 결국 ‘어느 출처의 어떤 내용이, 어떤 에이전트 권한으로 실행되는가’다.
2. 악성 스킬을 의심할 수 있는 징후
악성 지시는 반드시 실행 파일에만 숨어 있지 않다. 자연어로 작업 목적을 바꾸거나, 참고 자료 속 문장을 상위 지시처럼 따르게 유도할 수도 있다. 외부 콘텐츠가 모델의 행동을 바꾸도록 만드는 문제는 프롬프트 인젝션과 연결된다. OWASP Prompt Injection
다음 표는 회의록 정리 스킬을 심사한다고 가정한 예시다. 항목 하나만으로 악성이라고 단정하기보다, 업무 목적과 필요한 권한이 일치하는지 판단하는 데 사용한다.
외부 통신이나 셸 실행 자체가 악성의 증거는 아니다. 웹 조사 스킬은 네트워크가 필요하고, 빌드 스킬은 명령을 실행해야 한다. 반대로 코드가 없는 스킬도 이미 연결된 전송 도구를 잘못 사용하도록 지시할 수 있다. 목적, 데이터, 행동, 권한을 함께 검토해야 한다.
그림 1. 검토해야 할 두 경로: 모델에 들어가는 지시와 실제 실행되는 코드. Agent Skills 규격, OWASP Prompt Injection 공식 문서를 바탕으로 재구성한 개념도.
3. 설치 전에 격리하고, 전체 묶음을 검사한다
기업의 첫 통제 지점은 직원이 스킬을 선택하는 순간과 에이전트가 스킬을 발견하는 순간 사이에 두는 것이 좋다. 검토 전 패키지는 에이전트가 자동으로 검색하는 스킬 디렉터리 밖에 보관한다. 검사하려고 내려받은 파일이 곧바로 업무 에이전트의 지침으로 로딩되는 일을 피하기 위해서다.
도입 요청에는 최소한 출처 URL, 작성 주체, 사용할 업무, 입력 데이터 등급, 필요한 파일·도구·네트워크 권한, 책임자를 적는다. 공개 저장소의 인기도나 ‘공식’ 표시는 출처를 판단하는 단서지만, 현재 내려받은 내용의 적합성까지 증명하지는 않는다.
검사 대상을 확정할 때는 저장소 이름만 기록하지 않는다. 정확한 커밋과 내려받은 전체 패키지의 해시를 보존한다. 해시는 파일 내용으로 계산한 지문이다. 이후 배포된 파일이 검토한 파일과 같은지 확인하는 데 쓴다. 서명과 출처 증명도 무결성과 공급 경로 판단에 도움이 되지만, 정상 제작자가 넣은 위험한 기능까지 자동으로 제거해 주지는 않는다. 공급망의 여러 지점을 구분하는 관점은 SLSA 위협 모델을 참고할 수 있다.
검토 목록에는 SKILL.md뿐 아니라 연결된 문서, 스크립트, 설정 파일, 잠금 파일, 설치 시 실행되는 훅을 포함한다. 심볼릭 링크가 가리키는 외부 파일이나 서브모듈도 실제 내용을 확인한다. 실행 중 다른 주소에서 지침이나 코드를 가져온다면, 그 외부 콘텐츠가 승인 범위를 벗어나지 않도록 별도로 관리해야 한다.
원격 설치 명령을 먼저 실행한 뒤 결과를 검사하면, 설치 과정에서 이미 코드가 실행되었을 수 있다. 격리된 수집 환경에서 자료를 확보하고, 설치 단계의 행동도 분석 대상으로 삼는 순서가 적절하다.
그림 2. 기업용 도입·운영 절차 제안. Agent Skills 구현 안내, Cisco 검사 권장 설정, SLSA 위협 모델 공식 문서를 바탕으로 재구성. 보류·거절·예외 기준은 조직이 정한다.
4. 악성 스킬 검사는 여러 방법을 겹쳐 사용한다
형식 검사와 보안 검사는 서로 다른 질문에 답한다. 예를 들어 규격 검증기는 필수 메타데이터나 이름 규칙을 확인할 수 있지만, ‘요약 후 원문을 외부로 보내라’는 지시의 업무상 정당성까지 보장하지 않는다. Agent Skills의 참조 검증 도구도 규격 검증 용도로 이해해야 한다. Agent Skills 검증 안내
실무에서는 다음처럼 검사를 나누면 누락된 영역이 보인다.
Cisco Skill Scanner: 스킬 전용 분석의 출발점
Cisco의 Skill Scanner는 규칙 기반 검사, 코드·데이터 흐름 분석, 선택적 LLM 분석 등을 결합한다. 프롬프트 인젝션, 정보 유출, 난독화, 의존성 관련 위험 등을 찾는 데 사용할 수 있다. 다만 --use-behavioral의 데이터 흐름 분석을 실제로 스킬을 실행하는 샌드박스 시험과 혼동하면 안 된다. 공식 문서도 탐지 결과가 없다는 사실이 보안 인증은 아니라고 명시한다. Cisco Skill Scanner, 공식 저장소
운영에서는 탐지 심각도만큼 검사 완료 여부가 중요하다. 공식 권장 설정 문서에는 LLM 분석 실패가 LLM_ANALYSIS_FAILED라는 INFO 항목으로 보고되어 게이트를 통과할 수 있다는 설명이 있다. 따라서 회사의 승인 절차는 ‘높은 위험 발견 없음’과 ‘필수 분석이 전부 성공함’을 별도로 확인해야 한다. 규칙만 사용하는 검사와 외부 모델·서비스를 연결하는 검사도 구분한다. Cisco 검사 권장 설정
Snyk Agent Scan: 연결된 에이전트 구성 요소까지 확인
Snyk Agent Scan은 스킬과 MCP 서버 등 에이전트 구성 요소를 살펴보는 도구다. 스킬만의 내용 검사와 연결 환경의 조사 범위를 구분해서 사용할 수 있다. 특히 공식 README는 MCP 설정 검사 과정에서 서버 명령을 실행하거나 원격 주소에 접속할 수 있다고 설명한다. 신뢰하지 않는 MCP 설정은 검사 자체도 격리 환경에서 수행해야 한다. CLI 출력 구조가 실험적이라는 안내도 있으므로, 특정 필드에 의존하는 사내 차단 로직은 버전을 고정하고 변경을 검증해야 한다. Snyk Agent Scan 공식 저장소
검사 도구를 고를 때는 탐지 기능과 함께 데이터 처리 방식을 확인한다. 회사의 스킬에는 내부 주소, 업무 규칙, 비공개 코드가 들어갈 수 있다. 온라인 업로드나 외부 LLM 분석을 사용한다면 무엇이 어느 서비스로 전송되는지, 보관·학습 이용 조건은 무엇인지 확인한 뒤 허용해야 한다. ‘로컬에서 실행하는 CLI’라는 이유만으로 모든 처리가 로컬에서 끝난다고 가정하지 않는다.
도구의 탐지율을 이 글에서 순위로 비교하지는 않는다. 동일한 시험 자료와 버전으로 측정하지 않았기 때문이다. 기업은 정상 업무 스킬, 금지 행동을 요구하는 시험 스킬, 분석 실패 사례를 함께 모아 자체 회귀 시험을 만드는 편이 유용하다.
5. 검토자가 확인할 것은 ‘왜 이 권한이 필요한가’다
회의록 정리 스킬을 검토한다면, 읽을 폴더와 만들 파일을 먼저 정한다. 외부 업로드가 필요 없다면 전송 기능을 제외하고, 자료 취득에 별도 계정이 필요하다면 필요한 문서만 읽는 연결을 제공한다. 이처럼 업무를 구체화하면 과도한 권한을 발견하기 쉽다.
자연어 분석을 LLM에 맡길 때도 검사 대상의 지시는 신뢰하지 않는 입력으로 취급한다. 검토 모델에는 실제 업무용 자격증명과 실행 도구를 주지 않고, ‘문제없음’이라는 결론보다 의심 문장·파일 위치·예상 행동·필요한 권한을 근거로 제출하게 한다. 모델의 판정은 검토 자료로 사용하고, 고위험 예외 승인까지 같은 모델에 맡기는 구조는 피한다.
오탐을 처리할 때는 검사 규칙을 통째로 끄기보다 해당 버전의 특정 동작이 필요한 이유를 기록한다. 예외에는 적용 범위, 책임자, 만료일을 둔다. 업무용으로 승인한 전송 주소가 바뀌거나 데이터 등급이 달라졌다면 기존 예외를 재사용하지 않는다.
검토 기록은 다음 질문에 답할 수 있으면 실용적이다.
- 어떤 업무에 사용할 스킬이며, 승인한 정확한 패키지는 무엇인가?
- 어떤 데이터를 읽고, 무엇을 쓰거나 외부로 보낼 수 있는가?
- 발견된 경고를 왜 수용하거나 차단했는가?
- 실제 실행 환경이 승인된 권한 범위를 강제하는가?
- 문제가 생기면 누가 사용을 중단하고 영향을 조사하는가?
6. 실행 중에는 모델 밖에서 권한을 제한한다
사전 검토를 통과한 스킬에도 실행 시 통제가 필요하다. 정상 스킬이 읽은 웹페이지나 문서에 악성 지시가 들어 있을 수 있고, 승인 후 의존성이나 외부 자료가 달라질 수도 있다. OWASP는 기능과 권한을 최소화하고, 고위험 행동은 별도로 승인하며, 하위 시스템에서 권한을 검증하도록 권고한다. OWASP Excessive Agency
기업용 설계에서는 다음 네 경계를 나누어 점검할 수 있다.
파일 경계: 작업에 필요한 입력만 읽기 전용으로 제공하고 결과물을 쓸 디렉터리를 분리한다. 개인 홈 전체나 다른 프로젝트까지 접근하게 만들지 않는다. 실행 환경에 호스트 제어용 소켓이나 운영 자격증명을 함께 노출하면 격리의 의미가 약해진다.
네트워크 경계: 기본적으로 외부 연결을 제한하고 업무에 필요한 목적지만 허용한다. 도메인이 허용되어 있어도 그 서비스의 임의 저장소나 다른 조직 계정으로 업로드할 수 있다면 유출 경로가 남는다. 가능하면 전용 API 중계 계층에서 대상 계정·자원·요청 종류까지 검증한다. LLM 제공자에게 전달되는 프롬프트도 데이터 전송 경계에 포함한다.
도구와 자격증명 경계: 범용 셸이나 임의 URL 호출보다 용도가 좁은 도구를 제공한다. 비밀값을 프롬프트에 넣기보다, 중계 서비스가 보관한 짧은 수명의 제한된 자격증명으로 승인된 작업만 실행하도록 설계한다. 도구 서버는 호출한 사용자에게 실제 권한이 있는지도 확인해야 한다.
외부 행동 경계: 메일 전송, 운영 배포, 대량 삭제 같은 작업은 실행 직전의 대상과 내용을 확인한다. 사람이 승인했다면 그 승인과 실제 실행 인수를 묶고, 내용이 바뀌면 다시 검사한다. 최종 답변만 차단해도 이미 실행된 전송이나 변경은 되돌아오지 않는다.
그림 3. 회의록 처리 업무를 위한 실행 경계 제안. OWASP Excessive Agency, Claude Code 샌드박스 문서 공식 문서를 바탕으로 재구성. 특정 제품의 기본 구성을 나타내지 않는다.
샌드박스를 켰다는 사실만으로 모든 도구가 제한된다고 결론 내리지 않는다. 어떤 프로세스·파일 도구·브라우저·MCP 서버가 그 경계 안에 있는지 각각 확인해야 한다. 예를 들어 Claude Code의 샌드박스 문서는 명령 실행의 파일·네트워크 격리, 격리 밖 재시도, 사용할 수 없을 때의 처리 방식을 구분한다. 조직이 격리를 필수로 요구한다면 실패 시 일반 실행으로 넘어가는 경로까지 점검해야 한다. Claude Code 샌드박스
이름만 보고 믿기 쉬운 설정 두 가지
allowed-tools를 모든 에이전트에서 동일한 ‘도구 차단 목록의 반대’로 해석하면 곤란하다. Agent Skills 규격에서는 실험적 필드로 설명하고 구현에 따라 지원이 다를 수 있다고 안내한다. Agent Skills 규격
Claude Code의 현재 문서는 allowed-tools를 해당 스킬 호출 턴에서 추가 승인 없이 사용할 도구의 지정으로 설명한다. 목록 밖 도구를 모두 제거하는 기능이 아니며, 다른 도구에는 별도의 권한 설정이 적용된다. disable-model-invocation: true는 모델의 자동 스킬 호출을 제한하는 설정이다. 자동 호출 제어와 파일·네트워크 격리는 서로 다른 기능이다. Claude Code 스킬 설정
따라서 중요한 제한은 검토 대상인 스킬이 스스로 선언하게 두기보다, 조직이 관리하는 실행 정책과 도구 서버에서 강제해야 한다. 제품과 버전별로 실제 동작을 확인하고, 허용되지 않은 작업이 거부되는 시험도 남긴다.
7. 승인된 스킬도 업데이트와 폐기 절차가 필요하다
사내 저장소는 승인된 패키지를 배포하는 출발점이 될 수 있다. 다만 저장소를 만드는 것으로 끝내면 사용자의 개인 스킬, 프로젝트에 포함된 스킬, 다른 플러그인의 스킬이 함께 로딩될 수 있다. 조직에서 허용한 공급 경로와 실제 로딩된 출처를 비교해야 한다. 같은 이름의 스킬이 여러 곳에 있을 때 선택되는 대상도 클라이언트별로 확인한다.
다음은 사내 승인 기록의 예시다. 제품의 공통 설정 형식이 아니라 회사가 관리할 항목을 보여 준다.
업데이트 심사는 SKILL.md의 변경분에만 한정하지 않는다. 스크립트, 의존성, 연결 서버, 동적 참조 자료가 바뀌면 행동이 달라질 수 있다. 승인한 파일을 배포 직전과 로딩 시점에 확인하고, 가능한 구성은 변경할 수 없는 버전으로 고정한다. 에이전트나 정책 엔진의 업데이트가 권한 해석에 영향을 주는지도 함께 시험한다.
운영 기록에는 스킬 식별자와 해시, 호출한 사용자·업무, 사용한 도구, 접근 대상, 허용·거부 결과를 연결한다. 원문과 비밀값을 무제한 수집할 필요는 없다. 보존 범위와 접근자를 제한하고 민감한 값은 마스킹해야 한다.
문제 스킬이 발견되면 새 설치 차단과 함께 실행 중인 작업, 이미 로딩된 지침, 캐시와 배포 사본을 확인한다. 필요한 경우 작업을 중단하고 관련 자격증명 노출 여부를 조사해 회수·교체한다. 스킬 파일을 삭제했다는 사실과 실행 중인 작업이 끝났다는 사실은 별도로 확인해야 한다.
8. 회사에서 시작할 수 있는 최소 운영 기준
처음부터 모든 스킬을 같은 절차로 심사하면 운영 부담이 커질 수 있다. 공개 자료의 형식을 정리하는 작업, 비공개 문서를 읽는 작업, 운영 시스템을 변경하는 작업을 구분하고 데이터와 행동의 영향에 맞춰 검토 수준을 높이는 방식이 현실적이다.
첫 도입에서는 다음 여섯 가지를 기준으로 삼을 수 있다.
- 승인된 출처와 버전만 배포한다. 검토 전 자료를 업무 에이전트가 자동으로 읽지 않게 한다.
- 지침과 코드를 함께 검사한다. 보조 문서·의존성·설치 절차까지 포함하고, 분석 실패는 미검토 상태로 남긴다.
- 업무 목적에 필요한 권한만 준다. 파일, 네트워크, 도구, 데이터 등급을 명시한다.
- 격리 시험으로 제한을 확인한다. 기능 성공뿐 아니라 금지된 읽기·전송·변경이 실제로 거부되는지 확인한다.
- 외부 영향이 큰 행동은 별도로 검증한다. 사람의 승인과 도구 서버의 권한 검사를 연결한다.
- 변경과 회수를 운영 절차에 넣는다. 새 버전 재심사, 실행 이력, 신속한 사용 중단이 가능해야 한다.
핵심은 ‘악성 스킬을 완벽하게 골라내는 검사기’를 찾는 데서 멈추지 않는 것이다. 검사 결과는 도입 판단의 근거로 활용하고, 실행 환경은 잘못된 행동의 범위를 줄이며, 운영 절차는 변화와 사고에 대응하도록 맡긴다.
기업에서 스킬을 안전하게 활용한다는 것은 검토한 패키지를 필요한 업무에만 연결하고, 허용한 데이터와 행동 범위가 실제 실행에서도 유지되는지 확인하는 일이다. 이 기준이 갖춰지면 스킬의 재사용성과 자동화 효과를 조직의 보안 요구 안에서 활용할 수 있다.
'일반IT > IT보안' 카테고리의 다른 글
| ARTEX는 무엇을 자동화할까? 금융권 침해 보도와 AI 보안 도구 도입의 경계 (0) | 2026.10.05 |
|---|---|
| Presidio 한국어 탐지, 회귀 테스트로 검증하기 (0) | 2026.10.04 |
| Presidio와 NeMo Guardrails, AI DLP라고 불러도 될까? (0) | 2026.09.15 |
| 증거에서 대응까지: LLM 보안 사고 조사 (0) | 2026.09.03 |
| 소프트웨어 공급망 보안 입문: 무엇을 공부하고 어떤 도구로 검증할까 (0) | 2026.09.02 |
