단일 에이전트가 위험한 행동을 할 때 감사(audit) 문제는 작습니다. 하나의 실행(run), 하나의 도구 호출 세트(tool calls), 하나의 영수증 스트림(receipt stream), 그리고 누가, 무엇을, 왜 했는지 물어볼 수 있는 한 곳만 있기 때문입니다.

하지만 에이전트 팀(team)이 동일한 작업을 수행할 때, 감사 문제는 갑자기 훨씬 어려워지며, 가장 흔한 반응은 모든 것을 공유 로그로 붙이는 것입니다. 하지만 이는 보통 잘못된 답변입니다.

다중 에이전트 실행에서 가장 먼저 깨지는 것

저희의 작업에서 가장 먼저 문제가 되는 것은 도구의 정확성(tool correctness)이 아닙니다. 바로 인계(handoff) 과정입니다.

구체적으로 설명드리겠습니다: agent A가 티켓을 읽고, 수정 계획을 세우며, 실제 파일 편집은 B가 해야 한다고 결정합니다. 왜냐하면 B가 적절한 도구링(tooling)과 더 제한적인 권한 범위(permission scope)를 가지고 있기 때문입니다. A는 B에게 편집을 요청하고, B가 이를 수행합니다. 사용자가 다음 날 아침에 일어나 PR을 보고

• 부모 실행 ID (Parent run id) 및 자식 실행 ID (child run id)
• 부모가 자식에게 전달한 정확한 작업 문자열 (요약이 아닌 실제 프롬프트 (prompt))
• 자식이 상속받은 스코프 (scope) 객체와 자식이 실제로 사용한 스코프 객체의 비교 (종종 다르며, 이 차이가 감사 지점 (audit point)이 됨)
• 자식이 행동을 수행하기 위해 사용한 자격 증명 신원 (에이전트별 서비스 계정, 스코프가 지정된 OAuth 토큰, 휘발성 키 등 런타임이 지원하는 방식)
• 위임(delegation) 시점의 부모의 추론 경로 (reasoning trail)에 대한 포인터. 이를 통해 검토자는 부모가 이 작업을 위해 왜 이 자식을 선택했는지 당시의 생각을 확인할 수 있음
• 인계 (handoff) 과정에서 내려진 정책 결정 사항의 짧은 목록: 자식의 스코프가 부모보다 좁았는가? 해당 작업이 되돌릴 수 있는(reversible) 것이었는가? 인계 자체에 귀하의 티어 규칙에 따른 인간의 승인이 필요했는가?

핵심 아이디어는 인계 (handoff)가 두 개의 별개 세션 사이의 '이음새 (seam)'이며, 이 이음새는 그 자체의 기록을 가질 가치가 있다는 것입니다. 공유 추적 기록 (shared trace)만 있다면 이 이음새는 보이지 않게 됩니다.

여기서 하위 에이전트별 세션 신원이 중요한 이유

이는 우리가 어제 작성했던 에이전트별 세션 신원 (per-agent session identity) 패턴을 직접적으로 확장한 것입니다. 만약 모든 하위 에이전트가 자신만의 자격 증명, 자신만의 스코프 객체, 그리고 자신만의 영수증 스트림을 가지고 있다면, 인계 (handoff)는 이러한 신원들이 '명시적으로' 연결되는 순간이 됩니다 — 부모 실행 ID, 자식 실행 ID, 상속된 스코프, 실제 스코프와 같은 것들 말입니다. 이러한 관계가 사후에 체인을 재구성할 수 있게 해줍니다.

만약 하위 에이전트들이 단일 자격 증명과 단일 스코프를 공유한다면, 누구의 행동이 어떤 부작용 (side effect)을 일으켰는지 구분할 수 없습니다. 단지 "에이전트가 수행했다"라고만 알 수 있을 뿐이며, 이는 감사 추적 (audit trail)을 조사하기 어려운 하나의 거대한 덩어리로 붕괴시킵니다.

가드 (guard)와 함께 배치되는 위치

도구 호출 (tool-call) 경계에서 실행되는 정책 가드 (policy guard)는 여전히 할 일이 남아 있습니다. 인계 영수증 (handoff receipt)은 도구 호출 영수증 (tool-call receipts)을 대체하는 것이 아닙니다. 이들은 서로 다른 계층입니다:

• 도구 호출 영수증 (Tool-call receipt): 어떤 기능 (capability)이, 어떤 대상 (target)에 대해, 어떤 인자 (arguments)로 호출되었는지, 그리고 정책 결정 (policy decision)은 무엇이었는지에 대한 정보.
• 인계 영수증 (Handoff receipt): 어떤 하위 에이전트 (sub-agent)가, 어떤 범위 (scope)로, 어떤 부모 작업 (parent task)의 어느 부분을 충족하기 위해 생성되거나 호출되었는지에 대한 정보.

