For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/ko/articles/friendly-fire-rogue-agent-ai-coding-security.md.
아군 오사와 불량 에이전트는 AI 에이전트 보안이 단순히 모델 정렬 문제가 아님을 보여줍니다. 실질적인 경계는 런타임, 즉 파일, 명령어, 네트워크 접근, 비밀 정보, 실행 환경 및 감사 가능성에 있습니다. AI 코딩 에이전트를 사용하는 팀은 신뢰할 ...
AI 코딩 에이전트는 더 이상 단순한 자동완성 도구가 아닙니다. 이들은 저장소를 읽고, 이슈를 검사하고, 파일을 편집하고, 스크립트를 실행하고, 도구를 호출하고, 네트워크 연결을 열고, 때로는 프로덕션에 바로 적용 가능한 변경사항을 만듭니다. 이는 유용하지만, 동시에 보안 모델을 변화시킵니다.
핵심 질문은 더 이상 모델이 유해한 프롬프트를 거부할 수 있는지 여부만이 아닙니다. 더 어려운 질문은 에이전트가 런타임에 무엇을 할 수 있는지입니다: 어떤 파일을 읽을 수 있고, 어떤 스크립트를 실행할 수 있으며, 인터넷에 접근할 수 있는지, 비밀정보가 마운트되어 있는지, 모든 행동이 유용한 감사 기록을 남기는지 등입니다.
이 글은 우군 사격과 불량 에이전트에 관한 원래 논의를 실제 개발 워크플로우에서 AI 코딩 에이전트를 사용하는 팀들을 위한 실용적인 보안 가이드로 재구성합니다.
우군 사격과 불량 에이전트 뒤에 있는 공통 신호는 간단합니다: 신뢰할 수 없는 컨텍스트가 에이전트가 이를 권위로 취급할 때 위험해질 수 있습니다.
저장소의 README, 의존성 스크립트, 고객이 업로드한 아카이브, 챗봇 코드 블록은 평범한 입력처럼 보일 수 있습니다. 하지만 에이전트가 해당 입력을 읽고 파일시스템, 셸, 네트워크 또는 자격증명 접근 권한으로 그 입력에 대해 행동한다면, 해당 입력은 사실상 신뢰 경계를 넘은 것입니다.
프로덕션 환경에서는 에이전트가 도구 호출 허용 여부에 대한 최종 권위자가 되어서는 안 됩니다. 에이전트는 행동을 제안할 수 있습니다. 권한 레이어, 샌드박스, 정책 엔진, 인간 검토자가 해당 행동이 실제로 허용되는지 결정해야 합니다.
우군 사격은 현실적인 보안 워크플로우에 초점을 맞춥니다: AI 코딩 에이전트에게 타사 또는 오픈소스 저장소의 취약점을 검토하도록 요청하는 것입니다. 이 워크플로우가 매력적인 이유는 방어적으로 보이기 때문입니다. 팀은 에이전트에게 어떤 것을 공격하도록 요청하는 것이 아닙니다. 에이전트에게 코드를 검사하고 수정 사항을 제안하도록 요청하는 것입니다.
문제는 보안 검토가 신뢰할 수 없는 자료를 읽는 것을 필요로 한다는 점입니다. 저장소에는 단순한 데이터가 아닌 문서, 스크립트, 빌드 파일, 바이너리 아티팩트, 주석이 포함될 수 있습니다. 또한 에이전트를 대상으로 한 지시사항이 포함될 수도 있습니다.
중요한 교훈은 AI 보안 도구에 대해 패닉에 빠지지 않는 것입니다. 증거와 권한을 분리하는 것입니다.
README는 프로젝트가 일반적으로 어떻게 테스트되는지 설명할 수 있습니다. 에이전트가 자동으로 해당 테스트를 실행하도록 권한을 부여해서는 안 됩니다. 의존성 스크립트는 저장소의 일부일 수 있습니다. 자동으로 신뢰되어서는 안 됩니다. 타사 패키지는 일반적인 보안 검사처럼 보이는 명령을 포함할 수 있습니다. 에이전트는 이를 읽을 수 있지만, 실행은 더 높은 수준의 신뢰가 필요합니다.
위험한 패턴은 다음과 같습니다:
./security.sh
명령 자체는 무해해 보일 수 있지만, 중요한 질문은 이것이 어디서 왔는지입니다. 사용자가 명시적으로 요청한 것입니까? 모델이 제안한 것입니까? 타사 README에서 복사된 것입니까? 이슈 댓글이나 의존성 스크립트에 포함된 것입니까? 이러한 출처들은 동일한 수준의 신뢰를 가져서는 안 됩니다.
불량 에이전트는 다른 종류의 위험을 보여줍니다. 로컬 코딩 에이전트가 저장소를 검토하는 대신, 문제는 클라우드 AI
대화형 에이전트가 관리형 실행 환경 내에서 코드 블록을 실행할 수 있는 플랫폼입니다.
제품 및 보안 팀에게 유용한 교훈은 챗봇이 단순히 프롬프트와 응답만으로 이루어지지 않는다는 점입니다. 챗봇에는 런타임 환경, 서비스 계정, 네트워크 이그레스, 세션 변수, 로그, 공유 인프라, 배포 권한이 포함될 수 있습니다.
대화형 에이전트가 코드를 실행하거나 고객 데이터에 접근할 수 있는 경우, 프로덕션 애플리케이션처럼 관리되어야 합니다. 즉, 최소 권한, 환경 분리, 감사 로깅, 변경 검토, 명확한 소유권이 필요합니다. 이를 단순히 "대화 구성"으로만 취급하는 것은 실제 위험에 비해 너무 미약합니다.
Friendly Fire와 Rogue Agent는 서로 다른 사고이지만, 동일한 실패 패턴을 가리킵니다: 신뢰할 수 없는 컨텍스트가 운영 권한을 부여받는 것입니다.
Friendly Fire 시나리오에서는 신뢰할 수 없는 저장소 콘텐츠가 에이전트에 영향을 주어 명령을 실행하게 할 수 있습니다. Rogue Agent 시나리오에서는 에이전트 플랫폼 내부의 코드 실행이 공유 런타임 동작과 민감한 대화 데이터에 영향을 미칠 수 있습니다. MCP 관련 연구에서도 유사한 우려가 제기되었습니다: 사용자에게 표시되는 승인 화면과 모델이 실제로 수신하는 메타데이터가 항상 동일한 신뢰 수준을 나타내지 않을 수 있습니다.
이것이 보안 설계가 신중한 모델에만 의존할 수 없는 이유입니다. 모델은 위험에 대해 추론하는 데 도움이 될 수 있지만, 신뢰할 수 없는 명령을 읽은 직후 자신의 위험한 도구 호출을 승인해서는 안 됩니다.
보다 안전한 아키텍처는 세 가지 계층을 분리합니다:
타사 저장소, 알 수 없는 이슈, 의존성 감사, 고객 아카이브, 다운로드된 패키지는 일회용 환경에서 열어야 합니다. 컨테이너나 가상 머신이 좋은 기본값입니다.
격리된 환경은 사용자의 홈 디렉터리, 클라우드 자격 증명, 패키지 레지스트리 토큰, SSH 키, 브라우저 프로필, 프로덕션 구성을 마운트하지 않아야 합니다. 소스 코드는 읽기 전용으로 시작할 수 있습니다. 쓰기 권한은 에이전트가 명확한 계획을 수립하고 사용자가 범위를 승인한 경우에만 부여되어야 합니다.
좋은 기본값은 다음과 같습니다:
읽기, 편집, 실행이 하나의 자동 흐름으로 합쳐지지 않도록 분리하세요.
읽기 단계: 에이전트가 파일을 검사하고, 위험을 식별하며, 계획을 수립할 수 있습니다.
패치 단계: 에이전트가 diff나 패치를 생성할 수 있으며, 이상적으로는 신뢰할 수 없는 스크립트를 실행하지 않아야 합니다.
실행 단계: 에이전트는 제한된 허용 목록 내에서 승인된 명령만 실행할 수 있으며, 타임아웃과 리소스 제한이 적용됩니다.
제안된 명령이 README, 이슈 댓글, 의존성 스크립트 또는 외부 문서에서 비롯된 경우, 승인 UI에는 해당 출처가 표시되어야 합니다.
명확히. 저장소가 제안한 명령은 사용자가 명시적으로 요청한 명령과 동일하지 않습니다.
아이디어를 한 문장으로 입력하면 We0 AI가 쇼케이스 사이트, 페이지, CMS를 생성하고 출시 후 고객과 트래픽 확보를 돕습니다.
무료 등록을 위한 하나의 완전한 프로젝트 생성
하나의 완전한 생성 흐름을 시도하고 첫 번째 프로젝트 초안을 빠르게 보는 데 가장 적합합니다.
AI 에이전트는 설명 및 분류에 유용하지만, 가능한 경우 결정적 도구를 먼저 실행해야 합니다.
예를 들어:
에이전트는 결과를 요약하고 우선순위를 지정할 수 있습니다. 기본 스캐너를 대체해서는 안 됩니다.
신뢰할 수 없는 저장소의 경우, 가장 안전한 기본값은 먼저 검사하고 실행하지 않는 것입니다.
유용한 규칙은 간단합니다. 입력을 덜 신뢰할수록 에이전트에 부여하는 권한을 줄여야 합니다.
단일 "안전 모드" 토글만으로는 충분하지 않습니다. 실제 제품에는 기능 수준의 권한이 필요합니다.
더 나은 권한 모델은 각 기능을 별도로 처리합니다:
| 기능 | 권장 기본값 | 중요한 이유 |
|---|---|---|
| 파일 읽기 | 범위가 지정된 작업 공간에서 허용 | 에이전트는 컨텍스트가 필요하지만, 전체 시스템은 아닙니다. |
| 패치 작성 | 계획 검토 후 허용 | 코드 작성은 코드 실행보다 안전합니다. |
| 테스트 실행 | 허용 목록만 | 테스트 명령은 임의 스크립트를 호출할 수 있습니다. |
| 종속성 설치 | 승인 필요 | 패키지 수명 주기 스크립트는 주요 위험 표면입니다. |
| 네트워크 액세스 | 신뢰할 수 없는 작업의 경우 기본적으로 거부 | 데이터 유출 및 원격 페이로드 가져오기를 방지합니다. |
| 비밀 액세스 | 기본적으로 거부 | 비밀은 신뢰할 수 없는 작업에 표시되어서는 안 됩니다. |
| 풀 리퀘스트 생성 | 승인 필요 | PR은 신뢰할 수 있는 저장소 및 CI 시스템에 영향을 미칠 수 있습니다. |
| 배포 | 수동 승인 필요 | 배포는 프로덕션에 영향을 미치는 작업입니다. |
승인 화면에는 명령뿐만 아니라 그 출처도 표시되어야 합니다. 사용자 의도, 모델 추론, README 지침, CI 구성 및 외부 이슈 댓글에서 비롯된 명령은 다르게 표시되어야 합니다.
NxCode 사용자는 종종 에이전트가 실제 개발 작업을 처리하기를 원합니다: 코드 읽기, 파일 업데이트, 검사 실행, 배포 결과물 생성 및 문서 작성. 이러한 기능은 가치 있지만, 권한 경계가 명확할 때만 유용합니다.
실용적인 접근 방식은 작업을 세 그룹으로 분류하는 것입니다:
저장소
예를 들어 서식 변경, 문서 업데이트, 작은 UI 변경, 테스트 제안 등이 있습니다. 저장소와 환경이 신뢰할 수 있는 경우 이러한 작업은 더 높은 수준의 자동화를 사용할 수 있습니다.
신뢰할 수 없는 입력에 대한 조사
예를 들어 알 수 없는 저장소, 의존성 업데이트, 외부 이슈 보고서, 고객이 업로드한 아카이브 등이 있습니다. 이러한 작업은 일회용 제한된 환경에서 실행되어야 합니다.
운영에 영향을 미치는 작업
예를 들어 배포, 데이터베이스 마이그레이션, 비밀 키 교체, 인프라 변경, CI/CD 권한 업데이트 등이 있습니다. 이러한 작업은 사람의 승인과 강력한 증거 로그가 필요합니다.
이 설계는 AI 코딩 에이전트의 속도 이점을 없애지 않습니다. 위험이 낮은 곳에서는 에이전트를 빠르게 유지하고, 피해 범위가 큰 곳에서는 더 많은 구조를 강제합니다.
Friendly Fire는 방어 작업에 사용되는 AI 에이전트가 신뢰할 수 없는 코드베이스 콘텐츠의 영향을 받는 위험 패턴을 말합니다. 에이전트가 타사 저장소를 읽고 문서나 스크립트 내의 지침을 안전한 운영 지침으로 처리할 수 있습니다.
Rogue Agent는 보고된 Dialogflow CX 보안 문제로, 에이전트 워크플로 내에서 코드 실행이 포함됩니다. 더 넓은 교훈은 코드 실행, 세션 액세스 및 클라우드 런타임 권한이 있는 AI 챗봇은 단순한 대화 스크립트가 아닌 프로덕션 소프트웨어처럼 취급되어야 한다는 것입니다.
AI 코딩 에이전트는 종종 신뢰할 수 없는 파일을 읽고 배운 내용을 바탕으로 도구를 사용합니다. 저장소, 이슈 또는 문서에 숨겨진 지침이 포함된 경우 에이전트는 신뢰할 수 없는 콘텐츠를 신뢰할 수 있는 사용자 의도와 혼동할 수 있습니다.
샌드박싱은 중요하지만 유일한 방어 수단이 되어서는 안 됩니다. 안전한 설정에는 권한 경계, 네트워크 제한, 비밀 키 격리, 결정적 스캐닝, 명령 출처 및 감사 로그도 필요합니다.
자동으로 실행해서는 안 됩니다. README 명령은 유용한 문서가 될 수 있지만 검사 중인 저장소에서 비롯됩니다. 신뢰할 수 없는 프로젝트의 경우 에이전트는 실행이 승인되기 전에 명령 출처와 위험을 설명해야 합니다.
일회용 환경을 사용하고, 비밀 키 마운트를 피하고, 네트워크 액세스를 제한하고, 먼저 정적 검사를 실행하고, 검토된 패치나 보고서만 가져오세요. 샌드박스 상태나 생성된 아티팩트를 기본적으로 신뢰하지 마십시오.
제품은 파일 읽기, 패치 작성, 테스트 실행, 의존성 설치, 네트워크 사용, 비밀번호 접근, 풀 리퀘스트 생성, 배포 등의 각 기능에 대해 세분화된 제어 권한을 노출해야 합니다. 각 기능은 고유한 범위, 예산, 로그 및 승인 규칙을 가져야 합니다.
Friendly Fire와 Rogue Agent는 AI 에이전트 보안이 단순히 모델 정렬 문제가 아님을 보여줍니다. 실제 경계는 런타임, 즉 파일, 명령어, 네트워크 접근, 비밀번호, 실행 환경 및 감사 가능성에 있습니다.
AI 코딩 에이전트를 사용하는 팀은 작업이 방어적이더라도 신뢰할 수 없는 저장소와 외부 컨텍스트를 신뢰할 수 없는 입력으로 취급해야 합니다. 에이전트는 검사와 설명을 도울 수 있지만, 실행은 샌드박싱, 정책, 스캐너 및 명시적 승인에 의해 제어되어야 합니다.
가장 안전한 패턴은 간단합니다. 에이전트가 광범위하게 추론하도록 허용하되, 운영 권한은 좁게 부여하는 것입니다.
한 문장에서 시작해 몇 분 안에 완전한 웹사이트를 받아보세요.
