[AI] AI 보안 · 작성: 2026-07-19 19:41:12 · 조회 6
LLM 하나가 질문에 답하는 걸 넘어, 여러 에이전트가 서로 도구를 호출하고 서로의 결과를 넘겨받으며 작업을 나눠 처리하는 멀티 에이전트/오케스트레이션 구조가 빠르게 늘고 있다. 에이전트 하나하나는 각자 안전하게 설계되어도, 여러 에이전트가 서로를 신뢰하며 엮이는 순간 개별 컴포넌트에는 없던 새로운 공격 표면이 생긴다.
단일 LLM 앱에서는 "사용자 입력 → 모델 → 도구 호출"이라는 신뢰 경계가 비교적 명확하다. 오케스트레이션 구조에서는 이게 훨씬 복잡해진다.
사용자 → 오케스트레이터 에이전트 → 리서치 에이전트 → 웹 검색 도구
→ 코드 실행 에이전트 → 셸
→ 이메일 에이전트 → 실제 발송
각 에이전트는 "이전 에이전트가 준 입력은 신뢰할 수 있다"고 가정하는 경우가 많은데, 사용자 입력이 오케스트레이터를 거쳐 하위 에이전트로 전파되는 과정에서 원래의 신뢰 수준(사용자=신뢰 불가)이 유지되지 않고 점점 "내부 시스템끼리의 대화"처럼 취급되는 경향이 생긴다. Prompt Injection 글에서 다룬 "지시와 데이터의 경계가 흐리다"는 문제가, 에이전트 간 통신에서는 "어느 에이전트가 준 데이터인지"까지 더해져서 한층 복잡해진다.
전통적인 보안에서 "Confused Deputy"는 높은 권한을 가진 프로그램이, 낮은 권한의 요청자를 대신해 작업을 수행하다가 그 권한을 남용당하는 문제를 가리킨다. 멀티 에이전트 구조에서 이게 그대로 재현된다.
개별 에이전트의 권한이 아니라, "에이전트 체인 전체를 관통했을 때 최종적으로 어떤 권한 조합이 행사되는가"를 봐야 실제 위험이 보인다.
에이전트가 여러 도구를 순서대로 호출할 수 있으면, 개별 도구는 안전해 보여도 조합했을 때 위험한 동작이 나올 수 있다.
도구 하나하나를 심사할 때는 통과해도, 에이전트가 자율적으로 도구를 조합해서 쓰는 순간 심사 범위 밖의 동작이 생긴다는 게 핵심 리스크다.
에이전트가 외부 도구/데이터 소스에 연결하는 방식이 표준화되면서(MCP 등), "신뢰할 수 없는 MCP 서버에 연결하면 그 서버가 제공하는 도구 설명 자체가 오염된 프롬프트일 수 있다"는 새로운 공급망 문제도 제기되고 있다. 모델은 도구의 이름과 설명을 보고 언제 그 도구를 쓸지 판단하는데, 그 설명 문구 자체에 지시문이 숨어 있으면(Tool Description Injection) 별도의 사용자 입력 없이도 모델이 조작당할 수 있다.
오케스트레이션 구조는 개별 컴포넌트의 보안을 다 지켜도, 그것들이 엮이는 "사이"에서 새로운 문제가 생긴다는 게 기존 소프트웨어 보안과 다른 지점이다. 시스템을 설계할 때 "이 에이전트가 뚫리면 그 다음 에이전트에 뭘 할 수 있는가"를 체인 전체로 그려보는 게 실무적으로 가장 도움이 된다.