왜 어떤 플랫폼도 AI 에이전트를 위한 중립적 신뢰 계층이 될 수 없는가, 그리고 2026년 8월 2일이 왜 모두의 문제가 되는가

오늘날 배포되는 모든 AI 에이전트 — 이메일을 읽거나, 돈을 옮기거나, API를 호출하거나, 다른 에이전트와 대화하는 것과 관계없이 — 자신이 무엇을 했는지 증명하거나, 허용된 작업만을 수행하도록 강제하거나, 타인에게 자신의 신원을 검증할 수 있는 표준화된 방식 없이 작동합니다.

이것은 이론적인 문제가 아닙니다. 법적인 문제입니다. EU AI Act(유럽연합 AI 법)가 2026년 8월 2일에 전면 시행됩니다. 벌금은 3,500만 유로 또는 전 세계 연간 매출의 7%에 달할 수 있습니다. 유럽 내에서 또는 유럽으로 고위험 AI 시스템을 배포하는 모든 기업은 아마도 현재 갖추지 못했을 세 가지 요소가 필요합니다: 검증 가능한 에이전트 신원 (verifiable agent identity), 강제 가능한 행동 제한 (enforceable behavioral limits), 그리고 변조 불가능한 감사 추적 (tamper-proof audit trail).

시장은 이를 주목했습니다. 지난 90일 동안 Microsoft는 Agent Trust Kit을 출시했습니다. Cisco는 Astrix를 4억 달러에 인수했습니다. Okta는 Agent Identity를 출시했습니다. AWS, Google, Anthropic 모두 네이티브 에이전트 거버넌스 프리미티브 (native agent governance primitives)를 출시했습니다. 수십억 달러의 자금이 이 카테고리의 가치를 입증하고 있습니다.

하지만 그들 중 누구도 이 문제를 해결할 수 없습니다.

아무도 말하지 않는 구조적 문제
스스로에게 물어보십시오: 규제를 받는 기업이 OpenAI 에이전트가 올바르게 행동했는지 독립적으로 검증하기 위해 Microsoft를 신뢰할까요? Google의 에이전트를 감사하기 위해 AWS를 신뢰할까요? GPT의 준수 여부를 인증하기 위해 Anthropic을 신뢰할까요?

이 기업들 모두는 이해 상충 (conflict of interest) 문제를 안고 있습니다. 그들은 플랫폼입니다. 그들은 에이전트, 컴퓨팅 (compute), 프레임워크, 또는 이 세 가지 모두를 판매합니다. 그들에게 경쟁사의 에이전트를 중립적으로 검증해 달라고 요청하는 것은, 감사 법인에게 자신의 모회사를 감사하라고 요청하는 것과 같습니다. 어떤 규제 기관도 이를 수용하지 않습니다. 어떤 기업의 CISO (정보보호최고책임자)도 이에 승인하지 않습니다.

이것은 기능의 공백이 아닙니다. 구조적 불가능성입니다. AI 스택에서 플랫폼을 판매하는 기업은 AI 에이전트를 위한 중립적 신뢰 계층 (neutral trust layer)을 구축할 수 없습니다. 그들이 신뢰할 수 있는 중립성을 제공하려면 자신들에게 수익을 가져다주는 비즈니스를 포기해야 합니다. 그것은 카운터 포지셔닝 (counter-positioning) — 자본이나 엔지니어링으로는 극복할 수 없는 가장 강력한 형태의 경쟁적 해자 (competitive moat)입니다.

Microsoft는 동일한 암호화 프리미티브 (cryptographic primitives)를 출시할 수 있습니다.

그들은 툴킷 (toolkit)을 오픈 소스로 공개할 수도 있습니다. 무료로 제공할 수도 있습니다. 하지만 여전히 중립적일 수는 없습니다. 왜냐하면 중립성은 기능 (feature)이 아니라, 입장 (position)이기 때문입니다.

