다중 에이전트 AI 시스템을 위한 제로 트러스트

신원(identity)만으로는 충분하지 않은 이유: 자율 에이전트가 작업을 위임하고, 도구를 호출하며, 실제 세계의 영향을 생성할 수 있을 때

SGAEIA 연구 시리즈 - 기사 3

Aridio Silva

독립 연구원, 브라질

SGAEIA(Secure Governed Autonomous Edge Intelligence Architecture) 제작자

ORCID: 0009-0008-2411-6995

다중 에이전트 AI 시스템을 위한 제로 트러스트. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

목차

• 인증 후에도 지속되는 권한 문제
• 제로 트러스트는 위치에서 행동으로 이동한다
• 위임은 신뢰가 아닌 제한된 권한을 전송한다
• 도구 기능이 곧 권한은 아니다
• 지속적인 신원이 지속적인 권한을 의미하지 않는다
• 강제(enforcement)를 모델의 재량권 밖에 유지해야 한다
• 증거와 취소는 권한의 일부이다
• 엣지 자율성은 권한을 확장해서는 안 된다
• 공개 SGAEIA 권한 모델
• 실용적인 엔지니어링 검토
• 제한 사항
• 결론
• 참고 문헌

이 개발자 중심의 에디션은 공개 연구 논문을 실질적인 아키텍처 및 보안 토론에 맞게 조정했습니다. 예시는 실험 결과가 아닌 교육용입니다. 이 글은 공개된 연구 주장을 유지하며, 비공개 SGAEIA 메커니즘, 스키마 또는 구현 세부 사항을 공개하지 않습니다.

인증 후에도 지속되는 권한 문제

한 사람이 에이전트 A에게 고객 보고서 작성을 요청한다고 상상해 봅시다. 에이전트 A는 데이터 검색 작업을 에이전트 B에게 위임합니다. 에이전트 B는 파일 도구를 발견하고, 이 도구가 API를 호출하며, 이는 요청된 기록과 관련 없는 기밀 데이터를 모두 보유한 서비스에 도달합니다. 모든 구성 요소가 설계대로 작동할 수 있으며, 인간은 올바르게 인증되었을 수도 있습니다. 보안 실패는 초기 인증이 체인 내의 모든 후속 선택에 대한 권한으로 간주될 때 발생합니다.

이것이 다중 에이전트 AI를 위한 핵심적인 제로 트러스트(Zero Trust) 문제입니다. 워크플로우는 합법적인 사용자로부터 시작하여 개별적으로 합법적인 구성 요소를 포함할 수 있지만, 권한이 확장되거나 상속되거나 원래 목적 외에 적용되었기 때문에 여전히 승인되지 않은 결과를 산출할 수 있습니다 [1][2]. 엔지니어링 팀에게 실질적인 질문은 단순히 “어떤 ID가 인증했는가?”가 아닙니다. 또한 다음과 같습니다: 현재의 ID, 위임된 권한, 목적, 정책, 시간, 그리고 맥락 하에서 이 특정 액션이 이 특정 리소스에 대해 허용되는가?

본 기사의 논지는 에이전트들이 협업한다고 해서 신뢰가 단순히 전파되어서는 안 된다는 것입니다. ID는 명시적이어야 하고, 권한은 경계 지어져야 하며, 정책은 외부적으로 강제 가능해야 하고, 결정은 증거 기반이어야 하며, 파생된 권한은 취소 가능해야 합니다.

Figure 1 - The Multi-Agent Trust Problem. Authentication at the beginning of a workflow must not become implicit downstream trust.
그림 1 - 다중 에이전트 신뢰 문제(The Multi-Agent Trust Problem). © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

제로 트러스트는 위치에서 액션으로 이동한다

“절대 신뢰하지 말고, 항상 검증하라”는 유용한 간결한 표현이지만, 제로 트러스트가 모든 구성 요소를 영구적으로 악의적이라고 취급한다는 의미는 아닙니다. 이는 근접성, 친숙함, 소유권 또는 이전 결정을 무기한적인 신뢰로 전환하는 것을 거부한다는 의미입니다. 기존의 요청 경로에서는 정책 결정이 리소스에 대한 접근을 통제할 수 있습니다. 하지만 에이전트 기반(agentic) 경로에서는 시스템이 누가 액션을 선택했는지, 그 에이전트가 누구의 권한을 대표하는지, 그 권한이 위임되었는지, 그리고 요청된 효과가 승인된 목적 내에 남아 있는지까지 고려해야 합니다 [1][2].

에이전트는 단순히 사용자나 서비스의 신원(identity)만을 의미하지 않습니다. 자연어 의도(natural-language intent)를 일련의 작업(sequence of operations)으로 변환하는 의사결정 중개자일 수 있습니다. 올바른 신원은 누가 또는 무엇이 행동하고 있는지를 답할 뿐, 그 결과로 발생하는 작업이 허용되는지 여부를 답하지는 않습니다. NIST와 NCCoE는 소프트웨어 및 AI 에이전트의 신원과 권한 부여(authorization)에 대해 식별(identification), 인증(authentication), 권한 부여(authorization), 감사(auditing), 그리고 책임 소재(accountable principals)를 관련 있지만 구별되는 관심사로 다룹니다 [4][5].

첫 번째 설계 원칙은 다음과 같이 직접적으로 이어집니다:

인증(Authentication)은 신원을 확립합니다. 권한 부여(Authorization)는 특정 작업에 대한 허가(permission)를 확립합니다. 어느 쪽도 지속적인 신뢰(continuing trust)를 확립하지 못합니다.

개발자에게 이것은 효과가 발생할 수 있는 경계 지점에서 요청된 작업을 평가해야 함을 의미합니다. 성공적인 로그인, 유효한 토큰, 또는 신뢰하는 네트워크 세그먼트가 모든 다운스트림 작업에 대해 암묵적으로 허용 결정이 되어서는 안 됩니다.

위임(Delegation)은 신뢰가 아닌 제한된 권한을 전송한다

다중 에이전트 시스템에서는 위임이 필수적입니다. 계획 에이전트는 다른 에이전트에게 기록 검색, 데이터 분석 또는 전문 도구 작동을 요청할 수 있습니다. 보안 목표는 위임을 막는 것이 아니라, 그것이 암묵적으로 권한 범위를 넓히지 않도록 보장하는 것입니다. 인증된 위임에 대한 연구는 에이전트 시스템이 주체(principals), 위임자(delegates), 권한(permissions), 그리고 책임 소재를 연결하는 명시적이고 감사 가능한 관계를 필요로 한다고 주장합니다 [3].

만약 Agent A가 권한 집합 $\alpha$를 가지고 있고, 그중 부분집합 $\beta$를 Agent B에게 위임한다고 가정해 봅시다. 의도된 관계는 $\beta \subseteq \alpha$입니다: 즉, 수임자는 위임하는 주체가 가진 것보다 더 많은 권한을 받지 않으며, 오직 작업에 필요한 부분집합만을 받습니다. 또한 이 관계는 자원(resource), 작업(action), 목적(purpose), 시간(time), 상황(context), 그리고 추가적인 위임이 허용되는지 여부와 같은 제약 조건도 필요로 합니다. 이러한 기호들은 교육적인 SGAEIA 형식화이며, NIST가 명시한 방정식은 아닙니다.

Figure 2 - Trust Must Not Propagate With Delegation. Delegation transfers an explicitly bounded subset of authority, not unrelated permissions or the trust state of the delegating principal.
그림 2 - 위임 시 신뢰는 전파되어서는 안 된다 (Trust Must Not Propagate With Delegation). © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

고객 기록을 읽고 내부 보고서를 생성할 권한이 있는 에이전트를 가정해 봅시다. 유효한 위임은 두 번째 에이전트가 지정된 세트의 기록을 10분 동안 읽도록 허용할 수 있습니다. 하지만 삭제, 외부 공유, 관련 없는 고객 접근, 또는 알 수 없는 제3자에게의 위임을 자동으로 허용해서는 안 됩니다. Agent B를 호출하는 것은 Agent A가 도움을 요청했다는 증거일 뿐이며, B가 선택한 모든 작업이 승인되었다는 증거는 아닙니다.

구현 검토를 위해서는 권한 출처(authority provenance)를 보존해야 합니다. 즉, 누가 누구에게 어떤 목적과 제약 조건 하에 무엇을 부여했는지 기록해야 합니다. 또한 특정 부여로부터 파생된 권한과 위임자가 독립적으로 보유하는 권한을 구별해야 합니다. 이러한 구분이 없다면, 하나의 부여를 취소하는 것이 의존적인 접근을 종료하지 못하거나 관련 없는 합법적인 권한까지 잘못 제거할 수 있습니다.

도구 기능은 권한이 아니다 (Tool capability is not permission)

에이전트 프레임워크는 일반적으로 모델이 작업을 요청할 수 있도록 도구를 노출합니다. 도구를 발견하거나 호출하는 기술적 능력은 '기능(capability)'입니다. 반면, '권한(authorization)'은 특정 인수와 효과를 가진 특정 호출이 진행될 수 있는지 여부에 대한 별도의 결정 사항입니다. LLM 에이전트 프레임워크에서 발생하는 혼란스러운 대리인 실패(confused-deputy failures)에 대한 연구는 모델이 부작용을 일으키는 호출을 발생시킬 수 있을 때 기능 게이팅만으로는 불충분한 이유를 보여줍니다 [8].

에이전트가 보고서 하나를 읽어야 하므로 파일 도구가 사용 가능하다고 가정해 봅시다. 도구의 가용성이 에이전트에게 해당 보고서를 덮어쓰거나, 관련 없는 디렉터리를 열거하거나, 권한을 변경하거나, 데이터를 업로드할 수 있는 권한을 부여하는 것은 아닙니다. 이러한 구분은 결제(payment), 메시징, 인프라스트럭처, 데이터베이스, 산업 제어 도구에도 동일하게 적용됩니다. 모델에게 보여지는 스키마는 무엇을 요청할 수 있는지 설명할 뿐이며, 실제로 실행될 수 있는 것의 강제 경계가 되어서는 안 됩니다.

