당신의 AI 에이전트 아키텍처가 보안 리스크가 되는 이유
2027년까지 기업용 AI 배포의 40%가 프롬프트 인젝션(prompt injection) 또는 에이전트 하이재킹(agent hijack) 사고를 겪게 될 것입니다. 이는 2025년 초의 5% 미만에서 급격히 증가한 수치입니다.
오케스트레이션 레이어(orchestration layer)는 에이전트를 유용하게 만들지만, 동시에 공격의 표적으로 만듭니다.
최근 싱가포르의 한 물류 기업이 230만 달러의 손실을 입었습니다. 공격자가 악성 캘린더 초대장을 보냈고, 이것이 스케줄링 에이전트를 자극하여 CRM 데이터를 외부 편지함으로 전송하게 만들었습니다. 모델 자체에는 잘못된 코드가 없었습니다. 모델은 지시 사항을 완벽하게 수행했을 뿐입니다. 문제는 아키텍처였습니다.
에이전트는 단순한 챗봇이 아닙니다. 파일을 읽고, API를 호출하며, 트랜잭션을 실행하는 도구입니다. 기존의 보안 모델은 요청이 들어오고 응답이 나가는 것을 전제로 합니다. 하지만 에이전트는 이 모델을 무너뜨립니다.
PDF를 요약하고 환불을 신청할 수 있는 에이전트는 하나의 런타임(runtime) 안에 세 개의 앱이 들어있는 것과 같습니다. 모든 도구 호출(tool call)이 리스크이며, 모든 메모리 쓰기(memory write)가 리스크입니다. 이제 모든 이메일이나 문서는 실행 가능한 코드가 되었습니다.
안전하게 구축하려면 세 가지 레이어가 필요합니다:
• Identity: 모든 도구 호출은 사용자로부터 분리된 고유한 신원을 가져야 합니다. • Provenance: 모든 메모리 쓰기에는 데이터의 출처를 나타내는 메타데이터가 필요합니다. • Intent: 모든 계획 단계에는 다운스트림 시스템이 검증할 수 있는 서명된 객체(signed object)가 필요합니다.
에이전트가 프로덕션 API를 직접 호출하게 두지 마십시오. 중개 도구 레이어(mediated tool layer)를 사용하십시오. 이 레이어는 새로운 방화벽 역할을 합니다. 인자(arguments)를 검증하고 각 세션에 대한 권한을 제한합니다.
에이전트의 메모리를 주시하십시오. 공격자들은 오염된 문서나 이메일을 사용하여 시간이 지남에 따라 에이전트의 행동을 재작성합니다. 메모리 포이즈닝(memory-poison
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi