컨텍스트 엔지니어링 실패모드 위키

provenance·신뢰등급 — 프로베넌스 역설과 Attested Identity

10 min read

상위: 07_00_MOC

provenance와 신뢰등급 — 출처를 검증하지 않으면 자기보고가 오염을 키운다

07_02-근본원인-권위와-출처-메타데이터-부재에서 다룬 세 가지 빠진 메타데이터 가운데 가장 반직관적이면서 가장 위험한 것이 provenance(출처·내력) 다. 흔히 “에이전트에게 자기 품질을 물어보면 된다”고 생각하지만, 측정 결과는 그 반대를 가리킨다.

1. 프로베넌스 역설 — 자기보고는 랜덤보다 나쁘다

Sunil Prakash(2026, “The Provenance Paradox in Multi-Agent LLM Routing”)는 위임 라우팅에서 나타나는 결정적 실패를 짚는다. 에이전트가 자신의 품질을 자기보고(self-claim)하도록 두면, 라우터는 체계적으로 최악의 에이전트를 선택한다.

“Quality-based routing produces a provenance paradox: it systematically selects the worst delegates, performing worse than random.” — Prakash(2026)

라우팅 방식성능(실제 Claude 모델 테스트)
자기보고 기반(self-claimed)8.90
랜덤 선택9.30
Attested(검증된) 라우팅9.51 (p < 0.001)

자기보고는 랜덤보다도 나쁘다. 원인은 역선택이다. 가장 과대하게 주장하는, 즉 자기인식이 가장 부정확한 에이전트가 가장 자주 선택되기 때문이다. 거의 최적에 도달하는 것은 검증된 라우팅뿐이다.

수치 신뢰도 주의 — 위 정량치(8.90/9.30/9.51, p<0.001)는 단일저자 프리프린트(Prakash, 2026, arXiv:2603.18043)에 근거하며 독립적인 재현 결과는 아직 없다. 따라서 자기보고 < 랜덤 < 검증이라는 방향성 신호로 읽는 편이 안전하고, 절대 수치를 인용할 때는 과신을 경계해야 한다.

“Attested routing achieved near-optimal outcomes (d = 9.51, p < 0.001) across all conditions.” — Prakash(2026)

검증에 드는 오버헤드는 sub-microsecond 수준이라 사실상 무시할 수 있다. 정리하면 출처 검증을 거치지 않은 자기주장은 오히려 오염을 확산시킨다. 위임 계약(delegation contract)은 자기보고가 아니라 명시적 목표·예산·실패정책에 더해 제3자 검증(attestation) 으로 권위를 묶어야 한다.

graph LR
    R["라우터<br/>(위임 결정)"] -->|"자기보고 8.90<br/>최악 선택"| W1["저품질 에이전트<br/>(거짓 자기주장)"]
    R -->|"랜덤 9.30"| W2["임의 에이전트"]
    R -->|"검증 9.51 · p<0.001"| W3["Attested 에이전트<br/>(제3자 검증)"]
    style W1 fill:#FF4444,color:#fff
    style W2 fill:#888888,color:#fff
    style W3 fill:#44AA44,color:#fff
    style R fill:#FF8800,color:#fff

2. 신뢰등급(Trust Level) — 슬롯마다 신뢰를 매긴다

provenance를 실제로 운용하는 형태가 신뢰등급이다. 컨텍스트의 모든 슬롯에 출처 기반 trust 점수를 매기면, 모델은 무엇을 무조건 믿고 무엇을 검역할지를 구조적으로 구분할 수 있다. 4계층 모델(07_08-처방-컨텍스트는-슬롯계약-4계층-모델)의 trust 매핑은 다음과 같다.

슬롯출처신뢰등급취급
불변 시스템 규칙Managed Policy(검증된 배포)5무조건 수용
검증된 사실Attested Identity·Verifier 통과3수용(출처 링크 유지)
작업 가설에이전트 자기생성1spec 대비 검증 후 사용
외부 입력도구 반환·웹 콘텐츠0IPI 검역 후에만 격리 사용

핵심은 하나다. trust 0인 외부 입력을 trust 5인 시스템 규칙과 같은 평면에 두지 않는 것. 이것이 07_02-근본원인-권위와-출처-메타데이터-부재에서 짚은 “평면 컨텍스트” 문제에 대한 직접적인 처방이다.

3. 외부 신뢰 경계 — IPI와 제로 트러스트

trust 0 슬롯이 위험한 까닭은 간접 프롬프트 주입(IPI) 때문이다. AgentSentry(Zhang et al., 2026)는 이를 신뢰 경계의 관점에서 분석한다.

“Attacker-controlled context embedded in tool outputs or retrieved content silently steers agent actions away from user intent.” — Zhang et al.(2026)

도구 반환값이나 검색된 웹 콘텐츠 같은 외부 환경이 신뢰 경계를 넘어와 컨텍스트를 오염시킨다. AgentSentry는 도구 반환 경계에서 counterfactual 재실행으로 공격 진입점을 짚어내, AgentDojo에서 평균 74.55% Utility Under Attack(기존 대비 20.8~33.6%p 개선)을 기록했다. IPI는 프롬프트 튜닝으로는 풀리지 않는 아키텍처 수준 취약점이라, 신뢰 경계와 컨텍스트 격리, 도구 호출 검증으로만 완화할 수 있다.

이 발상을 시스템 차원으로 일반화한 것이 제로 트러스트 에이전트 보안이다. Anthropic은 2026년 5월 제로 트러스트 프레임워크를 발표했다(OpenTools, 2026). 핵심 명제는 다음과 같다.

“Traditional access controls won’t prevent agents from misusing legitimate permissions.” — Anthropic 프레임워크, OpenTools(2026)

전통적 접근 제어로는 에이전트가 정당한 권한을 오용하는 것을 막을 수 없다. 그래서 두 가지를 처방한다. 하나는 작업별 권한 스코핑으로, 한 작업에 인가된 권한은 그 작업이 끝나면 만료된다(역할 기반이 아니라 작업 기반이다). 다른 하나는 암호화 기반 에이전트 신원으로, 배포 출처와 인가된 역량을 검증 가능하게 증명한다.

“Permissions scoped per individual task — an agent authorized for one database query loses that access afterward.” — Anthropic 프레임워크, OpenTools(2026)

출처 주의 — 위 제로 트러스트 내용은 2차 출처(OpenTools)에 기반한다. 실제 운용에서는 Anthropic 원본 문서를 직접 참조하는 편이 좋다.

이는 07_05-메모리계층과-권한-MemGPT-오케스트레이터-워커의 권한 분리와 같은 방향이다. 권한은 정적인 역할이 아니라 검증된 작업 단위로 부여하고 만료해야 한다.

4. 프로토콜 계층의 계약 관점 — A2A Agent Card의 한계

provenance는 프로토콜 차원에서도 아직 미완이다. Ehtesham et al.(2025)의 조사에 따르면 A2A(Google)는 capability 기반의 Agent Card 로 에이전트의 역량과 신원을 선언한다.

“A2A: peer-to-peer task delegation using capability-based Agent Cards, supporting secure and scalable collaboration.” — Ehtesham et al.(2025)

그러나 Agent Card는 선언(declaration)일 뿐 검증(attestation)이 아니다. 한 에이전트가 다른 에이전트의 실제 역량을 어떻게 아는가, 이 역량 협상 문제는 현행 프레임워크 대부분에서 풀리지 않았고, 이것이 곧 1절의 프로베넌스 역설과 직결된다. 선언만 믿으면 자기보고 라우팅과 똑같은 함정에 빠진다.

확인되지 않은 주장 — “2025년 12월 MCP·A2A·ACP·ANP가 모두 Linux Foundation 산하 Agentic AI Foundation으로 이관됐다”는 이야기는 원전에서 직접 확인되지 않으므로 여기서는 단정하지 않는다.

참고문헌

그래프 뷰

백링크