에이전트에게 실제로 필요한 것 — 그리고 법이 요구하는 것
에이전트용 애플리케이션을 위한 OWASP Top 10 (2025년 12월 발행)은 구체적인 위험 요소들을 정의합니다. EU AI Act (제9조, 12조, 13조, 14조)는 구체적인 법적 요구 사항을 정의합니다. 이들이 실제 운영 환경에서 결여된 요소들과 어떻게 교차하는지는 다음과 같습니다.

1. 에이전트 신원 (Agent Identity) (OWASP: 과도한 권한 (Excessive Agency), 신원 남용 (Identity Abuse))
   모든 에이전트는 암호화된 신원 (cryptographic identity)이 필요합니다. 이는 사용자 이름이나 API 키가 아니라, 동작에 서명할 수 있고 누구나 검증할 수 있는 Ed25519 키 쌍 (keypair)이어야 합니다. 이것이 없다면 어떤 에이전트가 무엇을 했는지 증명할 방법이 없습니다. EU AI Act는 고위험 AI 시스템에 대해 "고유 식별 (unique identification)"을 요구합니다. 오늘날 배포되는 대부분의 에이전트는 신원 자체가 아예 없습니다.
   필요한 것: 결정론적 에이전트 신원 생성 (Deterministic agent identity generation). 조회 및 검증이 가능한 공개 키 (public key). LangChain, CrewAI, n8n, AutoGen, 커스텀 빌드 등 모든 프레임워크에서 작동하는 형식.

2. 정책 집행 (Policy Enforcement) (OWASP: 불충분한 권한 부여 (Insufficient Authorization), 권한 상승 (Privilege Escalation))
   에이전트에게는 무엇을 할 수 있는지에 대한 강제된 제한이 필요합니다. 이는 가이드라인이나 프롬프트 (prompt)가 아니라, 금지된 동작이 실행되기 전에 차단하는 런타임 정책 평가 (runtime policy evaluation)여야 합니다. 결제 에이전트는 고객 데이터베이스를 내보낼 수 없어야 합니다. 지원 에이전트는 기록을 삭제할 수 없어야 합니다.
   필요한 것: 런타임 시 모든 동작에 대해 허용/차단/플래그 규칙을 평가하는 정책 엔진 (policy engine). 에이전트 개발자가 아닌 배포자에 의해 정의되는 규칙. 플래그가 지정된 동작에 대해 실행을 일시 중지하고, 타임아웃 시 자동 차단하는 인간 감독 게이트 (Human oversight gates).

3. 변조 방지 감사 추적 (Tamper-Proof Audit Trails) (OWASP: 불충분한 로깅 (Insufficient Logging), 로그 조작을 통한 서비스 거부 (Denial of Service via Log Manipulation))
   모든 에이전트 동작에는 서명되고 변조를 확인할 수 있는 기록이 필요합니다. 로그 파일이 아닙니다. 관리자 권한을 가진 누군가가 수정할 수 있는 데이터베이스 행 (database row)도 아닙니다.

사후에 수정될 경우 서명 검증 (signature verification)에 실패하는, 암호학적으로 서명된 이벤트 (cryptographically signed event)입니다. EU AI Act는 "이벤트의 자동 기록"과 요청 시 감사 추적 (audit trails)을 생성할 수 있는 능력을 요구합니다.
필요한 것: 생성 시점에 에이전트의 개인 키 (private key)로 모든 항목이 서명되는 이벤트 스트림 (event stream). 공개 키 (public key)를 보유한 누구라도 독립적으로 검증할 수 있는 이벤트. 관습이 아닌, 강제된 데이터베이스 제약 조건 (database constraints)에 의해 설계 단계부터 추가만 가능한 (append-only) 데이터 계층.

4. 컴플라이언스 보고 (Compliance Reporting) (EU AI Act: 제9조, 제12조, 제13조)
   규제 기관이 "당신의 AI 에이전트가 규정을 준수하고 있음을 증명하라"고 요구할 때, 당신에게 필요한 것은 피치 덱 (pitch deck)이 아니라 보고서입니다. 에이전트의 신원, 정책, 그리고 감사 추적을 특정 규제 요구 사항과 매핑하는 보고서 말입니다. EU AI Act는 적합성 평가 (conformity assessments)를 요구합니다. OWASP는 입증 가능한 완화 조치 (demonstrable mitigations)를 요구합니다.
   필요한 것: 이벤트 스트림을 읽어 감사인이 검증할 수 있는 문서를 생성하는 자동화된 컴플라이언스 보고서 생성 기능. OWASP Agentic Top 10, EU AI Act, HIPAA (의료 분야 배포용) 등을 위한 패키지.

