AuthProof SDK

AuthProof एजेंटिक AI के लिए एक क्रिप्टोग्राफिक डेलीगेशन प्रोटोकॉल है। इस क्षेत्र के अधिकांश प्रोटोकॉल ऑपरेटर-परिभाषित नीति के विरुद्ध प्रवर्तन करते हैं — ऑपरेटर को उपयोगकर्ता के मूल इरादे को बाद में विस्तारित या पुनर्व्याख्या करने का अधिकार देते हैं। AuthProof एक अलग ट्रस्ट मॉडल पर बनाया गया है: उपयोगकर्ता की अपनी निजी कुंजी निष्पादन को गेट करने वाले प्राधिकरण ऑब्जेक्ट पर हस्ताक्षर करती है, और लाइव मॉडल स्थिति को प्राधिकरण समय और निष्पादन से ठीक पहले दोनों समय सत्यापित किया जाता है। उपयोगकर्ता-हस्ताक्षरित प्राधिकरण और लाइव मॉडल-स्थिति गेटिंग का संयोजन विशिष्ट दावा है — कोई व्यापक प्रवर्तन कहानी नहीं।

क्या इसे अलग बनाता है:

• उपयोगकर्ता हस्ताक्षर करने वाला प्राधिकरण है। प्रत्येक प्रतिस्पर्धी प्रोटोकॉल (AIP, AITH, OAP, SAGA, AgentSpec) ऑपरेटर द्वारा परिभाषित नीति के विरुद्ध प्रवर्तन करता है। AuthProof में, उपयोगकर्ता की निजी कुंजी सीधे प्राधिकरण ऑब्जेक्ट पर हस्ताक्षर करती है। उपयोगकर्ता के हस्ताक्षर करने के बाद ऑपरेटर दायरा नहीं बढ़ा सकता।

• दो-चरणीय मॉडल-स्थिति प्रतिबद्धता। मॉडल को प्राधिकरण समय पर मापा जाता है और निष्पादन से ठीक पहले पुनः मापा जाता है। यदि मॉडल उन दो बिंदुओं के बीच बदल गया है, तो निष्पादन प्री-एक्ज़ीक्यूशन वेरिफिकेशन पर अवरुद्ध हो जाता है।

• प्रदाता अद्यतन बनाम दुर्भावनापूर्ण प्रतिस्थापन, अलग किए गए। प्रोटोकॉल मॉडल-स्थिति परिवर्तनों को दो श्रेणियों में वर्गीकृत करता है: वैध प्रदाता अद्यतन (PROVIDER_UPDATE_REQUIRES_REAUTH) और अनधिकृत स्वैप (MALICIOUS_MODEL_SUBSTITUTION). प्रत्येक एक मशीन-पठनीय अस्वीकृति कारण कोड उत्पन्न करता है जो पहचानता है कि कौन से घटक बदले हैं।

Pre-Execution Verifier

नियतात्मक गेट जो किसी भी एजेंट कार्रवाई के निष्पादन से पहले चलता है।

PreExecutionVerifier एजेंट रनटाइम के बाहर स्थित है। रनटाइम को तब तक नियंत्रण नहीं मिलता जब तक कि सत्यापक पास नहीं हो जाता। एक समझौता किया गया या दुर्भावनापूर्ण एजेंट इसे छोड़ नहीं सकता — यह रनटाइम शुरू होने से पहले चलता है।

यह क्यों मायने रखता है

पारंपरिक प्राधिकरण जाँच एजेंट रनटाइम के अंदर होती हैं। यदि रनटाइम से समझौता किया जाता है, तो उन जाँचों को छोड़ा, पुनर्क्रमित या बायपास किया जा सकता है। PreExecutionVerifier प्राधिकरण को पूरी तरह से रनटाइम के बाहर ले जाकर इस हमले की सतह को समाप्त करता है। एजेंट केवल तभी निष्पादित होता है — और केवल तभी — जब सभी छह अनुक्रमिक जाँच पहले पास हो जाएँ।

