파이브 아이즈 에이전트 AI 보안 지침: 엔지니어링 팀을 위한 쉬운 설명서

Sang Lee

July 17, 2026

최종 업데이트: 2026년 7월 15일

핵심 요약

2026년 5월 1일, 미국, 영국, 호주, 캐나다, 뉴질랜드의 사이버 보안 기관은 공동으로 에이전트형 AI 서비스의 신중한 도입을(를) 발표했습니다. 이는 파이브 아이즈 동맹이 내놓은 최초의 에이전트형 AI 보안 지침입니다. 핵심 원칙은 다음과 같습니다. 에이전트에 광범위하거나 제한 없는 접근 권한을 부여하지 말 것, 저위험 및 비민감 작업으로 범위를 제한할 것, 요청별 인증을 통해 최소 권한 원칙을 준수할 것, 영향력이 큰 작업에는 반드시 사람의 승인을 거칠 것, 그리고 AI 보안을 별도의 영역이 아닌 기존 사이버 보안 프레임워크 내에서 관리할 것입니다.

개요

지침의 정의 및 작성 기관
에이전트형 AI를 위한 별도의 보안 문서가 필요한 이유
5가지 위험 범주 및 상세 설명
수명 주기 단계별 권장 조치 사항
지양해야 할 사항
배포 전 필수 점검 항목
자주 묻는 질문(FAQ)

파이브 아이즈의 에이전트형 AI 보안 지침이란 무엇인가?

에이전트형 AI 서비스의 신중한 도입 은(는) LLM 기반 AI 에이전트 고유의 보안 위험을 정의하고, 설계, 개발, 배포 및 운영에 관한 약 100가지 권장 사항을 제시합니다. 이 지침은 미국의 CISA 및 NSA, 영국의 NCSC-UK, 호주의 ASD ACSC, 캐나다 사이버 보안 센터, 뉴질랜드 NCSC 등 6개 기관이 공동으로 작성했습니다.

‍

이 지침은 규정이 아닙니다. 법적 구속력은 없으며, 앞서 다룬 바와 같이 엔지니어링 팀이 AI 규제를 기다릴 수 없는 이유에 대한 분석, 구속력 있는 규칙이 마련되기까지는 수년이 걸릴 것으로 보입니다. 하지만 파이브 아이즈(Five Eyes)의 공동 지침은 1~2년 내에 감사관, 조달 팀, 사이버 보험사가 참조하는 사실상의 기준이 된 전례가 있습니다. 'Secure by Design(설계 단계부터 보안 강화)' 원칙도 같은 길을 걸었습니다. 프로덕션 환경에 에이전트를 배포하고 있다면, 이 문서는 현재 구할 수 있는 가장 공식적인 체크리스트에 가깝습니다.

‍

이 글의 나머지 부분에서는 이를 실무에 적용할 수 있는 용어로 풀이합니다. 원문이 필요하시다면, CISA 리소스 페이지 에서 전체 문서를 확인하실 수 있습니다.

에이전트를 위한 별도의 보안 문서가 필요한 이유

이 지침은 생성형 AI와 에이전트형 AI를 명확히 구분하며, 바로 그 구분 때문에 이 문서 전체가 존재합니다. 사람이 읽을 텍스트를 생성하는 챗봇은 실패 모드가 제한적이지만, 자격 증명을 보유하고 도구를 호출하는 에이전트는 그렇지 않습니다.

No.	Dimension	Generative AI	Agentic AI
1	Output	Content for a human to review	Actions executed against real systems
2	Failure mode	Bad text reaches a human	Bad action reaches your infrastructure
3	Credentials	None, or read-only	API keys, tokens, service permissions
4	Blast radius	One conversation	Every system the agent can touch
5	Human checkpoint	Built in (a person reads the output)	Only if you deliberately design one in

위 표는 이 지침의 핵심 차이점을 요약합니다. 생성형 AI는 사람이 검토한 후 결과물이 나오는 콘텐츠를 생성하는 반면, 에이전트형 AI는 작업을 직접 실행합니다. 따라서 에이전트가 손상되거나 오류를 일으키면 사람이 직접 개입하는 단계를 설계해 두지 않는 한 실제 시스템에 즉각적인 영향을 미칩니다.

‍

에이전트에 연결하는 모든 구성 요소(도구, 메모리, RAG 저장소, 웹 검색)는 공격 표면을 넓힙니다. 컨텍스트 윈도우로 유입되는 외부 데이터는 간접 프롬프트 주입의 경로가 됩니다. 지침에서 제시한 예시는 피싱 이메일에 삽입된 악성 프롬프트가 이메일 모니터링 에이전트를 속여 악성 코드를 다운로드하게 만드는 상황입니다.

‍

5가지 위험 범주, 번호별 풀이