5. 에이전트 간 신뢰 (Cross-Agent Trust) (OWASP: 불충분한 샌드박싱 (Inadequate Sandboxing), 신뢰할 수 없는 에이전트 상호작용 (Untrusted Agent Interaction))
   이것은 아직 아무도 구축하지 못한 계층입니다. X사의 에이전트 A가 Y사의 에이전트 B와 상호작용해야 할 때, 그들은 어떻게 서로를 검증할까요? Y사는 에이전트 A가 주장하는 본인이 맞는지, 주장하는 권한을 가지고 있는지, 그리고 깨끗한 이력을 가지고 있는지 어떻게 알 수 있을까요?
   필요한 것: 에이전트들이 서로의 권한(mandates)—즉 신원, 권한, 그리고 실적(track record)—을 확인할 수 있는 중립적인 검증 네트워크. 이것은 참여자가 추가될 때마다 전체 시스템의 가치를 높이는 네트워크 효과 (network-effect) 계층입니다.

이것이 왜 중립적이어야 하는가
위에서 언급한 다섯 가지 요구사항 — 신원 (identity), 정책 (policy), 감사 (audit), 컴플라이언스 (compliance), 에이전트 간 신뢰 (cross-agent trust) — 이 제대로 작동하려면 단일 시스템에 의해 제공되어야 합니다. 에이전트의 신원은 이벤트에 서명하는 신원과 동일해야 하며, 정책 엔진 (policy engine)에 의해 확인되고, 컴플라이언스 보고서에 나타나야 하며, 다른 에이전트들에 의해 검증되어야 합니다. 이를 여러 벤더 (vendor)로 파편화하면 어떤 기업도 도입하려 하지 않을 상호운용성 (interoperability)의 악몽이 발생합니다.
그리고 그 단일 시스템은 중립적이어야 합니다. 마케팅 문구로서의 중립성이 아니라, 구조적 사실로서의 중립성입니다. 플랫폼 비즈니스가 없고, 판매할 AI 모델이 없으며, 추가 판매할 컴퓨팅 자원 (compute)도 없는 엔티티 (entity)에 의해 운영되어야 합니다. 오직 신뢰 계층 (trust layer) 그 자체만이 유일한 비즈니스인 엔티티여야 하며, 그래야만 그들의 인센티브가 해당 계층의 정확성과 완벽하게 일치하게 됩니다.
이는 다음과 같은 것들을 만들어낸 것과 동일한 구조적 논리입니다:

• 인증 기관 (Certificate Authorities) — 브라우저는 스스로 서명하는 웹사이트를 신뢰하지 않습니다. 대신 신원을 검증하는 중립적인 제3자를 신뢰합니다. 신용 평가 기관 (Credit rating agencies) — 대출 기관은 차입자가 스스로의 신용을 평가하는 것을 신뢰하지 않습니다. 대신 신용도를 검증하는 독립적인 기관을 신뢰합니다. SWIFT — 은행들은 서로의 내부 원장 (ledger)을 신뢰하지 않습니다. 대신 모든 당사자가 대조하여 검증할 수 있는 중립적인 메시징 네트워크를 신뢰합니다.

AI 에이전트는 자율적인 경제 주체 (autonomous economic actors)입니다. 이들은 다른 모든 자율적인 경제 주체들이 필요로 해왔던 것과 동일한 인프라, 즉 독립적이고 중립적인 검증을 필요로 합니다.

10가지 OWASP 에이전트 리스크(Agentic Risks)와 중립적 신뢰 인프라와의 매핑

참고를 위해, 에이전트 애플리케이션(Agentic Applications)을 위한 OWASP Top 10 전체 목록과 중립적 신뢰 계층(neutral trust layer)이 각 리스크를 어떻게 해결하는지 정리했습니다:

