에이전트 신뢰 격차 (The Agentic Trust Gap): 브레이크 없는 엔진을 만들고 있다

이런 시나리오를 상상해 보세요. 새벽 3시입니다. 당신의 CFO가 전사 회의에서 자랑스럽게 발표했던 그 AI 에이전트가 6시간째 작동 중입니다. 에이전트는 일상적인 작업을 마치고, 데이터를 교차 참조한 뒤, 이틀 전 회계 시스템에서 조용히 업데이트된 벤더 계좌로 82,000달러를 송금합니다.

아침이 되면 돈은 사라져 있습니다. 그리고 아무도 감사관에게 누가 이 송금을 승인했는지 말할 수 없습니다.

아무도 승인하지 않았기 때문이 아닙니다. 승인 자체가 당신이 제어하는 시스템 내의 로그 항목이었고, 거래를 실행한 바로 그 에이전트에 의해 작성되었으며, 여기서 "승인"이란 정책 엔진 (policy engine)이 아무도 보지 못한 새벽 3시의 결정에 대해 "예"라고 답했음을 의미하기 때문입니다.

이것이 바로 에이전트 신뢰 격차 (Agentic Trust Gap)입니다. 그리고 이것은 우리 세대의 결정적인 보안 문제입니다.

50년 동안, 보안은 잘못된 질문에 답해왔다

지난 반세기 동안의 모든 주요 보안 기본 요소 (security primitive)는 단 하나의 질문에 답하기 위해 구축되었습니다: 누가 들어올 수 있는가?

방화벽 (Firewalls)은 권한이 없는 IP를 차단했습니다. OAuth는 문 앞에서 인간의 신원을 확인했습니다. 제로 트러스트 (Zero-trust)는 그 경계를 외부로 확장했습니다. 다요소 인증 (Multi-factor authentication)은 잠금 장치를 강화했습니다.

이 모든 것들은 _이 엔티티 (entity)는 누구이며, 이곳에 머무는 것이 허용되었는가?_라는 질문에 답하기 위해 아름답게 설계되었습니다.

하지만 소프트웨어의 지배적인 사용자는 더 이상 인간이 아닙니다.

자율적인 AI 에이전트 (Autonomous AI agents)는 코드를 작성하고, 도구를 호출하며, 운영 시스템을 즉석에서 변경합니다. 그들은 단순히 인증을 받고 조용히 앉아 있는 것이 아닙니다. 그들은 행동합니다. 그리고 에이전트가 기록 삭제, 자금 이동, 구성 변경과 같이 되돌릴 수 없는 행동을 취할 때, 전통적인 보안은 이에 대해 유용한 말을 해줄 수 있는 것이 아무것도 없습니다.

당신의 OAuth 서버는 에이전트가 유효한 토큰을 가지고 있다는 사실을 확인했을 뿐입니다.

특정 인간이 해당 구체적인 행동을 승인했는지에 대해서는 전혀 알지 못합니다.

아무도 답할 수 없는 질문

지금 당장 AI 에이전트를 도입하고 있는 기업의 CISO (정보보호최고책임자) 회의에 들어가서 이렇게 물어보십시오. "만약 내일 여러분의 에이전트가 파괴적인 행동을 한다면 — 즉, 돈을 잘못된 계좌로 송금하거나, 운영 중인 데이터베이스 테이블을 삭제하거나, 데이터를 잘못된 엔드포인트로 유출한다면 — 특정 인간이 해당 구체적인 행동을 승인했다는 암호학적 증거 (cryptographic proof)를 제시할 수 있습니까?"

회의실은 정적에 휩싸일 것입니다.

그들이 그 문제를 생각해 보지 않았기 때문이 아닙니다. 정직한 답변이 "아니오"이기 때문입니다.

그들에게는 로그 (logs)가 있습니다. 감사 추적 (audit trails)도 있습니다. 인간의 감독 (human oversight)이라는 _원칙_을 신중한 언어로 기술한 정책 문서와 거버넌스 프레임워크 (governance frameworks), 그리고 NIST AI RMF 매핑 (mappings)도 있습니다.