त्वरित आरंभ```js

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 six checks pass

### Six sequential checks (stops at first failure)

| # | जांच | तब अवरुद्ध करता है |
|---|-------|-------------|
| 1 | रसीद हस्ताक्षर | ECDSA P-256 हस्ताक्षर अमान्य या रसीद से छेड़छाड़ की गई |
| 2 | निरसन | `RevocationRegistry` के माध्यम से रसीद निरस्त कर दी गई है |
| 3 | समय सीमा | रसीद समाप्त हो गई या अभी तक मान्य नहीं है (लॉग टाइमस्टैम्प ओरेकल, क्लाइंट घड़ी नहीं) |
| 4 | दायरा | कार्रवाई `ScopeSchema.allowedActions` में नहीं है या टेक्स्ट-आधारित दायरा मिलान विफल रहता है |
| 5 | ऑपरेटर निर्देश | वर्तमान निर्देश जारी करने के समय रसीद में बंद हैश से मेल नहीं खाते |
| 6 | प्रोग्राम हैश | प्रदान किया गया `programHash` प्रतिबद्ध `executes` हैश से मेल नहीं खाता (कोड प्रतिस्थापन रोकथाम) |

प्रत्येक जांच परिणाम — पास या फेल — स्वचालित रूप से एक अपरिवर्तनीय `ActionLog` में लॉग किया जाता है, जो सत्यापनकर्ता की अपनी कुंजी से हस्ताक्षरित होता है।

### Middleware integrations

सामान्य फ्रेमवर्क के लिए ड्रॉप-इन रैपर। प्रत्येक रैपर लपेटे गए कोड के निष्पादित होने से पहले प्रत्येक कॉल को `PreExecutionVerifier` के माध्यम से गेट करता है।

- **[LangChain](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/langchain.js)** — किसी भी एजेंट को `invoke()` विधि के साथ लपेटता है
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/express.js)** — किसी भी Express-संगत फ्रेमवर्क के लिए अनुरोध मिडलवेयर
- **[Generic function wrapper](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/generic.js)** — किसी भी async फ़ंक्शन को लपेटता है```js
// 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 })

---

समस्या

एजेंट पहचान के लिए हर मौजूदा IETF ढांचा — AIP, draft-klrc-aiagent-auth, WIMSE — सेवा-से-एजेंट विश्वास को संबोधित करता है: कैसे एक डाउनस्ट्रीम सेवा यह सत्यापित करती है कि कोई एजेंट उसे कॉल करने के लिए अधिकृत है। उनमें से कोई भी उपयोगकर्ता-से-ऑपरेटर विश्वास को संबोधित नहीं करता।

वर्तमान एजेंटिक सिस्टम में प्रतिनिधिमंडल श्रृंखला है:``` User → Operator → Agent → Services

The user instructs the operator. The operator instructs the agent. But no cryptographic record of the user's original intent exists at the moment of delegation. The operator becomes a trusted third party with unchecked authority to expand, distort, or omit the user's instructions before they reach the agent.

The consequences:

- Users cannot prove what they authorized.
- Regulators have no audit trail.
- Courts have no evidence chain.
- Agents cannot distinguish legitimate operator instructions from compromised or rogue ones.

AuthProof fills this gap.

---

## The Core Primitive: Delegation Receipt

A **Delegation Receipt** is a signed Authorization Object anchored to a decentralized append-only log before any agent action begins. It contains four required fields:

### Scope

An explicit allowlist of permitted operations. Everything not listed is denied by default. Expressed in structured format — not natural language. Operation classes:

| Class | Description |
|---|---|
| `reads` | Read access to specified resources |
| `writes` | Write access to specified resources |
| `deletes` | Deletion of specified resources |
| `executes` | Execution of a specific program, referenced by its **static capability signature hash** |

`executes` is the most dangerous class. It must reference the cryptographic hash of a Safescript program's static capability DAG — not a name, URI, or description. No hash match means no execution.

### Boundaries

Explicit prohibitions that cannot be overridden by operator instructions under any circumstances. User-defined hard limits that survive any subsequent operator instruction.

### Time Window

Validity period of the authorization. The **log timestamp** is the time oracle — not the client clock. Client clocks are explicitly excluded from time validation.

### Operator Instruction Hash

A cryptographic hash of the operator's stated instructions at delegation time. If the operator subsequently instructs the agent differently, the discrepancy is detectable from the log without any additional trust assumptions.