ASI-01: 과도한 권한 (Excessive Agency) — 에이전트가 의도된 범위를 벗어나 행동함. 완화 방법: 허용/차단/플래그(allow/block/flag) 규칙을 갖춘 정책 집행 엔진(Policy enforcement engine). 민감한 작업 시 실행을 일시 중단하는 인간 감독 게이트(Human oversight gates).

ASI-02: 불충분한 권한 부여 (Insufficient Authorization) — 에이전트가 승인되지 않은 작업을 수행함. 완화 방법: 실행 전 모든 작업에 대한 런타임 정책 평가(Runtime policy evaluation). 배포자에 의해 정의된 에이전트별 권한 세트.

ASI-03: 신원 남용 (Identity Abuse) — 에이전트의 신원이 위조되거나 도난당함. 완화 방법: Ed25519 암호화 신원(cryptographic identity). 모든 작업은 에이전트의 개인 키(private key)로 서명됨. 공개 키(Public key)는 등록되어 검증 가능함.

ASI-04: 부적절한 가드레일 (Inadequate Guardrails) — 에이전트에 대한 행동 제한이 없음. 완화 방법: 사전 정의된 규칙 및 사용자 정의 규칙 템플릿을 갖춘 정책 엔진(Policy engine). 정책 위반 시 자동 차단.

ASI-05: 불충분한 로깅 및 모니터링 (Insufficient Logging and Monitoring) — 에이전트의 행동이 기록되지 않음. 완화 방법: 변조 방지(Tamper-proof) 서명된 이벤트 스트림. 모든 작업은 타임스탬프, 리소스, 결과 및 암호화 서명과 함께 기록됨.

ASI-06: 프롬프트 인젝션 에스컬레이션 (Prompt Injection Escalation) — 주입된 프롬프트가 에이전트의 권한을 상승시킴. 완화 방법: 정책 집행(Policy enforcement)이 트리거 방식과 관계없이 상승된 작업을 포착함. 정책 엔진은 의도(intent)에 상관없이 작업 자체를 평가함.

ASI-07: 신뢰할 수 없는 에이전트 상호작용 (Untrusted Agent Interaction) — 에이전트가 검증되지 않은 피어(peer)와 상호작용함. 완화 방법: 중립적 신뢰 네트워크를 통한 에이전트 간 검증(Cross-agent verification). 에이전트 A는 상호작용 전 에이전트 B의 권한(mandate)을 검증함.

ASI-08: 부적절한 샌드박싱 (Inadequate Sandboxing) — 에이전트가 실행 환경을 탈출함. 완화 방법: 정책 엔진 내의 작업 유형 제약(Action-type constraints). 샌드박스가 뚫리더라도 에이전트의 서명된 권한(signed mandate)이 수행 가능한 작업을 제한함.

ASI-09: 서비스 거부 (Denial of Service) — 에이전트가 자원을 소모하도록 압도당하거나 조작됨.

완화 방법: 이벤트 스트림 (event stream)에 대한 속도 제한 (Rate limiting) 및 이상 탐지 (anomaly detection). 행동 급증을 식별하는 위험 점수 산정 (Risk scoring).

ASI-10: 공급망 취약점 (Supply Chain Vulnerabilities) — 에이전트 파이프라인 내의 손상된 구성 요소. 완화 방법: 모든 구성 요소에 대한 신원 확인 (Identity verification). 특정 에이전트 신원으로 동작을 추적할 수 있는 감사 추적 (Audit trails)을 통해 손상된 구성 요소를 격리할 수 있도록 함.

이 문제를 시급하게 만드는 타임라인
EU AI 법 (EU AI Act)의 집행은 예측이 아닙니다. 그것은 확정된 날짜입니다: 2026년 8월 2일. 이것이 실질적으로 의미하는 바는 다음과 같습니다:

• EU 내에서 고위험 AI 시스템을 배포하는 기업은 적합성 평가 (conformity assessments)를 완료해야 함
• 자동 이벤트 기록 (Automatic event recording)이 작동 중이어야 함
• 인간 감독 (Human oversight) 메커니즘이 마련되어 있어야 함
• 기술 문서 (Technical documentation)는 감사가 가능해야 함
• 미준수 시 벌금: 최대 3,500만 유로 또는 전 세계 연간 매출액의 7%