하지만 로그는 증언일 뿐입니다. 로그는 시스템이 무엇이 일어났다고 말하는지를 기술합니다. 데이터베이스 접근 권한이 있는 누구라도 로그를 수정할 수 있습니다. 로그는 운영자를 신뢰할 것을 요구합니다.

그들에게 부족한 것은 바로 **증거 (evidence)**입니다. 특정 인간이 특정 행동을 실행하기 전에, 그 행동을 확인하고, 이해하고, 승인했다는 암호학적이고 오프라인에서 검증 가능한 (offline-verifiable) 증거 말입니다. 이를 생성한 시스템이 침해되더라도 살아남을 수 있는 증거가 필요합니다.

이 격차로 인해 수십억 달러가 손실되고 있습니다

충분한 주목을 받지 못하고 있는 비즈니스 현실은 다음과 같습니다.

기업의 AI 예산은 성능 때문에 억제되고 있는 것이 아닙니다. ChatGPT 수준의 성능은 2년 전에 이미 등장했습니다. 모델들은 놀랍습니다. 에이전트는 실재합니다.

예산이 억제되고 있는 이유는 감사인의 질문에 답할 수 없는 컴플라이언스 (compliance) 팀 때문입니다. "누가 이 행동을 승인했습니까? 그리고 그것을 증명할 수 있습니까?"

제가 대화하는 모든 CISO는 동일한 대화의 변형된 형태를 겪고 있습니다. 엔지니어링 팀은 실제 행동을 수행하는 에이전트를 배포하고 싶어 합니다. 컴플라이언스 팀은 감사 추적을 원합니다. 법무 팀은 책임 소재를 입증할 증거를 원합니다. 하지만 에이전트 행동을 위한 보안 기본 요소 (security primitives)가 아직 존재하지 않기 때문에 아무도 그들에게 필요한 것을 줄 수 없습니다.

결과적으로: 수십억 달러 규모의 AI 예산이 누군가 브레이크를 만들어 주기를 기다리며 에스크로 (escrow)에 묶여 있습니다.

권한 승인 영수증 (Authorization receipts): 누락되었던 기본 요소

EMILIA 프로토콜 (EMILIA Protocol) 이면에 담긴 통찰은 일단 깨닫고 나면 매우 단순합니다.

OAuth와 IAM은 행위자(actor)가 누구인지를 알려줍니다. 하지만 정작 누락된 것은, 행위가 일어나는 순간, 행위의 정확한 파라미터(parameters)에 결합되어, 부인할 수 없는 특정 개인에 의해 서명된, 행위자가 무엇을 수행하도록 권한을 부여받았는지에 대한 표준입니다.

우리는 이것을 **권한 영수증 (authorization receipts)**이라고 부릅니다.

권한 영수증은 암호학적으로 서명된 기록입니다. 이는 운영자를 신뢰하지 않고도, 오픈 소스 코드를 통해, 누구나 오프라인에서 검증할 수 있으며 다음 질문에 답합니다:

누가 이 행위를 시작했는가?
행위의 정확한 내용은 무엇인가 (표준화된(canonical), 해시 고정된(hash-pinned) 파라미터)?
누가 승인했는가 (서비스 계정이나 정책 엔진이 아닌, 이름이 명시된 개인 또는 기기에 결합된 패스키(passkey))?
실행 시점을 기준으로 승인이 언제 이루어졌는가?
이 영수증이 진본인가, 아니면 변조되었는가?

이것들은 감사인(auditor), 규제 기관(regulator), 또는 사고 대응자(incident responder)가 답을 얻어야 하는 다섯 가지 질문입니다. 권한 영수증은 운영자에 대한 신뢰 없이도, 오픈 소스 코드를 통해 오프라인에서 이 다섯 가지 질문 모두에 답합니다.

실제 작동 방식

EMILIA 프로토콜은 에이전트의 도구 호출(tool calls)을 위한 신흥 표준인 **모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)**에 연결됩니다. 코드 재작성이 필요하지 않습니다.

에이전트가 파괴적인 도구(destructive tool)—파일 삭제, 자금 이동, 운영 기록 수정 등—를 호출하려고 할 때, EMILIA는 MCP 경계에서 이를 가로채어 4단계의 의식(ceremony)을 수행합니다:

1단계: 결정 (Decision). 해시 고정된(hash-pinned) 정책이 행위를 평가합니다: 허용(allow), 서명 후 허용(allow-with-signoff), 또는 거부(deny). 또한 운영 환경에서 아무것도 변경하지 않고 차단되었을 사항을 보고만 하는 관찰 모드(observe mode)도 있습니다. 이는 정책을 강제하기 전에 책임 범위(accountability surface)를 매핑할 수 있는 리스크 제로의 방법입니다.

2단계: 승인 (Signoff, 필요한 경우). 고위험 행위의 경우, 정책은 이름이 명시된 개인의 승인을 요구합니다. 사람은 의역되지 않은 정확한 행위(표준화된 파라미터)를 확인하고, 자신의 기기에서 Face ID 또는 Touch ID를 사용하여 승인합니다. 그들이 보는 것이 곧 그들이 서명하는 것이며, 승인된 내용이 그대로 실행됩니다.

3단계: 영수증 (Receipt). 결과물은 서명된 승인 영수증 (signed authorization receipt)입니다. 누구나 서버에 홈 호출 (calling home)을 하지 않고도 오프라인에서, 브라우저에서, 또는 오픈 소스 검증기 (open-source verifier)를 사용하여 이를 검증할 수 있습니다. 영수증을 변조하면 구조적으로 검증에 실패합니다.

4단계: 선택 사항, 앵커링 (Anchor it). 공개 타임스탬핑 (public timestamping)이 중요한 워크플로우의 경우, 영수증을 체인으로 연결하고 앵커링 (anchored)할 수 있습니다. 하지만 핵심 기능에는 블록체인 (blockchain)이 필요하지 않습니다.

지금 바로 시도해 보세요:

npx @emilia-protocol/issue demo

이 명령은 API 키 없이 실제 영수증을 발행하고 오프라인에서 이를 검증합니다. 약 10초 정도 소요됩니다. 이것이 전체 프리미티브 (primitive)입니다.

IETF 기준: 세 가지 독립적인 구현

진정한 표준과 영리한 라이브러리를 구분하는 한 가지는 상호 운용 가능한 여러 개의 독립적인 구현체입니다.

EMILIA Protocol은 JavaScript, Python, Go로 구성된 **세 가지 레퍼런스 검증기 (reference verifiers)**를 제공하며, 이는 매 푸시 (push)마다 동일한 적대적 준수 벡터 (adversarial conformance vectors)에 대해 일치함이 증명되었습니다. 이것이 바로 IETF 기준입니다. 또한 이 프로토콜이 IETF 인터넷 초안 (Internet-Draft, draft-schrock-ep-authorization-receipts)으로 추적되는 이유이기도 합니다.

정형 모델 (formal models)은 또 다른 계층을 추가합니다. CI에서 실행되는 반례가 없는 26개의 TLA+ 안전성 속성 (safety properties)과 22개의 Alloy 관계 어설션 (relational assertions)이 포함되어 있습니다. 이는 단순히 코드를 테스트하는 것이 아니라, 프로토콜이 할 수 있는 것과 할 수 없는 것에 대한 속성을 증명합니다.

이것이 빌더들에게 제공하는 가능성

에이전트 (agents)를 구축하고 있다면, 아마 이미 이 벽에 부딪혀 보았을 것입니다. 당신은 실제로 유용하고 실질적인 행동을 취하는 에이전트를 원합니다. 하지만 기업 고객이 에이전트가 그들의 운영 시스템 (production systems)을 건드리도록 허용하려 할 때마다, 대화는 항상 같은 지점에서 멈춥니다: "사람이 이것을 승인했는지 알아야 합니다."

EMILIA는 30초 만에 답을 제공합니다. MCP 서버를 설치하세요. 정책 (policy)을 정의하세요. 고객에게 전달하세요. 에이전트가 되돌릴 수 없는 작업을 시도하면, 의식 (ceremony)이 실행되고 영수증이 생성됩니다. 고객의 감사자 (auditor)는 오픈 소스 코드로 이를 검증할 수 있습니다.

이제 책임 계층 (accountability layer)을 처음부터 구축할 필요가 없습니다. 그것은 하나의 라이브러리입니다.

# Claude / Cursor / Cline
npx -y @emilia-protocol/mcp-server

...

