멀티 에이전트에서 권한이 새는 지점
이 논문이 다루는 문제는 모델 성능 자체보다 위임된 권한을 어디까지 허용할 것인가에 가깝다. LLM 기반 에이전트는 사용자를 대신해 클라우드 서비스에 접근하고, 도구를 호출하고, 다른 에이전트에게 일을 넘길 수 있다. 문제는 세션이 시작될 때 정해진 권한이 이후 요청마다 거의 같은 방식으로 적용되고, 앞서 어떤 행동을 했는지까지 누적해서 판단하지 않는 경우가 많다는 점이다.
개인 사용자나 연구자가 보기에는 “프롬프트 인젝션을 더 잘 막는 방법”처럼 보일 수 있지만, 논문의 핵심은 조금 다르다. 공격이 위험해지는 이유는 모델이 속았기 때문만이 아니라, 속은 모델에게 실제로 파일 읽기, 전송, 삭제, 외부 호출 같은 권한이 있었기 때문이다. 그래서 저자는 이 문제를 모델 안전성만이 아니라 인가 구조의 문제로 본다.
Bounded Agents가 제안하는 핵심 관점
논문은 Agentic Principal Chain, 줄여서 APC라는 구조를 제안한다. APC는 한 주체에서 다음 주체로 넘어가는 위임 권한의 흐름을 추적한다. 사용자가 에이전트에게 권한을 주고, 그 에이전트가 다시 하위 에이전트나 도구를 호출할 때, 권한 범위와 예산이 그대로 풀리는 것이 아니라 제한된 형태로 이어져야 한다는 접근이다.
중요한 부분은 각 요청을 따로 보는 것이 아니라 세션 안에서 누적된 상태와 함께 평가한다는 점이다. 예를 들어 어떤 작업은 단독으로 보면 허용될 수 있다. 파일 목록 조회, 특정 문서 열람, 외부 API 호출이 각각은 정책상 가능할 수 있다. 하지만 이 행동들이 결합되면 민감한 데이터를 외부로 빼내는 결과가 될 수 있다. APC는 이런 조합을 사전에 정의된 제한 조건과 비교해 차단하는 방향을 취한다.
또 하나의 실무적 포인트는 판단을 모델 내부의 자기검열에만 맡기지 않는다는 점이다. 논문 설명에 따르면 APC의 결정은 모델 바깥에서 강제된다. 실제 제품에 적용한다면, 이는 “모델에게 하지 말라고 지시한다”보다 “권한 집행 계층에서 못 하게 막는다”에 더 가깝다.
개인 사용자와 개발자가 먼저 봐야 할 차이
이 논문은 바로 설치해서 쓰는 소비자용 기능 소개가 아니다. 따라서 지금 당장 가격, 플랜, 지역 제공 여부를 비교할 수 있는 제품 발표로 읽기보다는, 앞으로 에이전트 제품을 고를 때 확인해야 할 보안 기준으로 보는 편이 적절하다. 특히 여러 도구를 연결한 AI 비서, 연구 자동화 파이프라인, 코드 에이전트, 일정·메일·문서 처리 에이전트를 쓰는 사람에게 의미가 있다.
단일 챗봇에서는 실패가 대체로 잘못된 답변에 머무를 수 있다. 반면 멀티 에이전트 시스템에서는 한 에이전트가 다른 에이전트에게 권한을 넘기고, 여러 호출이 이어지고, 그 결과가 실제 계정이나 저장소에 반영될 수 있다. 이때 “어떤 도구를 쓸 수 있는가”만 보는 것은 부족하다. “이 도구를 어떤 순서와 조합으로 썼을 때 어디까지 허용되는가”를 봐야 한다.
논문 수치에서 읽을 수 있는 것
저자는 InjecAgent, AgentDojo, ASB를 포함해 3,154개 인스턴스에서 평가했다고 밝힌다. 논문 초록 기준으로 AgentDojo의 데이터 유출은 네 개 도메인에서 75~100% 수준에서 0%로 떨어졌고, APC는 InjecAgent의 데이터 탈취 사례 544개를 모두 차단했다. 또한 intent binding을 적용했을 때 destruction은 38.6%에서 4.0%로, manipulation은 90.5%에서 12.1%로 낮아졌다고 제시한다.
성능 비용도 언급된다. 유휴 호스트 기준 99퍼센타일 인가 지연 시간은 0.24ms로 보고됐다. 다만 보안 강화가 공짜는 아니다. 949개의 AgentDojo task-injection 쌍에서 utility가 두 설정에서 각각 8.6퍼센트포인트, 13.9퍼센트포인트 낮았다고 되어 있다. 즉 이 접근은 공격 차단 효과를 보였지만, 일부 정상 작업의 수행성이나 편의성을 줄일 수 있다.
| 확인 항목 | 논문에서 볼 근거 | 실사용 전 해석 |
|---|---|---|
| 권한 위임 | APC가 주체 간 위임 권한을 추적 | 하위 에이전트가 원래 작업보다 넓은 권한을 갖지 않는지 확인해야 한다. |
| 행동 조합 | 개별 허용 행동의 금지된 조합을 검사 | 파일 읽기와 외부 전송처럼 함께 쓰이면 위험한 조합을 정책으로 표현할 수 있어야 한다. |
| 집행 위치 | 결정을 모델 외부에서 강제 | 프롬프트 규칙뿐 아니라 도구 호출 계층의 차단 장치가 있는지 봐야 한다. |
| 편의성 손실 | 일부 평가에서 utility 하락 보고 | 보안을 높이면 정상 자동화가 일부 막힐 수 있으므로 예외 처리 기준이 필요하다. |
에이전트 제품을 고를 때 확인할 질문
- 에이전트가 연결된 서비스별로 읽기, 쓰기, 삭제, 전송 권한을 분리해서 줄 수 있는가?
- 하위 에이전트나 플러그인 호출 시 원래 권한이 그대로 복사되는가, 아니면 더 좁게 제한되는가?
- 한 번의 요청만 검사하는가, 아니면 같은 세션에서 앞서 수행한 행동까지 함께 평가하는가?
- 민감한 데이터 접근과 외부 전송이 결합될 때 별도 차단 규칙을 둘 수 있는가?
- 보안 결정이 모델 응답 안에서만 이뤄지는가, 아니면 실제 도구 호출 전후의 권한 계층에서 강제되는가?
- 정상 작업이 막혔을 때 사용자가 어떤 로그를 보고 왜 차단됐는지 이해할 수 있는가?
연구·개발 워크플로에 붙일 때의 기준
학생이나 연구자가 논문 정리, 자료 검색, 데이터셋 관리에 에이전트를 붙인다면 첫 기준은 자동화 폭이 아니라 자료의 민감도다. 공개 논문 검색처럼 위험이 낮은 작업과, 미공개 원고·실험 데이터·계정 토큰이 섞인 작업은 같은 권한 정책으로 다루면 안 된다. APC가 제기하는 관점은 바로 이 구분을 시스템 구조 안에 넣어야 한다는 것이다.
개발자라면 코드 저장소 접근 권한을 더 세밀하게 봐야 한다. 이슈 읽기, 브랜치 생성, 코드 수정, CI 재실행, 배포 트리거는 서로 다른 위험을 가진다. 단순히 “GitHub에 연결 가능”하다는 문구만으로는 충분하지 않다. 에이전트가 어떤 순서로 어떤 권한을 조합할 수 있는지, 그리고 그 조합이 의도한 작업을 벗어날 때 차단되는지 확인해야 한다.
팀 단위에서는 비용보다 권한 관리가 먼저다. 모델 사용량 제한과 월 비용은 이후에도 조정할 수 있지만, 잘못 넓어진 권한은 사고가 난 뒤에야 드러나는 경우가 많다. 특히 여러 에이전트가 각자 다른 도구를 호출하는 구조라면, 각 에이전트의 역할과 예산, 접근 가능한 데이터 범위를 문서로 남겨야 한다.
바로 적용 가능한 검토 순서
- 현재 쓰는 에이전트가 실제로 호출할 수 있는 도구 목록을 확인한다.
- 각 도구에 대해 읽기, 쓰기, 삭제, 외부 전송 권한을 분리해 적는다.
- 개별 권한은 허용되지만 함께 쓰이면 위험한 조합을 찾는다.
- 하위 에이전트나 자동 실행 기능이 있는 경우 권한이 축소되어 전달되는지 확인한다.
- 프롬프트 인젝션이 발생했을 때 실제로 실행 가능한 최악의 행동을 가정한다.
- 작은 샘플 작업에서 차단 로그, 정상 작업 실패율, 되돌리기 방법을 함께 확인한다.
이 논문을 제품 소식으로 읽을 때 주의할 점
논문에는 구현, 평가 도구, 데이터가 공개되어 있다고 되어 있지만, 이것이 곧 특정 상용 제품에 바로 적용됐다는 뜻은 아니다. 따라서 실제 제품 선택 단계에서는 공식 문서, 관리자 설정, API 권한 모델, 감사 로그 제공 여부를 따로 확인해야 한다. 가격이나 플랜 조건도 이 원문만으로는 판단할 수 없다.
또한 논문의 Composition Soundness는 완전한 제한 집합과 직렬화된 승인 조건 아래에서 금지된 조합에 대해 제한적으로 설명된다. 실사용 시스템이 병렬 실행, 비동기 작업, 외부 서비스 재시도, 캐시된 권한을 갖는다면 같은 보장이 그대로 성립한다고 단정하면 안 된다. 적용 전에는 내가 쓰는 시스템의 실행 방식이 논문 가정과 얼마나 맞는지 봐야 한다.
현실적인 결론
Bounded Agents의 가치는 “더 똑똑한 에이전트”보다 “더 좁게, 더 추적 가능하게 권한을 맡기는 에이전트”라는 기준을 제시한다는 데 있다. 멀티 에이전트 시스템을 쓰거나 만들고 있다면 프롬프트 방어 문구만 늘리는 것으로는 부족하다. 사용자가 맡긴 목표, 세션 중 누적된 행동, 하위 에이전트로 넘어간 권한, 금지된 행동 조합을 함께 다뤄야 한다.
개인 사용자라면 당장 모든 도구를 바꿀 필요는 없다. 대신 AI 에이전트에 메일, 드라이브, 저장소, 결제, 배포 권한을 연결하기 전에는 “이 에이전트가 속았을 때 실제로 무엇을 할 수 있는가”를 먼저 물어야 한다. 연구자와 개발자에게는 이 논문이 멀티 에이전트 보안 설계를 비교하는 기준표로 유용하다.
출처와 검증
원문은 arXiv 문서 Bounded Agents: Delegation Security for Multi-Agent AI Systems다. 저자는 Xabier Muruaga이며, arXiv 기록상 2026년 8월 16일 제출된 논문이다. Hacker News AI 피드에서는 2026년 8월 21일 08:32 UTC 시각의 항목으로 확인된다.
실제 제품 적용 여부, 가격, 계정별 제공 범위, 관리자 설정, API 권한 모델은 이 문서만으로 확정할 수 없다. 적용 전에는 사용하는 서비스의 공식 문서와 보안 설정 화면에서 권한 분리, 감사 로그, 하위 에이전트 권한 제한, 데이터 보존 조건을 직접 확인해야 한다.