
AI 에이전트를 위한 암호학적으로 서명된 위임 영수증. AI가 할 수 있는 것과 할 수 없는 것을 정확히 정의합니다 — 서명 가능, 검증 가능, 변조 방지.
AuthProof는 AI 에이전트를 위한 감사 및 귀속(attribution) 계층입니다. 이를 통해 에이전트가 행동하기 전에 사용자가 무엇을 승인했는지 증명할 수 있으며, 에이전트가 해당 승인에 대해 실제로 무엇을 했는지 기록합니다.
메커니즘은 단순합니다. 사용자는 자신의 개인 키로 위임 영수증(delegation receipt)에 서명합니다. 영수증에는 범위, 경계, 운영자 지침(해시됨), 그리고 시간 창이 포함됩니다. 실행 전 검증기(pre-execution verifier)는 제안된 각 작업을 영수증과 대조하여 확인하고, 추가 전용(append-only) 작업 로그가 실행된 내용을 기록합니다. 그 결과는 증거입니다: 승인된 것과 실제로 일어난 것을 비교한 것입니다.
이것은 악의적인 운영자에 대한 보안 통제가 아닙니다. 검증기는 에이전트와 동일한 프로세스에서 실행되며, 부정직한 운영자는 단순히 이를 호출하지 않을 수 있습니다. 동일한 런타임 내부에서는 어떤 암호학적 속성으로도 이를 해결할 수 없습니다. AuthProof는 게이트를 실행하는 배포에 대한 승인을 증명하며, 감사자, 규제 기관, 사용자에게 사후에 확인할 수 있는 기록을 제공합니다.
차별점:
사용자가 서명 권한자입니다. 승인 객체는 운영자가 관리하는 정책에 기록되는 것이 아니라 사용자의 개인 키로 서명됩니다. 영수증에 서명된 범위와 프로그램 해시는 항상 운영자 로그 메타데이터보다 우선합니다. 운영자 메타데이터가 서명된 영수증과 충돌하면, 게이트는 메타데이터를 따르는 대신 작업을 거부합니다.
2단계 모델 상태 커밋먼트. 모델은 승인 시점에 측정되고 실행 전에 다시 측정됩니다. 이러한 측정은 소프트웨어로 계산되고 자기 증명(self-attested)된 것이며, 하드웨어에 뿌리를 둔 것이 아닙니다. 이는 정직한 배포를 위한 변조 증거(tamper-evidence)이며, 적대적인 호스트에 대한 증명이 아닙니다.
제공자 업데이트와 악의적 대체의 구분. 모델 상태 변경은 정당한 제공자 업데이트(PROVIDER_UPDATE_REQUIRES_REAUTH)와 무단 교체(MALICIOUS_MODEL_SUBSTITUTION)로 분류됩니다. 각각은 어떤 구성 요소가 변경되었는지 식별하는 기계 판독 가능한 거부 사유 코드를 생성합니다.
에이전트 작업이 실행되기 전에 작동하는 게이트.
PreExecutionVerifier.check()는 제안된 각 작업을 서명된 위임 영수증과 대조하여 검증합니다. 에이전트 프로세스에서 작업이 실행되기 전에 모든 작업을 이 검증기를 통과시키십시오. 검증기는 자체 허용/거부 결정에 서명하여 감사 로그에 기록하므로, 모든 결과가 기록의 일부가 됩니다.
염두에 두어야 할 하나의 냉혹한 진실: 검증기는 동일 프로세스에서 실행됩니다. 검증기는 증명을 검증하지만, 이를 호출하기를 거부하는 운영자를 막을 수는 없습니다. 코드를 실행하는 운영자에 대한 강제가 필요한 곳이 아니라, 증거가 필요한 곳에서 사용하십시오.
오늘날 대부분의 에이전트 승인은 운영자의 말에 불과합니다: 운영자가 작성하고 운영자가 통제하는 코드로 강제되는 정책입니다. 문제가 발생했을 때, 사용자가 실제로 무엇을 승인했는지에 대한 기록은 없고, 운영자가 재구성한 것만 있을 뿐입니다. AuthProof는 이를 뒤집습니다. 사용자의 서명된 영수증은 실행보다 앞서 존재하며, 작업 로그는 그에 대해 무엇이 실행되었는지 기록합니다. "사용자가 이것을 승인했는가?"라는 질문은 논쟁의 대상이 아니라 확인 가능한 것이 됩니다.
import { PreExecutionVerifier, DelegationLog } from 'authproof-sdk/pre-execution-verifier'
import { RevocationRegistry } from 'authproof-sdk'
// 1. Set up the gate
const delegationLog = new DelegationLog()
const revocationRegistry = new RevocationRegistry()
await revocationRegistry.init({ privateKey, publicJwk })
const verifier = new PreExecutionVerifier({ delegationLog, revocationRegistry })
await verifier.init({ privateKey: verifierKey, publicJwk: verifierPub })
// 2. Register your delegation receipt
delegationLog.add(receiptHash, receipt)
// 3. Gate every action â before the agent runs
const result = await verifier.check({
receiptHash,
action: { operation: 'read', resource: 'calendar' },
operatorInstructions: 'Summarize meetings. Stay within scope.',
programHash, // optional: prevents code substitution attacks
})
if (!result.allowed) {
throw new Error(`Blocked: ${result.blockedReason}`)
}
// Agent runtime only reaches here after all thirteen checks pass
| # | 검사 | 차단 조건 |
|---|---|---|
| 1 | 영수증 서명 | ECDSA P-256 서명이 유효하지 않거나 영수증이 변조됨 |
| 2 | 폐기 | RevocationRegistry를 통해 영수증이 폐기됨 (연쇄: 폐기된 상위 항목은 하위 항목을 거부함) |
| 3 | 시간 창 | 영수증이 만료되었거나 아직 유효하지 않음 (클라이언트 시계가 아닌 로그 타임스탬프 오라클) |
| 4 | 범위 | 작업이 ScopeSchema.allowedActions에 없음; 구조화된 스키마가 없으면 키워드 매칭은 참고용일 뿐이며 절대 게이트하지 않음 |
| 5 | 운영자 지침 | 제공된 지침이 발급 시 영수증에 잠긴 해시와 일치하지 않음; 호출자가 이를 생략하면 경고와 함께 건너뜀 |
| 6 | 프로그램 해시 | 제공된 programHash가 커밋된 executes 해시와 일치하지 않음 (선택 사항) |
| 7 | 세션 위험 | 신뢰/위험 임계값 초과 (선택 사항) |
| 8 | 도구 스키마 무결성 | toolSchemaHash가 영수증과 일치하지 않음 (선택 사항) |
| 9 | 모델 상태 | 모델 드리프트 감지됨 (선택 사항; 소프트웨어로 계산된 자체 증명 측정) |
| 10 | 도구 출력 해시 바인딩 | 출력 해시가 영수증과 일치하지 않음 (선택 사항) |
| 11 | 지침 출처 | 지침 소스가 영수증의 trustedSources에 없음 (선택 사항) |
| 14 | 상위 범위 포함 | 하위 영수증이 상위 항목의 범위를 초과함 (하위 영수증 전용); 검사 시점에 상위 항목을 폐기하면 하위 항목이 거부됨 |
| 15 | 권한 상태 드리프트 | 발급 이후 authorityStateCommitment가 드리프트됨 (선택 사항) |
슬롯 12와 13은 구현된 적이 없으며, 번호 공백은 역사적인 것입니다. 게이트는 첫 번째 실패한 검사에서 중단됩니다. 일회용 소비는 모든 검사가 통과한 후 마지막에 실행되므로, 다른 이유로 거부될 영수증에 대해 소비 슬롯이 소모되는 일은 없습니다.
모든 검사 결과는 통과든 실패든 검증자 자신의 키로 서명된 변경 불가능한 ActionLog에 자동으로 기록됩니다.
서명된 데이터가 우선합니다. 서명된 영수증의 범위와 프로그램 해시는 항상 운영자 로그 메타데이터보다 우선합니다. 서명되지 않은 DelegationLog 메타데이터가 서명된 영수증과 불일치하면, 게이트는 작업을 거부합니다 (SCOPE_METADATA_MISMATCH / PROGRAM_METADATA_MISMATCH). 로그 메타데이터는 영수증에 구조화된 범위나 서명된 executes 값이 없을 때만 대체 수단으로 사용됩니다.
가이드 위임은 관찰에 의해 안내됩니다. ScopeDiscovery.guided()와 AuthProofClient.delegateGuided()는 observe → generateScope → approve → finalize를 한 번의 호출로 실행하며, 관찰된 전체 초안 범위는 사람의 검토 없이 자동 승인됩니다. 진정한 인간 승인 순간을 위해서는 reviewDraft 훅을 전달하거나(발급 전에 초안을 승인, 수정 또는 거부), 명시적인 approve()와 함께 단계를 개별적으로 실행하십시오.
일반적인 프레임워크를 위한 드롭인 래퍼입니다. 각 래퍼는 래핑된 코드가 실행되기 전에 모든 호출을 PreExecutionVerifier를 통해 게이트합니다.
invoke() 메서드가 있는 모든 에이전트를 래핑합니다// LangChain
import { authproofMiddleware } from 'authproof-sdk/middleware/langchain'
const guardedAgent = authproofMiddleware(agent, { receiptHash, verifier })
// Express
import { authproofMiddleware } from 'authproof-sdk/middleware/express'
app.use(authproofMiddleware({ verifier, getReceiptHash: (req) => req.headers['x-receipt-hash'] }))
// Any function
import { guardFunction } from 'authproof-sdk/middleware/generic'
const guardedExecute = guardFunction(executeAction, { receiptHash, verifier, action })
AuthProof가 당신에게 무엇을 증명하는지 결정하기 전에 이 내용을 읽어라.
ScopeSchema 없이는 범위 매칭이 관측성을 위해 기록되는 키워드 중복 신호에 불과하다. 결코 허용하거나 거부하지 않는다. 실제 범위 적용에는 ScopeSchema가 필요하다.operatorInstructions를 전달하라.ConsumptionStore가 필요하다(Redis 어댑터가 포함되어 있음). 이것이 없으면 프로세스 간 재생 감지가 보장되지 않는다.에이전트 아이덴티티를 위한 기존의 모든 IETF 프레임워크 â AIP, draft-klrc-aiagent-auth, WIMSE â 는 서비스 대 에이전트 신뢰를 다룬다: 다운스트림 서비스가 에이전트가 자신을 호출할 권한이 있는지 검증하는 방법. 이들 중 어느 것도 사용자 대 운영자 신뢰를 다루지 않는다.
현재 에이전틱 시스템의 위임 체인은 다음과 같다:
User â Operator â Agent â Services
사용자가 운영자에게 지시한다. 운영자가 에이전트에게 지시한다. 그러나 위임이 이루어지는 순간 사용자의 원래 의도에 대한 암호학적 기록은 존재하지 않는다. 운영자는 사용자의 지시가 에이전트에 도달하기 전에 이를 확장, 왜곡, 또는 누락시킬 수 있는 검증되지 않은 권한을 가진 신뢰할 수 있는 제3자가 된다.
그 결과:
AuthProof가 이 공백을 채운다.
위임 영수증(Delegation Receipt) 은 에이전트 행동이 시작되기 전에 탈중앙화된 추가 전용 로그에 고정된 서명된 권한 부여 객체다. 이는 네 가지 필수 필드를 포함한다:
허용된 작업의 명시적 허용 목록. 나열되지 않은 모든 것은 기본적으로 거부된다. 자연어가 아닌 구조화된 형식으로 표현된다. 작업 클래스:
| 클래스 | 설명 |
|---|---|
reads | 지정된 리소스에 대한 읽기 접근 |
writes | 지정된 리소스에 대한 쓰기 접근 |
deletes | 지정된 리소스의 삭제 |
executes | 정적 능력 서명 해시로 참조되는 특정 프로그램의 실행 |
executes는 가장 위험한 클래스다. 이름, URI, 또는 설명이 아닌 Safescript 프로그램의 정적 능력 DAG의 암호학적 해시를 참조해야 한다. 해시가 일치하지 않으면 실행되지 않는다.