이것이 생태계에 가져다줄 변화

장기적인 관점은 더 거대합니다. 소프트웨어의 모든 플랫폼 전환에는 새로운 보안 프리미티브 (security primitive)가 필요했습니다.

웹에는 SSL/HTTPS가 필요했습니다. 이것이 영리해서가 아니라, 상거래를 위해서는 통신이 비공개라는 증명이 필요했기 때문입니다.
클라우드에는 IAM과 Okta가 필요했습니다. 신원 확인 (identity) 자체가 흥미로워서가 아니라, 기업용 배포를 위해서는 권한 부여 (authorization)에 대한 증명이 필요했기 때문입니다.
에이전트 경제 (agent economy)에는 **행위 수준의 신뢰 (action-level trust)**가 필요합니다. 의식 (ceremony)이 우아해서가 아니라, 규제 산업에서는 인간의 권한 부여 (human authorization)에 대한 증명 없이는 에이전트를 배포하지 않을 것이기 때문입니다.

EMILIA는 오픈 표준 (open standard)입니다. 왜냐하면 이 프리미티브의 가치는 채택률과 함께 성장하기 때문입니다. 이를 배포하는 모든 기업은 어떤 검증자 (verifier)라도 확인할 수 있는 영수증을 생성합니다. 모든 검증자는 모든 발행자 (issuer)와 호환됩니다. 해자 (moat)가 되는 것은 벤더 (vendor)가 아니라 표준 (standard)입니다.

SSL이 작동했던 방식이 바로 이렇습니다. 이것이 작동하는 방식입니다.

책임 격차 (accountability gap)는 좁혀지고 있습니다 — 문제는 누가 이를 채울 것인가입니다

NIST AI 위험 관리 프레임워크 (AI Risk Management Framework)는 이미 인간의 감독 (human oversight)을 권장 사항에서 필수 요구 사항으로 이동시키고 있습니다. EU AI 법 (EU AI Act)은 고위험 AI 결정에 대해 인간의 검토를 의무화합니다. 지난 18개월 동안 모든 G7 정부의 행정 명령은 동일한 주제로 수렴되었습니다. 즉, 중대한 결정에 따라 행동하는 자율 AI 시스템에는 감사 가능한 인간의 권한 부여 (human authorization)가 필요하다는 것입니다.

암호학적으로, 상호 운용 가능하게, 그리고 오프라인에서 검증 가능하게 이러한 요구 사항을 강제할 프리미티브 (primitives)는 아직 표준으로서 존재하지 않습니다.

그것이 바로 우리가 구축하고 있는 것입니다.

시도해 보기

30초 오프라인 데모 (30-second offline demo): npx @emilia-protocol/issue demo
Face ID 승인 데모 (Face ID signoff demo): 본인의 기기에서 8만 2천 달러의 송금을 승인한 다음, 이를 위조하여 실패하는 과정을 지켜보세요
브라우저 내 검증기 (In-browser verifier): 어떤 영수증이든 붙여넣어 브라우저에서 오프라인으로 검증하세요
MCP 서버 (MCP server): npx -y @emilia-protocol/mcp-server
GitHub: Apache-2.0, 3,672개 이상의 테스트 완료, 형식 검증 (formally verified)됨
IETF 인터넷 초안 (IETF Internet-Draft): 우리가 지향하며 구축하고 있는 표준

실제 행동을 수행하는 에이전트를 구축하고 있거나, 감사인의 질문에 답해야 하는 CISO(정보보호최고책임자)라면 저희와 이야기 나누고 싶습니다. 저희는 비용 부담이 없는 관찰 모드 (observe-mode) 파일럿을 운영하고 있습니다. 조달 절차가 필요 없으며, 운영 환경(production)의 변경 없이도 귀사의 책임 영역 (accountability surface)에 대한 지도를 제공합니다.

Discord · team@emiliaprotocol.ai

EMILIA Protocol은 Apache-2.0 오픈 소스입니다. 핵심 기술은 공개된 IETF 인터넷 초안 (Internet-Draft)입니다. 관리형 제품 (managed product)은 우리가 표준을 지원하기 위한 자금원입니다. github.com/emiliaprotocol/emilia-protocol에서 공개적으로 구축되고 있습니다.