AuthProof SDK

AuthProof — это криптографический протокол делегирования для агентного ИИ. Большинство протоколов в этой области обеспечивают соблюдение политики, определяемой оператором, предоставляя оператору полномочия расширять или переосмысливать исходное намерение пользователя постфактум. AuthProof построен на другой модели доверия: собственный закрытый ключ пользователя подписывает объект авторизации, управляющий выполнением, а состояние живой модели проверяется как в момент авторизации, так и непосредственно перед выполнением. Сочетание подписанной пользователем авторизации и блокировки на основе состояния живой модели является конкретным утверждением, а не общей историей принуждения.

Что делает его особенным:

• Пользователь является подписывающим органом. Каждый конкурирующий протокол (AIP, AITH, OAP, SAGA, AgentSpec) обеспечивает соблюдение политики, определяемой оператором. В AuthProof закрытый ключ пользователя напрямую подписывает объект авторизации. Оператор не может расширить область действия после того, как пользователь подписал.

• Двухфазная фиксация состояния модели. Модель измеряется в момент авторизации и повторно измеряется непосредственно перед выполнением. Если модель «дрейфовала» между этими двумя точками, выполнение блокируется на этапе проверки перед выполнением.

• Различие между обновлением провайдера и вредоносной подменой. Протокол классифицирует изменения состояния модели на две категории: легитимные обновления провайдера (PROVIDER_UPDATE_REQUIRES_REAUTH) и несанкционированные подмены (MALICIOUS_MODEL_SUBSTITUTION). Каждая генерирует машиночитаемый код причины отказа, идентифицирующий, какие компоненты изменились.

Верификатор предварительного выполнения

Детерминированный шлюз, который запускается перед выполнением любого действия агента.

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

### Шесть последовательных проверок (остановка при первой неудаче)

| # | Проверка | Блокирует, когда |
|---|----------|------------------|
| 1 | Подпись квитанции | Недействительная подпись ECDSA P-256 или квитанция изменена |
| 2 | Отзыв | Квитанция была отозвана через `RevocationRegistry` |
| 3 | Временное окно | Квитанция истекла или еще не действительна (используется оракул временных меток, а не клиентские часы) |
| 4 | Область | Действие отсутствует в `ScopeSchema.allowedActions` или не проходит текстовое сопоставление области |
| 5 | Инструкции оператора | Текущие инструкции не соответствуют хешу, зафиксированному в квитанции при выдаче |
| 6 | Хеш программы | Предоставленный `programHash` не соответствует хешу `executes` (предотвращение подмены кода) |

Каждый результат проверки — пройдена или не пройдена — автоматически записывается в неизменяемый `ActionLog`, подписанный собственным ключом верификатора.

### Интеграции промежуточного ПО

Модули-обертки для распространенных фреймворков. Каждая обертка пропускает каждый вызов через `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 фреймворка
- **[Обертка для произвольных функций](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/generic.js)** — оборачивает любую асинхронную функцию```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

Пользователь отдаёт инструкции оператору. Оператор отдаёт инструкции агенту. Но в момент делегирования не существует криптографической записи исходного намерения пользователя. Оператор становится доверенной третьей стороной с бесконтрольными полномочиями расширять, искажать или опускать инструкции пользователя до того, как они дойдут до агента.

Последствия:

- Пользователи не могут доказать, что они авторизовали.
- Регуляторы не имеют аудиторского следа.
- Суды не имеют цепочки доказательств.
- Агенты не могут отличить легитимные инструкции оператора от скомпрометированных или вредоносных.

AuthProof заполняет этот пробел.

---

## The Core Primitive: Delegation Receipt

**Delegation Receipt** — это подписанный объект авторизации, закреплённый в децентрализованном журнале с возможностью только добавления записей до того, как начнутся какие-либо действия агента. Он содержит четыре обязательных поля:

### Scope

Явный белый список разрешённых операций. Всё, что не перечислено, запрещено по умолчанию. Выражено в структурированном формате — не на естественном языке. Классы операций:

| Class | Description |
|---|---|
| `reads` | Доступ на чтение к указанным ресурсам |
| `writes` | Доступ на запись к указанным ресурсам |
| `deletes` | Удаление указанных ресурсов |
| `executes` | Выполнение конкретной программы, на которую ссылается её **static capability signature hash** |

`executes` — самый опасный класс. Он должен ссылаться на криптографический хэш статического графа возможностей (static capability DAG) программы Safescript — а не на имя, URI или описание. Несовпадение хэша означает отсутствие выполнения.

### Boundaries