Skip to content
KitploitKITPLOIT
도구익스플로잇블로그
Log in
제출
도구익스플로잇블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

피드문의개인정보© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
authproof-sdk — AI 에이전트를 위한 암호학적으로 서명된 위임 영수증. AI가 할 수 있는 것과 할 수 없는 것을 정확히 정의합니다 — 서명 가능, 검증 가능, 변조 방지. | Kitploit
도구/GitHubGitHub/commonguy25/authproof-sdk
Authentication & AuthorizationCryptographyIdentity & Access Management (IAM)Supply Chain SecurityAPI SecurityAI Security
GitHubcommonguy25/authproof-sdk

authproof-sdk

AI 에이전트를 위한 암호학적으로 서명된 위임 영수증. AI가 할 수 있는 것과 할 수 없는 것을 정확히 정의합니다 — 서명 가능, 검증 가능, 변조 방지.

저장소 보기
62912일 전아직 검토되지 않음

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유
웹사이트

AuthProof SDK

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

13개의 순차 검사 (첫 실패 시 중단)

#검사차단 조건
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를 통해 게이트합니다.

  • LangChain — invoke() 메서드가 있는 모든 에이전트를 래핑합니다
  • Express/HTTP — 모든 Express 호환 프레임워크를 위한 요청 미들웨어
  • 일반 함수 래퍼 — 모든 비동기 함수를 래핑합니다
// 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가 당신에게 무엇을 증명하는지 결정하기 전에 이 내용을 읽어라.

  • 악의적인 운영자에 대한 장벽이 아니다. 검증자는 에이전트와 동일한 프로세스에서 실행된다. SDK의 어떤 것도 부정직한 운영자가 게이트를 건너뛰는 것을 막지 못한다. AuthProof는 게이트를 실행하는 배포를 위한 증명이며, 실행을 거부하는 배포를 위한 통제가 아니다.
  • 하드웨어 증명이 없다. TEE 및 모델 상태 기능은 정직한 배포에서 감사 및 변조 증거를 위해 소프트웨어로 계산된 자체 증명 측정값이다. 하드웨어 보장은 실제 TEE 하드웨어가 필요하며 이 SDK에서 제공되지 않는다.
  • 서명은 정규화되지 않는다. JS SDK는 삽입 순서 JSON에 서명한다. 교차 구현 검증이 깨지며, JWS/COSE 정규 프로파일은 향후 작업이다. Python SDK는 부분 포팅이며 미러가 아니다: JavaScript SDK와 와이어 호환이 되지 않으므로(필드 이름, 서명 인코딩, 정규화가 다름) 두 SDK는 서로의 영수증을 검증할 수 없다.
  • 타임스탬프는 존재 여부만 확인된다. SDK는 RFC 3161 토큰의 바이트에 항목 다이제스트가 포함되어 있는지 확인한다. TSA의 암호화 서명이나 인증서 체인은 검증하지 않는다. 완전한 RFC 3161 서명 검증은 범위 밖이다.
  • 텍스트 범위 매칭은 참고용일 뿐이다. 구조화된 ScopeSchema 없이는 범위 매칭이 관측성을 위해 기록되는 키워드 중복 신호에 불과하다. 결코 허용하거나 거부하지 않는다. 실제 범위 적용에는 ScopeSchema가 필요하다.
  • 검사 5는 건너뛸 수 있다. 호출자가 운영자가 주장하는 지침을 제공하지 않으면 검사 5는 경고와 함께 건너뛴다. 해당 호출에 대해 운영자 드리프트는 검증되지 않는다. 드리프트 감지가 중요할 때는 항상 operatorInstructions를 전달하라.
  • 키 관리 이야기가 없다. 키 교체, KMS/HSM 통합, 침해 절차는 이 SDK의 일부가 아니다.
  • 영수증 논스가 없다. 일회용 시맨틱에는 내구성 있는 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의 암호학적 해시를 참조해야 한다. 해시가 일치하지 않으면 실행되지 않는다.

경계

도구 다운로드