이는 오늘부터 68일 남은 시점입니다. 만약 귀하가 EU 사용자, 고객 또는 데이터에 접촉하는 AI 에이전트를 배포하고 있다면 — 그리고 검증 가능한 신원, 강제된 정책, 그리고 변조 불가능한 감사 추적 (tamper-proof audit trail)을 갖추고 있지 않다면 — 귀하에게 남은 시간은 얼마 없습니다.

현재 존재하는 것
MandateZ는 AI 에이전트를 위한 중립적 신뢰 인프라 계층 (neutral trust infrastructure layer)입니다. 이는 정확히 이 문제를 해결하기 위해 구축되었습니다. MandateZ는 Claude, GPT, Gemini, LangChain, CrewAI, n8n, AutoGen 등 모든 벤더와 동시에 작동합니다. MandateZ는 플랫폼이 아니라 인프라이기 때문에 플랫폼 이해 상충 (platform conflict of interest)이 발생하지 않습니다.
현재 출시된 기능:

@mandatez/sdk (npm) — Ed25519 에이전트 신원 (agent identity), 런타임 정책 강제 (runtime policy enforcement), 인간 감독 게이트 (human oversight gates), 변조 방지된 서명된 이벤트 스트림 (tamper-proof signed event stream). 단 네 줄의 코드로 통합 가능.
@mandatez/mcp — Claude Desktop, Cursor, Windsurf에 직접 연결되는 7가지 도구. 에이전트 등록, 이벤트 추적, 정책 확인, 신뢰 프로필 획득, 신원 검증, 리스크 점수 계산.
컴플라이언스 보고서 생성기 (Compliance report generator) — OWASP Agentic Top 10, EU AI Act, HIPAA에 매핑된 자동화된 PDF 보고서.
에이전트 리스크 점수 (Agent Risk Score) — 이벤트 스트림 전반에 걸친 심각도 가중 리스크 계산. 도메인 분류, 사고 패턴 탐지, 행동 기준선 (behavioral baselines).
중립적 증명 (Neutral attestation) — MandateZ가 에이전트 활동에 독립적으로 교차 서명 (counter-signs) 합니다. 인증 없이 누구나 확인할 수 있는 공개 검증 엔드포인트 (public verification endpoint). 그 어떤 플랫폼도 신뢰성 있게 제공할 수 없는 기능입니다.
오픈 프로토콜 사양 (Open protocol specification) — 어떤 개발자라도 독립적으로 구현할 수 있는 400줄 분량의 사양.

무료 티어. 오픈 소스 SDK. 벤더 종속 (vendor lock-in) 없음. 암호학적 증명 (cryptographic proofs)이 자체 검증 가능하기 때문에, 사용자가 머물든 떠나든 이 신뢰 계층은 작동합니다.

이것이 가능하게 하는 미래
모든 에이전트가 위임장 (mandate) — 즉, 신원, 강제 가능한 제한 사항, 그리고 변조 방지된 기록 — 을 갖게 되면, 에이전트 경제 전체가 기본적으로 신뢰할 수 있게 됩니다. 에이전트들이 서로를 검증할 수 있습니다. 기업은 요구 시 컴플라이언스를 증명할 수 있습니다. 규제 기관은 중단 없이 감사할 수 있습니다. 보험사는 처음으로 AI 리스크를 정확하게 산정할 수 있습니다.
이것은 한 기업의 제품 로드맵이 아닙니다. 이것은 에이전트 경제가 작동하기 위해 필요한 인프라입니다. 누군가는 이를 구축해야 합니다. 어떤 플랫폼도 할 수 없습니다. 우리가 합니다.
모든 에이전트에게는 위임장 (mandate)이 필요합니다.

MandateZ는 AI 에이전트를 위한 중립적 신뢰 인프라 계층입니다. SDK: npmjs.com/package/@mandatez/sdk. Docs: mandatez.mintlify.app. Protocol: github.com/mandatez/core.