아키텍처 규칙은 간단합니다:

모델이 행동을 제안할 수는 있지만, 보안 경계가 그 구체적인 행동이 허용되는지 여부를 결정해야 합니다.

행위자(actor), 위임된 권한(delegated authority), 연산(operation), 인자(arguments), 대상 리소스(target resource), 목적(purpose), 시간(time), 그리고 관련 컨텍스트를 평가해야 합니다. 기본 허용(default allow), 공유 자격 증명(shared credentials), 광범위한 도구 노출을 편리한 구현 세부 사항이 아닌 명시적인 위험으로 다루어야 합니다. OWASP는 에이전트 시스템의 주요 위험 클래스로 도구 오용(tool misuse), 신원 및 권한 남용(identity and privilege abuse), 안전하지 않은 에이전트 간 통신(insecure inter-agent communication), 연쇄적 실패(cascading failures), 그리고 악성 에이전트(rogue agents)를 식별합니다 [6].

지속적인 신원이 지속적인 권한을 의미하지는 않는다

에이전트는 동일한 신원을 유지하면서도 행동할 권리를 잃을 수 있습니다. 작업이 취소되거나, 자격 증명이 손상되거나, 시간 창(time window)이 만료되거나, 정책이 변경되거나, 이상 징후가 감지되거나, 위임하는 주체(delegating principal)의 권한이 박탈될 수 있습니다. 따라서 지속적인 검증은 동일한 인증된 개체가 여전히 존재하는지 여부보다 더 많은 것을 검토해야 합니다. 현재 행동이 현재 조건 하에서도 여전히 합법적인지를 물어야 합니다 [1][4].

Figure 3 - Continuous Authority Verification Loop. Identity and context inform authorization; permitted actions generate evidence; risk evaluation can trigger reauthorization or revocation.
그림 3 - 지속적 권한 검증 루프(Continuous Authority Verification Loop). © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

지속적인 평가(Continuous evaluation)가 모든 무해한 작업마다 인간의 승인 대화창을 통해 중단된다는 의미는 아닙니다. 적절한 제어는 결과와 위험에 따라 달라집니다. 제한된 데이터셋으로부터의 읽기 전용 검색은 짧게 지속되는 정책 결정 하에서 작동할 수 있습니다. 하지만 결제, 배포(deployment), 자격 증명 변경, 외부 메시지 전송 또는 물리적 구동(physical actuation)과 같은 작업은 더 강력한 증거, 더 좁은 권한 부여(narrower grant), 또는 명시적인 승인을 요구할 수 있습니다.

모델의 재량권 밖에 강제 적용 유지하기 (Keep enforcement outside model discretion)

“기밀 파일에 접근하지 마라”라는 프롬프트는 모델의 행동을 안내할 수는 있지만, 접근 제어(access control)를 강제하지는 못합니다. 만약 에이전트가 자격 증명을 보유하고 무제한적인 도구 경로(unrestricted tool path)를 가지고 있다면, 모델은 사실상 자신의 권위를 감시하도록 요청받는 것과 같습니다. 프롬프트 지침은 행동에는 여전히 유용하지만, 보안에 중요한 결정들은 오직 모델이 준수하기로 선택하는 것에만 의존해서는 안 되는 제어(controls)가 필요합니다 [7].

Figure 4 - Zero-Trust Multi-Agent Enforcement Architecture. The agent proposes an action; an external control evaluates identity, authority, policy, and risk before execution.
그림 4 - 제로 트러스트 다중 에이전트 강제 적용 아키텍처(Zero-Trust Multi-Agent Enforcement Architecture). © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

익숙한 정책 결정 지점(Policy Decision Point)과 정책 강제 적용 지점(Policy Enforcement Point)의 구분은 여기서 유용합니다. 결정 구성 요소는 요청이 정책을 충족하는지 여부를 판단하며, 강제 적용 구성 요소는 그 결과로 나온 허용(allow), 거부(deny), 또는 제한된 결정이 실행을 통제하도록 보장합니다. 모델은 자체적인 권위를 만들어내거나 근본적인 도구에 직접 접근할 수 있기 때문에 강제 적용 경로를 우회해서도 안 됩니다.

이러한 분리는 테스트 또한 개선합니다. 팀들은 금지된 인자 조합(prohibited argument combinations)이 거부되는지, 누락된 권위가 안전하게 실패하는지, 만료된 승인이 종료되는지, 그리고 허용된 작업들이 여전히 사용 가능한지를 테스트할 수 있습니다. 이러한 테스트를 통과하는 것은 테스트된 조건 하에서 지정된 제어에 대한 제한적인 주장(limited claim)을 뒷받침할 뿐이며, 보편적인 보안을 증명하는 것은 아닙니다.

증명(Evidence) 및 철회(revocation)는 권한 부여의 일부입니다