도구 호출만을 보는 가드 (guard)는 "이 MCP 호출이 승인되었는가?"라는 질문에는 답할 수 있지만, "왜 이 하위 에이전트가 애초에 이 호출을 할 수 있도록 허용되었는가?"라는 질문에는 답할 수 없습니다. 두 번째 질문이야말로 다중 에이전트 시스템 (multi-agent systems)에서 가장 흥미로운 실패들이 발생하는 지점입니다. 예를 들어, 부모의 컨텍스트 (context) 내 프롬프트 인젝션 (prompt injection)이 자식의 도구 호출을 오염시키거나, 자식이 할당받은 것보다 더 넓은 범위를 조용히 사용하는 범위 드리프트 (scope drift), 그리고 부모가 평가할 컨텍스트조차 갖추지 못한 상태에서 무언가를 "승인"해버리는 승인 연극 (approval theater) 같은 사례들입니다.

분기(fork)가 필요 없는 시작 패턴

이 방식의 가치를 얻기 위해 완전한 다중 에이전트 런타임 (multi-agent runtime)을 구축할 필요는 없습니다. 실용적인 시작점은 다음과 같습니다:

• 모든 하위 에이전트 (sub-agent)에 검색 가능한 안정적인 ID를 부여합니다.
• 하위 에이전트가 생성되거나 호출될 때, 첫 번째 도구 호출이 이루어지기 전에 하나의 인계 기록 (handoff record)을 작성합니다.
• 하위 에이전트가 종료되면, 부모 실행 ID (parent run id)와 그 결과로 발생한 부수 효과 (side effects)를 가리키는 종료 기록 (close-out record)을 작성합니다.
• 인계 기록을 실행 이력 (run history) 내의 일급 아티팩트 (first-class artifact)로 취급합니다. 이를 grep으로 검색 가능하게 만들고, 실행 후 검토 체크리스트 (post-run review checklist)의 일부로 만드세요.

이것이 화려하지는 않지만, "어딘가에 공유 로그가 있다"와 "누가 무엇을 했는지 답할 수 있다" 사이의 결정적인 차이를 만듭니다.

우리가 여전히 고민 중인 열린 질문

인계 기록 (handoff record)은 어디에서 생성되어야 할까요? 세 가지 가능한 장소는 다음과 같습니다:

• 오케스트레이션(orchestrating)을 담당하는 부모가 계획 출력 (planning output)의 일부로 생성.
• 하위 에이전트를 호스팅하는 런타임 (runtime)이 하위 에이전트가 생성되는 시점에 생성.
• 부모와 자식 모두가 등록하는 공유 제어 평면 (shared control plane)에서 생성.

우리는 현재 런타임 (runtime) 쪽으로 기울고 있습니다. 왜냐하면 런타임은 이음매 (seam)의 양쪽 측면을 실제로 모두 알고 있는 유일한 장소이며, 하위 에이전트 (sub-agent)별 자격 증명 (credential) 및 범위 분리 (scope separation)를 강제하기에 자연스러운 장소이기 때문입니다. 오케스트레이션 (orchestrating)을 담당하는 부모는 인계 (handoff) 과정을 설명할 수는 있지만, 부모가 신뢰할 수 있는 유일한 원천 (authoritative source of truth)이 되어서는 안 됩니다. 그렇게 될 경우 프롬프트 인젝션 (prompt injection)의 위험이 따릅니다.

만약 이 방식이 실제 운영 환경 (production)에서 잘 작동하는 것을 보셨다면, 귀하의 스택 (stack)에서 인계 기록 (handoff record)이 어디에 위치하는지 궁금합니다.

공지: 이 포스트는 Armorer Labs의 글입니다. 우리는 귀하의 머신이나 서버에서 실행되는 AI 에이전트용 로컬 제어 평면 (local control plane)인 Armorer와, 도구 호출 (tool-call) 경계에서 정책을 실행하는 Rust 기반 스캐너인 Armorer Guard를 구축합니다. 위에서 언급한 인계 영수증 (handoff-receipt) 패턴은 우리가 내부적으로 사용하는 것과 동일한 형태이지만, 이 포스트는 제품 발표라기보다는 운영자 수준의 가이드입니다. 여기에 포함된 내용은 벤치마크, 고객 수 또는 가용성에 대한 주장과는 무관합니다.