챗봇이 환각 (Hallucination)을 일으키면, 사람이 답변을 읽고 이를 잡아냅니다. 하지만 에이전트가 환각을 일으키면, 누군가 확인하기도 전에 이미 쿼리를 실행했거나, 이메일을 보냈거나, 설정을 변경했을 수도 있습니다. 이 단 하나의 차이점 때문에 에이전트 안전 (Agent Safety)은 애플리케이션 보안 (Application Security)의 하위 섹션이 아닌 그 자체의 독립된 분야가 되었으며, OWASP가 2025년 12월에 이 문제를 기존 LLM 목록에 포함시키는 대신 에이전트 애플리케이션 (Agentic Applications)을 위한 전용 Top 10을 출시한 이유이기도 합니다.

제가 대화하는 대부분의 팀이 이를 놓치고 있는 이유는 동의하지 않아서가 아닙니다. 안전 관련 작업이 계획에 한 줄도 포함되지 않았기 때문입니다. 에이전트는 출시되었고, 제대로 작동했으며, 출시 첫날 함께 도입된 액세스 모델 (Access Model)은 90일이 지난 지금까지도 그대로 유지되고 있습니다.

권한 남용 (Permission Creep)이 실제 공격 표면이다

실제로 발생하는 사고들은 지루할 정도로 단순합니다. 문서를 요약하기 위해 에이전트가 구축됩니다. 두 번의 스프린트(Sprint)가 지난 후, 누군가 요약 파일을 작성해야 할 필요가 생기자 에이전트에 쓰기 권한 (Write Access)이 부여됩니다. 그다음 요약본을 게시해야 하므로 API 토큰이 부여됩니다. 파일 시스템 및 네트워크 쓰기 권한을 가진 문서 요약기를 승인하기 위해 아무도 앉아서 논의하지 않았지만, 그것이 현재의 상태이며, 아무것도 고장 나지 않았기 때문에 액세스 모델은 재검토되지 않았습니다.

최소 권한 원칙 (Least Privilege)은 동의하기는 쉽지만 유지하기는 지루하며, 바로 그 점 때문에 실패합니다. 실용적인 버전은 원칙이 아닌 규칙이 되어야 합니다: 모든 에이전트는 권한이 0인 상태에서 시작하며, 새로운 기능을 추가할 때마다 기존 권한에 단순히 추가(Append)하는 것이 아니라 전체 권한 세트를 다시 검토해야 합니다.

간접 프롬프트 주입 (Indirect Prompt Injection)은 데이터를 명령어로 바꾼다

프롬프트 주입 (Prompt Injection)은 여전히 LLM 애플리케이션에 대한 OWASP의 1순위 위험이며, 에이전트 맥락에서는 그 위험이 훨씬 더 심각해집니다. 왜냐하면 그 대가가 더 이상 오해의 소지가 있는 답변이 아니라, 실제 행동이기 때문입니다.

사용자가 시스템 프롬프트 (System Prompt)를 무시하도록 무언가를 입력하는 직접적인 방식은 누구나 테스트하는 방식입니다. 사람들을 당혹스럽게 만드는 방식은 간접적인 방식입니다. 악의적인 지시 사항이 웹 페이지, 지원 티켓, PDF, 또는 에이전트가 읽도록 지시받은 데이터베이스 행 (Database Row) 내부에 숨겨져 있는 경우입니다. 에이전트는 처리하도록 요청받은 콘텐츠와 따르도록 요청받은 지시 사항을 구분할 방법이 없으므로, 이를 그대로 따르게 됩니다.

이것이 바로 권한 (Permissions)과 인젝션 (Injection)이 두 개의 별개 문제가 아니라 동일한 문제인 이유입니다. 읽기만 할 수 있는 에이전트는 나쁜 상황이지만, 오염된 페이지를 읽고 그에 따라 행동할 수 있는 에이전트는 사고 (Incident)입니다.

행동하는 에이전트를 위한 심층 방어 (Defense In Depth)

단일 제어 장치만으로는 충분하지 않으므로, 유용한 패턴은 독립적으로 실패하는 계층 구조를 만드는 것입니다.

데이터뿐만 아니라 도구 (Tools)의 범위를 제한하세요. 내부 주소로만 이메일을 보낼 수 있는 "이메일 전송" 도구를 가진 에이전트는 일반적인 SMTP 자격 증명 (Credentials)을 보유한 에이전트와는 위험 프로필 (Risk Profile)이 다릅니다.

중요 목록 앞에는 인간을 배치하세요. 임계값 이상의 금융 거래, 운영 인프라 (Production Infrastructure) 변경, 외부 통신, 그리고 액세스 제어 (Access Control) 변경은 승인을 필요로 해야 합니다. 또한 승인 화면에는 제안된 작업 옆에 에이전트의 추론 (Reasoning) 과정을 보여주어, 인간이 단순히 형식적으로 승인 (Rubber Stamping)하는 것이 아니라 실제로 판단할 수 있도록 해야 합니다.

에이전트 간 검증을 수행하세요. 멀티 에이전트 파이프라인 (Multi-agent Pipeline)에서 메시지를 확인하지 않고 서로를 신뢰하는 에이전트들은, 단 하나의 침해된 단계를 열 개의 잘못된 출력으로 변질시킵니다.

오류뿐만 아니라 결정 사항을 모니터링하세요. 대부분의 에이전트 모니터링은 실패 사례를 집계합니다. 더 유용한 신호는 에이전트가 무엇을 하기로 선택했는지에 대한 분포입니다. 왜냐하면 호출되는 도구의 분포가 서서히 변하는 것이야말로 외부에서 보았을 때 성공적인 인젝션이 나타나는 모습이기 때문입니다.

이번 주에 시작할 일

이미 운영 환경 (Production)에서 실행 중인 에이전트를 하나 선택하여, 해당 에이전트가 가진 모든 권한과 각 권한을 누가 승인했는지 기록해 보세요. 대부분의 팀에서 그러한 문서는 아직 존재하지 않으며, 이를 작성하는 것만으로도 아무도 부여한 적을 기억하지 못하는 최소 하나 이상의 권한을 찾아내기에 충분할 것입니다.

그로부터 이어지는 효과적인 시퀀스(sequence)는 다음과 같습니다: 필요하지 않은 권한은 회수하고, 잘못 수행되기를 결코 원치 않는 작업 앞에는 승인(approval) 절차를 배치하며, 실패 사례뿐만 아니라 도구 호출(tool calls) 자체를 기록하는 로깅(logging)을 추가하는 것입니다.

위협 카테고리, 거버넌스(governance) 측면, 그리고 2026년 8월 고위험 시스템(high risk systems)에 대해 EU AI Act가 본격적으로 시행됨에 따른 컴플라이언스(compliance) 상황을 포함한 전체 분석 내용은 여기에서 확인할 수 있습니다: https://www.autolearningagents.com/ai-agent-safety/

이를 조기에 실행하는 팀들은 단순히 조심성을 기하는 것이 아닙니다. 그들은 원래 작업보다 훨씬 더 많은 비용이 드는 사후 수정(retrofit)을 피하고 있는 것입니다.