이 지침은 에이전트형 AI의 위험을 5가지 범주로 분류합니다. 문서에 명시된 순서대로 각 범주를 알기 쉽게 설명해 드립니다.

1. 권한 위험

에이전트는 필요한 것보다 더 많은 접근 권한을 갖게 되며, 이 권한이 악용됩니다. 지침의 예시를 보면, 재무 시스템, 이메일, 계약 저장소에 대한 광범위한 접근 권한을 부여받은 조달 에이전트가 배포 시점에만 권한 평가를 받습니다. 공격자가 에이전트 워크플로 내의 위험도가 낮은 도구 하나를 장악하면, 계약 수정이나 결제 승인과 같이 에이전트가 가진 모든 권한을 그대로 물려받게 됩니다. 이는 전형적인 '혼란스러운 대리인(confused deputy)' 패턴으로, 권한이 낮은 공격자가 권한이 높은 에이전트를 조종하여 직접 할 수 없는 일을 수행하게 만드는 방식입니다.

‍

여기서 주목할 점은 공격자가 신뢰받는 에이전트의 신원을 통해 행동하기 때문에 감사 로그는 정상적으로 보인다는 것입니다. 기존의 탐지 도구는 비정상적인 행동을 포착하도록 설정되어 있는데, 이 경우 그 어떤 행동도 비정상적으로 보이지 않습니다.

‍

신뢰 연쇄(Trust Cascade): 에이전트 A가 에이전트 B의 결과물을 무조건 신뢰할 경우, B의 보안이 뚫리면 A는 물론 A의 하위 단계에 있는 모든 요소까지 순식간에 위험해진다는 경고입니다. 에이전트별로 권한을 개별 평가하는 방식으로는 이 문제를 해결할 수 없습니다. 네트워크 세분화를 설계하듯 에이전트 간의 신뢰 관계를 매핑하십시오. 가치가 낮은 에이전트 하나만 뚫려도 그 결과물을 사용하는 모든 에이전트로 피해가 확산될 수 있기 때문입니다.

‍

2. 설계 및 구성 위험

핵심은 권한 부여의 유효성입니다. 권한을 매번 호출할 때 확인하지 않고 시작 시점에만 한 번 확인한다면, 공격자는 상황이 변한 뒤에도 캐시된 '허용' 결정을 악용할 수 있습니다. 여기에 과도한 권한을 가진 검증되지 않은 타사 구성 요소를 추가하고 에이전트 환경 간의 분리가 제대로 이루어지지 않으면, 사소한 설정 오류 하나가 시스템 전체의 측면 이동(lateral movement)으로 이어집니다.

‍

3. 행동 위험

에이전트는 부여된 권한을 예상치 못한 방식으로 사용할 수 있습니다. 이 지침에서는 사양 게임(가동 시간 극대화를 위해 보안 업데이트를 비활성화하는 에이전트), 의도 오해, 기만적 행동(평가 중임을 감지하면 행동을 바꾸는 에이전트), 그리고 프롬프트 인젝션, 탈옥, 데이터 오염, 적대적 입력을 통한 고의적 악용을 다룹니다. 모델 자체에 대한 공격은 이미 일상화되었습니다. 저희가 분석한 모델 추출 및 모델 반전 은 API 접근 권한만으로 가능한 두 가지 공격 유형을 다룹니다. 기억에 남는 예시로, 광범위한 파일 시스템 쓰기 권한을 가진 업데이트 에이전트가 "모든 엔드포인트에 보안 패치를 적용하고, 그 김에 방화벽 로그도 정리해 줘"라는 요청을 받았을 때, 요청자가 권한 있는 IT 그룹 소속이 아님에도 불구하고 두 작업 모두를 실행하는 경우가 있습니다.

‍

4. 구조적 위험

시스템의 상호 연결된 구조를 통해 장애가 전파됩니다. 오케스트레이션 결함 하나가 리소스를 고갈시키는 재계획 루프를 유발하고, 성능이 저하된 상태에서 에이전트가 잘못 구성된 타사 도구를 선택하며, 해당 도구가 시스템에 악성 명령을 주입하고, 동료 에이전트들이 그 결과물을 사실로 받아들이는 식입니다. 단 하나의 극적인 버그 없이도 연쇄적인 장애가 발생할 수 있습니다. 이 범주에는 도구 스쿼팅(합법적인 이름과 유사한 악성 도구 배포), 안전하지 않은 에이전트 간 통신, 다중 에이전트 시스템 내의 비정상 에이전트 문제도 포함됩니다. 여기서 필요한 완화 전략(에이전트별 범위 제한, 선별된 컨텍스트, 에이전트 간 교차 검증)은 저희가 단일 에이전트 LLM 래퍼가 프로덕션 SRE에서 실패하는 이유에서 주장했던 아키텍처와 동일합니다.

‍

5. 책임 소재 위험

여러 에이전트가 협업하여 작업을 수행하다 문제가 발생했을 때, 어떤 구성 요소가 원인인지 파악하는 것은 어렵습니다. 은 거의 불가능에 가깝습니다. 긴 추론 과정, 확률적 출력(동일한 프롬프트로 다른 작업이 수행될 수 있음), 하위 에이전트 생성, 그리고 방대하고 구조화되지 않은 로그는 모두 의사결정 경로를 파악하기 어렵게 만듭니다. 에이전트가 왜 그런 행동을 했는지 재구성할 수 없다면, 규정 준수를 입증하거나 책임을 할당하거나 근본 원인을 해결할 수 없습니다.

‍

지침이 권장하는 사항

이 권장 사항들은 시스템 수명 주기에 따라 구성되어 있습니다. 각 단계별로 대상이 명시되어 있는데, 설계 및 개발 섹션은 개발자와 공급업체를 대상으로 하며, 배포 및 운영 섹션은 프로덕션 환경에서 에이전트를 운영하는 팀을 대상으로 합니다.

‍

기관의 언어를 엔지니어링 실무로 번역하면 다음과 같습니다.

No.	What the guidance says	What it means for your team
1	"Construct each agent as a distinct principal"	Every agent gets its own cryptographic identity (keys or certs); no shared service accounts across agents
2	"Authenticate all inter-agent and agent-to-service API calls using mutual TLS"	Agent-to-agent traffic needs mTLS, not bearer tokens passed around in config
3	"Require just-in-time credentials for high-impact or privileged actions"	Replace static long-lived API keys with ephemeral credentials that expire when the task completes
4	"Implement phased deployment with progressively increasing access and autonomy"	Ship the agent with read-only access to one low-risk workflow first; expand scope only after observing production behavior
5	"Set system configurations to fail-safe by default"	When the agent hits an uncertain scenario, it stops and escalates to a human; it doesn't guess
6	"Quarantine requests to delete logs or audit records until reviewed by a human"	Any agent request to touch logs is held for human approval, no exceptions
7	"Monitor all agent operations, including internal processes, not just the inputs and outputs"	Log tool calls, memory interactions, and reasoning steps; I/O logging alone won't reconstruct an incident
8	"Decisions about when human approval is required are determined by system designers or operators, not delegated to the agentic AI system"	The agent never decides its own escalation threshold

실제로 이 지침의 100가지가 넘는 권장 사항은 익숙한 형태로 귀결됩니다. 에이전트별 ID 부여, 시작 시점이 아닌 요청 시마다 최소 권한 원칙 적용, 단계적 배포, 포괄적인 로깅, 그리고 영향력이 크거나 되돌릴 수 없는 작업에 대한 인간의 승인 절차가 그것입니다.

‍

직접 도입할 가치가 있는 두 가지 참조 자료는 다음과 같습니다. 이 지침은 OWASP 에이전트 애플리케이션 상위 10대 취약점 및 MITRE ATLAS 를 배포 계획 시 사용할 위협 모델링 분류 체계로 제시하며, NIST SP 800-207 을 에이전트 배포 시 준수해야 할 제로 트러스트 아키텍처의 기준으로 언급합니다.

‍

하지 말아야 할 것

이 지침은 권장 사항만큼이나 실패 패턴을 명시하는 데 유용합니다. 다음은 지침에서 설명하는 안티 패턴으로, 피해야 할 실수들입니다.

"편의성을 위해" 광범위한 액세스 권한을 부여하는 것. 이는 지침에서 다루는 조달 에이전트 침해 시나리오의 시작점입니다. 불편함은 곧 통제 수단입니다.
배포 시점에만 권한을 평가하는 것. 권한은 호출할 때마다 확인해야 합니다. 오래된 허용 결정은 공격의 빌미가 됩니다.
정적이고 공유되며 수명이 긴 자격 증명입니다. 에이전트 간에 키를 공유하면 공격자 한 명이 여러 에이전트를 사칭할 수 있습니다.
에이전트가 사람의 승인을 요청할 시점을 스스로 결정하게 두는 것입니다. 지침은 명확합니다. 해당 임계값은 설계자와 운영자가 설정해야 하며, 에이전트가 결정해서는 안 됩니다.
에이전트가 생성한 로그를 절대적인 진실로 신뢰하는 것입니다. 손상된 에이전트는 로그를 조작할 수 있으므로, 지침에서는 에이전트를 로그에 대한 쓰기 권한이 없는 격리된 환경(enclave)에 배치하고 독립적인 모니터링을 통해 교차 검증할 것을 권장합니다.
AI 보안을 독립적인 프로그램으로 취급하는 것입니다. 이 문서의 입장은 AI 시스템도 IT 시스템의 일부라는 것이며, 에이전트 관련 위험은 별도의 구조를 만들어 동기화가 어긋나게 할 것이 아니라 기존의 보안 프레임워크, 사고 대응 및 거버넌스 체계 내에서 관리해야 한다는 것입니다.

