왜 멀티에이전트 AI 보안이 깨졌는가 (그리고 실제로 효과가 있는 정체성 패턴)
Source: Dev.to
번역하려는 전체 텍스트를 제공해 주시면, 요청하신 대로 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)
문제 개요
지난 화요일, 스테이징 환경에서 “무해한” 코딩 에이전트가 PR을 열고, 잘못된 환경에서 비밀 정보를 가져온 뒤, 절대 건드려서는 안 되는 배포를 시작했습니다. 해킹된 것은 아니었으며, 에이전트는 시스템이 허용한 대로 정확히 행동했습니다.
다중 에이전트 설정에서 많은 팀이 놓치는 핵심 문제는 모델 품질이 아니라 정체성입니다.
두 개 이상의 에이전트(플래너, 코더, 리뷰어, 배포자, 지원 봇 등)를 운영할 때는 다음과 같은 지루한 질문에 답해야 합니다:
- 이 에이전트는 정확히 누구인가?
- 무엇을 할 수 있도록 허용되어 있는가?
- 다른 사람을 대신해 행동할 수 있는가?
- 나중에 무슨 일이 있었는지 어떻게 증명할 것인가?
이 질문들에 답하지 않으면, 여러분의 “AI 함대”는 권한이 모호한 공유 루트 계정이 됩니다.
현재 패턴과 그 함정
전형적인 에이전트 시스템은 여전히 다음과 같이 보입니다:
Agent A ----\
Agent B -----+----> same API key / same GitHub token / same MCP access
Agent C ----/다음과 같은 상황이 발생할 때까지는 잘 작동합니다:
- 하나의 에이전트가 프롬프트 주입을 당함.
- 하나의 워크플로우에 더 좁은 권한이 필요함.
- 감사 로그가 필요함.
- 위험한 행동에 대한 승인이 필요함.
- 하나의 에이전트를 중단해야 하는데, 나머지 에이전트가 모두 깨지는 상황을 피하고 싶음.
공유 자격 증명은 편리하지만, 기여자 식별과 최소 권한 보안을 파괴합니다.
권장되는 ID 기반 패턴
가장 신뢰할 수 있는 패턴:
- 각 에이전트에 고유한 암호화 신원 부여
- 단기간 유효한 위임 접근 권한 발급
- 도구 경계에서 정책 강제 적용
- 에이전트 신원 + 위임 체인과 함께 모든 행동 로그 기록
실제 적용 예시
[Human/User]
|
| delegates task
v
[Planner Agent] -- short‑lived token --> [Coder Agent]
| |
| policy check | calls tool / MCP server
v v
[Approval / Policy Engine] -------------> [GitHub, CI, Cloud, DB]Audit log = 누가 무엇을 누구에게 위임했는지, 어떤 작업에 대해, 언제인지를 기록합니다.
그 차이는 “에이전트가 무언가를 수행했다”와 “릴리스 워크플로를 대신해 행동한 검토 에이전트가 10분 동안 이 저장소만 업데이트하도록 허용되었다”는 점에 있습니다.
구현 예시 (Node.js + Ed25519)
npm install tweetnacl tweetnacl-util
node agent-id.js// agent-id.js
const nacl = require("tweetnacl");
const util = require("tweetnacl-util");
const keypair = nacl.sign.keyPair();
const publicKey = util.encodeBase64(keypair.publicKey);
const secretKey = util.encodeBase64(keypair.secretKey);
console.log("Agent public key:", publicKey);
console.log("Store secret key securely:", secretKey.slice(0, 24) + "...");이것은 전체 신원 시스템은 아니지만 올바른 방향을 보여줍니다: 각 에이전트가 자체 키페어를 가지고, 하위 시스템이 누가 호출했는지 검증합니다.
Practical Steps for Securing Your Agent Fleet
- 에이전트 프로세스 또는 역할마다 별개의 암호학적 아이덴티티(예: Ed25519 키)를 사용합니다.
- 위임 작업을 위해 짧은 수명·범위가 제한된 토큰을 발행하고, 장기 비밀을 재사용하지 않습니다.
- OAuth 토큰 교환 / 위임 체인 패턴(RFC 8693)이 잘 작동합니다.
- 정책 검사를 MCP 서버, 게이트웨이 또는 엣지 프록시에서 수행합니다:
- “이 에이전트는 이슈를 읽을 수 있다”
- “저 에이전트는 PR을 열 수 있다”
- “승인된 에이전트만 배포를 트리거할 수 있다”
- “프로덕션 작업은 인간 승인 필요”
- 맞춤형 솔루션을 만들기보다 기존 정책 엔진(예: OPA)을 활용합니다.
- 파괴적인 작업(삭제, 배포, 회전, 게시, 청구 등)은 특별히 취급하고 명시적인 승인을 요구합니다.
- 전체 위임 체인을 캡처하는 감사 로그를 유지하여 사후 포렌식에 활용합니다.
Resources
- MCP 서버 점검
- Agent audit scanner:
npx @authora/agent-audit(코드베이스를 스캔합니다) - Verified badge for agents
- Curated list of agent‑security resources
이것들은 나머지를 직접 구축하더라도 유용한 시작점입니다.
마무리 생각
큰 변화는 간단합니다: 에이전트를 “기능”으로 생각하는 것을 멈추고, 정체성을 가진 워크로드처럼 다루세요. 그렇게 하면 다중 에이전트 시스템을 신비로운 것이 아니라 관리 가능하게 만들 수 있습니다.