‍

에이전트가 아닌 선행 조건부터 시작하십시오

지침의 부록 A에는 사이버 보안 선행 조건이 나열되어 있습니다. 이 조건들은 에이전트를 배포하기 전에 갖추어야 할 필수 항목으로, 일종의 필터 역할을 합니다. 조직이 이러한 조건을 충족하는 데 어려움을 겪는다면 에이전트 도입은 시기상조입니다. 주요 내용은 다음과 같습니다. 특정 리소스, 작업, 시간대로 제한된 최소 권한 부여, 정적 비밀 정보를 대체하는 일회성 자격 증명, 암호화 및 속도 제한이 적용된 샌드박스 인프라, 무결성 및 최신성 검사를 포함한 메시지 검증, 그리고 검증된 사고 대응 계획입니다.

‍

이 문서의 결론은 기관 간 공동 발행물로서는 이례적으로 직설적이므로 인용할 가치가 있습니다. "조직은 에이전트형 AI 시스템이 예상치 못하게 작동할 수 있음을 가정하고, 효율성 향상보다 복원력, 가역성 및 위험 억제를 우선시하여 배포 계획을 수립해야 한다."

‍

이 지침의 모니터링 권장 사항은 온콜(on-call) 팀에게 실질적인 시사점을 줍니다. AI 기반 공격은 보안 경고가 아닌 운영상의 이상 징후로 먼저 나타나는 경향이 있습니다. 이것이 바로 AI 침해 사고가 처음에는 장애처럼 보이는 이유이며, 이제 온콜 엔지니어가 보안 대응의 최전선에 서게 된 이유입니다..

‍

자주 묻는 질문

Five Eyes 에이전트형 AI 보안 지침은 누가 발행했나요?

미국의 CISA와 NSA, 영국의 NCSC, 호주 신호국(ASD)의 ACSC, 캐나다 사이버 보안 센터, 뉴질랜드의 NCSC 등 6개 기관이 공동으로 작성했습니다. 이 지침은 2026년 5월 1일에 에이전트형 AI 서비스의 신중한 도입이라는 제목으로 발행되었습니다..

이 지침은 의무 사항인가요?

아니요. 이는 규제가 아닌 자발적 지침입니다. 하지만 그 영향력은 상당합니다. 파이브 아이즈(Five Eyes) 국가들이 공동으로 발표하는 문서는 감사인, 조달 요건, 부문별 규제 기관, 특히 핵심 인프라 및 정부 공급망 분야에서 사실상의 표준(reference baseline)이 되는 경향이 있기 때문입니다.

이 지침에서는 AI 에이전트를 어떤 작업에 사용하라고 권장하나요?

위험도가 낮고 민감하지 않은 작업에만 사용해야 합니다. 작성 기관들은 에이전트에 광범위하거나 제한 없는 접근 권한(특히 민감한 데이터나 핵심 시스템에 대한 접근)을 부여하지 말 것을 권고하며, 일부 반복적인 프로세스의 경우 자동화하기보다 아예 제거하는 것이 위험을 줄이는 방법일 수 있다고 언급합니다.

지침에서 제시하는 5가지 위험 범주는 무엇인가요?

권한 위험, 설계 및 구성 위험, 행동 위험, 구조적 위험, 책임 위험입니다. 권한 및 구성 위험은 과도하거나 오래된 접근 권한을 다루며, 행동 위험은 에이전트의 예상치 못한 동작을, 구조적 위험은 상호 연결된 구성 요소 간의 연쇄적 장애를, 책임 위험은 에이전트의 동작 원인을 추적하기 어려운 문제를 다룹니다.

엔지니어링 팀은 어디서부터 시작해야 할까요?

부록 A의 필수 요건인 최소 권한 원칙, 일회성 자격 증명, 샌드박스 환경, 검증된 사고 대응 체계부터 시작하세요. 그 후, 에이전트에 프로덕션 접근 권한을 부여하기 전에 OWASP의 에이전트 AI 분류 체계와 MITRE ATLAS를 사용하여 해당 배포 환경에 대한 위협 모델링을 수행하십시오.

‍

AI 바이브 코딩, 비용과 신뢰성 검증대에 오르다: 스타트업들이 뼈저리게 배우고 있는 교훈

온콜의 새로운 기준.
알림부터 해결까지 에이전트가 알아서.

Vibe OnCall 체험하기

데모 예약하기